[ietf-enroll] Proposed revision to the charter wording

[Eric Rescorla]

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

This change works for me.

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

This works for me.

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

I can live with this, but I'd like to have the procedures first,
protocols second. I'm ok with either:

(1) 2 deliverables with a dependency and not work on the second
    till the 1st is complete.
(2) Recharter.

Paul?
-Ekr