[ietf-enroll] Updated Charter

[Jim Schaad]

Max,

> -----Original Message-----
> From: ietf-enroll-bounces at mit.edu 
> [mailto:ietf-enroll-bounces at mit.edu] On Behalf Of Max Pritikin
> Sent: Monday, May 12, 2003 8:39 AM
> To: jimsch at exmsft.com
> Cc: 'IETF-Enroll'
> Subject: Re: [ietf-enroll] Updated Charter
> 
> 
> Inlines,
> 
> On Sun, 2003-05-11 at 23:26, Jim Schaad wrote:
> > Here is the updated charter based on the comments that I 
> have seen on 
> > the list. Max, I have not completely ignored your comments, 
> however I 
> > feel that many of them deal with what the model should look like 
> > rather than the scope of the work of the group and have 
> therefore not 
> > directly incorperated them.
> 
> Thanks Jim. No worries, the following is developing in a 
> direction I'm happy with. I've been bringing up the model 
> discussion early to keep the charter from being focused on an 
> 'enrollment' vs 'introduction' model. (I consider them distinct).
> 
> A couple of quick comments,
> 
> > Jim
> > 
> > 
> > Description of Working Group:
> > 
> > There are many cases where a service consumer needs to obtain 
> > credential information from a service provider and provide for some 
> > type of information for validation of identity.  This working group 
> > will look at some of the cases dealing with the use of 
> cryptographic 
> > algorithms for providing this information.
> > 
> > When doing enrollment of a service consumer against a service 
> > provider, three pieces of information need to be provided 
> or created 
> > in order to support authentication of the service consumer to the 
> > service provider (and visa versa) and to allow for 
> additional security 
> > services to be provided any information exchanged.  These pieces of 
> > data are:
> >
> > 1.	The  "entity label" for the service consumer,
> > 2.	A piece of keying information to be used
> > 3.	A set of permissions for operations for the service consumer.
> > 
> > Each of these data items could be created by either the consumer or 
> > provider at any point during the enrollment process.
> 
> In my prototypes I've found that in addition to distributing 
> this introductory material to any interested additional 
> security services it has also been useful to allow such 
> services to provide their own introductory material during 
> the exchange. 
> 
> I guess I'm suggesting that the phrase "and to allow for 
> additional security services to be provided any information 
> exchanged" to be changed to something like "Additional 
> security services may provide additional 3tuples of 
> introductory material to be exchanged at the same time, or 
> may recieve copies of the primary material." 
> 
> Starts to sound unwieldy and may not be an important 
> clarification at this level. 

I would rather argue this out in the framework document, but I see what
you mean.

> 
> 
> > 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 bare asymmetric key
> > 3.	A bound asymmetric key (e.g. an X.509 certificate).
> 
> Plus one document describing the framework as a whole?

"and create a document for a framework..." is already there.

> 
> Thanks,
> 
> 	- Max
> 
> > As part of the validation of the framework, the group will 
> examine how 
> > other real world enrollment procedures could be profiled.  
> (An example 
> > of this would be credit card usage.)
> > 
> > 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
> > 
> > _______________________________________________
> > ietf-enroll mailing list
> > ietf-enroll at mit.edu 
> > https://mailman.mit.edu/mailman/listinfo/ietf-enroll
> 
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu 
> https://mailman.mit.edu/mailman/listinfo/ietf-> enroll
> 

Jim