[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft charter - is it ok?



Stephen, et alia:

The new draft charter is acceptable to me.  We could nit-pick things to
death, but I'm suggesting we don't.  To me, this is fine as it is -
let's go with it.

		Al Arsenault


Stephen Farrell wrote:
> 
> Folks,
> 
> I've tried to put together the comments on the draft charter and
> done a bit more editing. The quicker we get this agreed, (on the
> list, then with the ADs and IESG) the quicker we get to become
> a WG.
> 
> If its fine as is, (which I hope will be the case), then we can have
> a very short charter discussion next week and use the time to get on
> with work (discussing requirements). I realise that we're very close
> to the meeting so we will have to at least have a short discussion
> over this, even if its perfect.
> 
> Meanwhile, could those who are still on email and can live with
> the attached say so on the list, or suggest alternative text if
> they feel a real need for substantive changes.
> 
> Regards,
> Stephen.
> 
> ---------
> 
> Securely Available Credentials (sacred)
> 
> Chairs:
> 
> Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>
> Magnus Nystrom <magnus@xxxxxxxxxxxxxxx>
> 
> Security Area Director(s):
> 
> Jeffrey Schiller <jis@xxxxxxx>
> Marcus Leech <mleech@xxxxxxxxxxxxxxxxxx>
> 
> Security Area Advisor:
> 
> TBD.
> 
> Mailing Lists:
> 
> General Discussion: ietf-sacred@xxxxxxx
> To Subscribe:  ietf-sacred-request@xxxxxxx
> In Body: subscribe (In Body)
> Archive: http://www.imc.org/ietf-sacred/mail-archive/
> Web site: http://www.imc.org/ietf-sacred/
> 
> Description of Working Group:
> 
> PKI credentials typically consist of a public/private key pair
> and a corresponding certificate or certificate chain.  They are
> stored on a desktop or laptop system as part of an application
> specific store. In general, support for credential export/import
> is uneven and end users need to get too involved with the mechanics
> of creating and maintaining their security profiles. Application
> specific stores also mean that user's cannot easily use the same
> credential in multiple applications on multiple devices, that is,
> today, credentials typically aren't portable.
> 
> PKIs that use hardware tokens (e.g., smart cards, PCMCIA cards) do
> allow for portability of the user's credentials. However, many PKI
> systems use only software solutions, but would like to provide similar
> portability by making use of "soft tokens", or software files containing
> the information normally contained in hardware tokens. Ideally, users
> would be able to use a common set of security credentials with their
> desktop and laptop PCs, PDAs, cell phones, and other Internet-ready
> devices.
> 
> Even where real hardware tokens are used, there may also be substantial
> benefit derived from using soft token protocols in support of credential
> management functions such as, for example, installation, token (locked
> PIN) recovery, or token replacement.
> 
> There are at least two possible solutions for providing credential
> mobility.  The first solution involves the use of a "credential server".
> Credentials are uploaded to the server by one device (e.g., a desktop
> computer); they can be stored there and downloaded when needed by the
> same or a different device (e.g., a mobile phone, PDA, or laptop
> computer).
> 
> A second solution involves the "direct" transfer of credentials from
> one device to another (e.g., from a mobile phone to a PDA).  While
> there may be servers involved in the transfer, in security terms the
> transfer is direct - that is, there is no "credential server" that takes
> an active part in securing the exchanges.
> 
> While it is possible that a single protocol can be developed for both types
> of solution, it is possible that two different protocols will be needed: one
> for interacting with a credential server; and the other to facilitate the
> "direct" transfer of credentials.
> 
> Security is at a premium for this working group; only authorized
> clients should be allowed to download credentials, credentials must be
> protected against eavesdropping and cut & paste attacks; attackers
> must not be able to successfully replace an entity's credentials at a
> credential server; etc. In general, the security provided by systems
> using soft tokens will be less than is provided in systems using actual
> hardware tokens, as the hardware tokens tend to be more resistant to
> improper inspection and modification.  However, in many environments,
> the security offered by soft token protocols will be sufficient.
> 
> Availability is also at a premium. Soft tokens must be available
> to many different types of client with different characteristics in
> terms of processing power, storage and network connectivity.
> 
> The purpose of this working group is therefore to gather requirements
> for a solution or set of solutions beneficial to the Internet community,
> establish a framework for these, and to develop, adapt, or adopt the
> required protocols and credential formats necessary to achieve
> interoperability.
> 
> Goals & Milestone:
> 
> Oct 00  Submit first draft of Requirements document
> 
> Nov 00  Submit first draft of Frameworks document
> 
> Dec 00  Submit second draft of Requirements document
>         Submit second draft of Frameworks document
>         Submit first draft of Protocol document (incl. PDU syntax)
> 
> Mar 01  Requirements document to Informational RFC
>         Frameworks document to Informational RFC
>         Submit second draft of Protocol document
> 
> Jun 01  Protocol document to Proposed Standard
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 647 7406
> 61 Fitzwilliam Lane,                    fax: +353 1 647 7499
> Dublin 2.                mailto:stephen.farrell@xxxxxxxxxxxx
> Ireland                             http://www.baltimore.com