[ietf-enroll] Charter

[Jim Schaad]

Paul, 

A couple of comments in line.

jim

> -----Original Message-----
> From: ietf-enroll-bounces at mit.edu 
> [mailto:ietf-enroll-bounces at mit.edu] On Behalf Of Paul Hoffman / VPNC
> Sent: Thursday, May 01, 2003 8:33 AM
> To: jimsch at exmsft.com; IETF-Enroll
> Subject: Re: [ietf-enroll] Charter
> 
> 
> 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.

I am agnositic on this term.  My main problem with identity is that, for
me, it implies actual knowledge of who is on the other side.  But I can
see people making the same argument on name.  One term that I consdered
using here, and I see is in my vocabulary list is "Entity Label".  Would
you consider this as a better term?

> 
> >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.

I consider both models to be acceptable within the framework.  Sometimes
there is only one thing that can be asked for, some times the enrollee
wants to ask for certain privelges and some times the enroller wants to
say that only some things (which can change over time) can change.

> 
> >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?

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)"?
> 

I actually just tossed this in as a last minute thought to see if I got
some discussion.  I think that we should be able to model real world
transactions and this was an example of one that we should make sure
that we could do.  I don't care about limiting it to just credit cards,
but this is not directly involved in the primary mission of the group.


> >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 _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu 
> https://mailman.mit.edu/mailman/listinfo/ietf-> enroll
>