Re: Proposed Enroll Charter

[Harald Tveit Alvestrand <harald@alvestrand.no>]

some comments inline, mostly questions for clarification....

--On 24. september 2003 16:35 -0400 Russ Housley <housley@vigilsec.com> 
wrote:

> Chairs:	Eric Rescorla
>   		Paul Hoffman
>
> Security Advisor:
> 		Don Eastlake

a very interesting triplet of personalities!

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

I have problems parsing. You MAY mean:

"There are many cases where a service consumer needs to contact a service 
provider to get credentials that the consumer can use when accessing the 
service; part of this initial contact may involve the consumer and the 
provider mutually validating the other's identity."

"This working group will look at some of the cases where cryptographic 
algorithms are used as part of the procedure for validating the identities."

But another interpretation is that the enrollment procedure creates the 
identity, and that validation is what happens when you use the service.

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

I think you mean an identifier, within a namespace controlled by the 
service provider, for the service consumer. But I'm not sure.

> 2.	A piece of keying information to be used

to be used for the interchange of identity-validation information, or to be 
used for the use of service?

> 3.	A set of permissions for operations for the service consumer.

To be used for letting the provider know what services the consumer wants 
to access, letting the consumer know what services he is being allowed 
access to, or both? Or does this refer to data items kept within the 
service provider, to be checked when the consumer tries to use the service?

> Each of these data items could be created by either the consumer or
> provider at any point during the enrollment process.
>
> 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:

I think you mean "for the following types of keying material".

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

I can't map credit card information to any of the 3 pieces of data 
mentioned above, so I take it that it's part of the input to the enrollment 
process, not part of the output. "usage of a credit card as input to the 
enrollment process"?

I think the work looks sensible, if I understand it - but this is an area 
where things can be particularly esoteric, so trying to map it down to 
short words for general consumption is probably a Good Thing.

Nit: No words about documenting the threat models and the resulting 
security considerations? :-)

                  Harald