[ietf-enroll] Proposed revision to the charter wording

[Max Pritikin]

Please see below,

On Thu, 2003-12-11 at 19:04, Eric Rescorla wrote:
> > 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.

I misread, and then mis-spoke (-typed? -toped?). I'm fine with the
original text here. 

Although you correctly perceived what I was getting at.

I meant to point out that the model delivered should be appropriate for
protocol development, as much as a description of enrollment process. 
I'd like this to be stated because I believe it will add (necessary)
complexity to the resulting model. I would hate to have us deliver a
model that, while simple, did not help the protocol development phase. 

I can agree that a description of the procedures/model should come
first. Either as stated above in (1) or (2).

	- Max

> 
> Paul?
> -Ekr