[ietf-enroll] Proposed revision to the charter wording

[Max Pritikin]

Thanks Paul (and co).
Some comments inline,

	- Max

On Thu, 2003-12-11 at 16:53, Paul Hoffman / VPNC wrote:
> Greetings again. After looking through the notes from the WG meeting 
> and comments on the mailing list, Eric Rescorla and I have come up 
> with this proposed new wording for the charter. We tried to remove 
> the part about "identity", emphasize that this is for initial 
> enrollment (not long-term enrollment in the style of PKIX), and to 
> generally tighten up some of the ambiguous language.
> 
> Please read through this and comment on the list. Even though the WG 
> is chartered, we agree that re-chartering to match the desires of the 
> active participants is important, and should be done now, not a year 
> from now (which is more common in bad IETF WGs...).
> 
> ==========
> 
> 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 authorization. This working
> group will look at how these initial contacts and authorizations can be
> leveraged into a medium and long term cryptographic credential for
> future authentications.

How about, "... leveraged to establish an independent ..."

I'm not sure about the word 'independent', what I mean is the longer
phrase "a local significant credential with no dependancies on the
continued security of the introduction credentials and mechanisms". In
other words this is not a new credential chained off the prior
credentials but a truely new credential (with perfect forward secrecy).

> 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 future authentication of the service consumer to the service
> provider (and vice versa). These pieces of data are:
> 
> 1. An identifier, within a namespace controlled by the service
>     provider, for the service consumer.
> 2. Keying information to be used for authorization confirmation.
> 3. A set of service consumer permissions and other attributes.
>     The permissions describe to the provider the services that the
>     consumer wants to access and is authorized to access. They describe
>     to the consumer what services offered by the provider will be
>     accessible.  The other attributes are other pieces of data that are
>     created during the credential creation process and associated with
>     the consumer, but that do not fit into the description of a
>     "permission".

How about, "For example enrollment protocol or management specific
configuration information along the lines of "contact this host using
this enrollment protocol and present your enrollment credentials to
obtain your independent credentials. Afterward use those credentials and
this management protocol to obtain further instructions."

(Same comment as above concerning 'independent').

> Each of these data items could be created by either the consumer or
> provider at any point during the initial enrollment process.
> 
> This group will create a model to be used in describing initial
> 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 types of keying material:
> 
>     1. A shared secret key.
>     2. A bare asymmetric key.
>     3. A bound asymmetric key (such as 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. For example,

As stated in the meeting I strongly feel this should be "procedures and
protocols". A complex procedure that can not be built into code will not
help end users do deployments.

	- Max

> credit card information might be part of the input to the enrollment
> process.
> 
> ==========
> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu
> https://mailman.mit.edu/mailman/listinfo/ietf-enroll