[ietf-enroll] Updated Charter

[Max Pritikin]

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. 


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

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