[ietf-enroll] Updated Charter

[Jim Schaad]

Alper,

> -----Original Message-----
> From: Alper Yegin [mailto:alper at docomolabs-usa.com] 
> Sent: Monday, May 12, 2003 7:37 PM
> To: jimsch at exmsft.com; 'IETF-Enroll'
> Subject: Re: [ietf-enroll] Updated Charter
> 
> 
> Hello,
> 
> Here are some comments........
> 
> > 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.
> 
> We should explicitly note if we are talking about the initial 
> contact between the client and service provider (not each 
> time client requests the service).

Let me think on this.

> 
> > 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,
> 
> "service consumer". maybe we should call it "client", simpler 
> and more familiar term.

Actually I went to "service consumer" just to get away from the familiar
term at this time.  To many people "client" implies a person, and we
want to deal with a "client machine" as well.

> 
> A short enumaration of types of services would help, just as 
> examples...

I think this goes into the model document and not the charter.

> 
> > 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,
> 
> What is this supposed to be? A dynamic identifier assigned to 
> the client by the service provider?

It could be assigned by either the comsumer or provider.

> 
> > 2.    A piece of keying information to be used
> > 3.    A set of permissions for operations for the service consumer.
> 
> #3 sounds like "authorization parameters.", is that right?

No - It could be a list of desired services if sent from consumer to
provider.

> 
> > Each of these data items could be created by either the consumer or 
> > provider at any point during the enrollment process.
> 
> Saying each can be determined by any parties might be 
> misleading. For example, authorization parameters cannot be 
> solely determined by the client. The service provider has to 
> at least agree with what the client proposes.

This would be refined in the model document.

> 
> > 
> > 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.
> 
> I think we are talking about dynamically performing enrolment 
> over the network. If so, we should clearly state that. A  
> counter example, which fits the above text but (I hope) not 
> our intentions is: Making the credentials available on a 
> SIM/smart card, client buys the card from a store, and 
> inserts in to the device, done.

This is one of the possible senerios that we need to be looking at.

> 
> > 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).
> 
> I assume the above list means "enrolment procedure in the 
> presence of , say, a shared secret key between the client and 
> the service provider." , etc. It'd be useful to explicitly state this.

No, what this means is that the cryptographic key used for later
authentication is a shared key,....

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