[ietf-enroll] Proposed revision to the charter wording

[Paul Hoffman / VPNC]

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.

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

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,
credit card information might be part of the input to the enrollment
process.

==========


--Paul Hoffman, Director
--VPN Consortium