[ietf-enroll] Charter

[Trevor Freeman]

Can you be more specific? I have also read the SACRED charter and I
don't see the overlap. ENROLL is targeting negotiation to reuse existing
credential or get new credentials. We are not making any assertion about
what comprises the starting set of credentials or how they get to any
given point in the network. 

Trevor

-----Original Message-----
From: ietf-enroll-bounces at mit.edu [mailto:ietf-enroll-bounces at mit.edu]
On Behalf Of Alper Yegin
Sent: Tuesday, May 27, 2003 11:53 AM
To: Russ Housley; jimsch at exmsft.com; IETF-Enroll
Subject: Re: [ietf-enroll] Charter


Reading the charter of SACRED, and messages on this mailing list, I
think
there may be some overlap between the ENROLL protocol and server-based
SACRED protocol. The end-result might be some protocol re-use between
the
two. Note that IPSRA was being considered for both protocols at some
point.

Alper

> SACRED is about credential portability.  ENROLL is about getting the
> credential in the first place.
> 
> Russ
> 
> 
> At 10:33 PM 5/25/2003 -0700, Alper Yegin wrote:
> 
> 
>> It'd be useful to understand how this work relates to or differs from
the
>> work SACRED WG is doing. Any comments on this?
>> 
>> Alper
>> 
>> On 4/28/03 12:03 PM, "Jim Schaad" <jimsch at nwlink.com> wrote:
>> 
>>> Here is a candidate charter for people to take shots at.
>>> 
>>> Description of Working Group:
>>> 
>>> There are many cases where a user 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 user against a service provider, three
pieces
>>> of information need to be provided or created in order to support
>>> authentication of the user to the provider and to allow for
additional
>>> security services to be provided any information exchanged.  These
>>> pieces of data are:
>>> 
>>> 1.    The name of the entity being enrolled,
>>> 2.    A piece of keying information to be used
>>> 3.    A set of permissions for operations for the entity being
>>> enrolled.
>>> 
>>> 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 base asymmetric key
>>> 3.    A bound asymmetric key (e.g. an X.509 certificate).
>>> 
>>> Additionally, the group will consider the case of using a credit
card
>>> profiling the framework.
>>> 
>>> 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
> 
> 

_______________________________________________
ietf-enroll mailing list
ietf-enroll at mit.edu
https://mailman.mit.edu/mailman/listinfo/ietf-enroll