[ietf-enroll] Charter

[Paul Hoffman / VPNC]

I wasn't at the BOF, but this sounds useful and not difficult if we 
can keep religion about which of the three types of credentials is 
"better" for everyone.

Jim's proposed charter sounds good. Minor notes:

>When doing enrollment of a user against a service provider, three pieces
>of information need to be provided or created in order to support
>authentication of the user to the provider and to allow for additional
>security services to be provided any information exchanged.  These
>pieces of data are:
>
>1.	The name of the entity being enrolled,

I prefer "identity" over "name". An email address or an IP address is 
an identity, but not a name.

>2.	A piece of keying information to be used
>3.	A set of permissions for operations for the entity being
>enrolled.

I'm not sure why this is here. If I understand the list above, the 
protocol looks a bit like:

Alice: "I'm Alice, here is my keying material, and I want the set of 
permissions called A."
Bob: "I agree with your keying material, therefore I agree you are 
Alice and you get permissions A."

A different model that I think is even more common and expected would be:

Alice: "I'm Alice, here is my keying material; what permissions do I get?"
Bob: "I agree with your keying material, therefore I agree you are 
Alice, and I give you permissions A."

If people agree with that description, then #3 above is not needed.

>This group will create a model to be used in describing enrollment
>procedures and create a document for a framework how this is to be done.
>The group will then produce three documents profiling the use of the
>framework for the following cases:
>
>1.	A shared secret key
>2.	A base asymmetric key

I think that is supposed to be "A *bare* symmetric key", yes?

>3.	A bound asymmetric key (e.g. an X.509 certificate).
>
>Additionally, the group will consider the case of using a credit card
>profiling the framework.

I don't like limiting it to credit cards. How about "external, 
human-based trust (such as credit cards)"?

>Goals and Milestones:
>
>Sept 2003	First draft of model
>Dec 2003	Last call on model document
>Nov 2003	First draft of Framework document
>April 2004	Last call on module document
>March 2004	First draft of secret key profile
>March 2004	First draft of bare asymmetric key profile
>March 2004	First draft of bound asymmetric key profile
>Aug 2004	Last call on secret key profile
>Aug 2004	Last call on bare asymmetric key profile
>Aug 2004	Last call on bound asymmetric key profile

Looks good to me.

--Paul Hoffman, Director
--VPN Consortium