[ietf-enroll] Updated Charter

[Alper Yegin]

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

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

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

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

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

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

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

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
>