[ietf-enroll] Updated Charter

[Jim Schaad]

Bob,


> -----Original Message-----
> From: Robert Moskowitz [mailto:rgm-sec at htt-consult.com] 
> Sent: Tuesday, May 13, 2003 2:10 PM
> To: jimsch at exmsft.com; 'IETF-Enroll'
> Subject: Re: [ietf-enroll] Updated Charter
> 
> 
> Fixed my filters......
> 
> At 11:26 PM 5/11/2003 -0700, Jim Schaad wrote:
> 
> 
> >Description of Working Group:
> >
> >There are many cases where a service consumer needs to obtain 
> >credential
> 
> exchange credentials
> 
> Might be better wording?  Se below.
> 
> >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)
> 
> visa versa sounds like an exchange to me.

My problem with exchange is that in some cases the credentials might
flow one direction only, however obtain does seem to make this a one
directional flow of information.  

GROUP: Any ideas on words that might encompass both?

> 
> >  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.
> 
> created by either is better handled in an exchange than an obtain.
> 
> >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).
> >
> >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
> 
> This is perhaps a staffing issue, but seems like the 
> Framework can be well 
> underway once we have a 'good' draft of the model.  But hey, 
> it is always 
> good to beat dates.

My only issue was that if the model is not settled on, then the
framework document would be difficult to start and wanted to allow for
that.

> 
> >April 2004      Last call on module document
> 
> You mean Framework document?

Yes -- will fix.

> 
> >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
> 
> 
> Robert Moskowitz
> TruSecure Corporation
> Security Interest EMail: rgm-sec at htt-consult.com
>