[ietf-enroll] Charter

[Max Pritikin]

About credit cards (see below),

On Thu, 1 May 2003, Jim Schaad wrote:

> Paul,
>
> A couple of comments in line.
>
> jim
>
> > -----Original Message-----
> > From: ietf-enroll-bounces at mit.edu
> > [mailto:ietf-enroll-bounces at mit.edu] On Behalf Of Paul Hoffman / VPNC
> > Sent: Thursday, May 01, 2003 8:33 AM
> > To: jimsch at exmsft.com; IETF-Enroll
> > Subject: Re: [ietf-enroll] Charter
> >
> >
> > I wasn't at the BOF, but this sounds useful and not difficult if we
> > can keep religion about which of the three types of credentials is
> > "better" for everyone.
> >
> > Jim's proposed charter sounds good. Minor notes:
> >
> > >When doing enrollment of a user against a service provider, three
> > >pieces of information need to be provided or created in order to
> > >support authentication of the user to the provider and to allow for
> > >additional security services to be provided any information
> > exchanged.
> > >These pieces of data are:
> > >
> > >1.	The name of the entity being enrolled,
> >
> > I prefer "identity" over "name". An email address or an IP address is
> > an identity, but not a name.
>
> I am agnositic on this term.  My main problem with identity is that, for
> me, it implies actual knowledge of who is on the other side.  But I can
> see people making the same argument on name.  One term that I consdered
> using here, and I see is in my vocabulary list is "Entity Label".  Would
> you consider this as a better term?
>
> >
> > >2.	A piece of keying information to be used
> > >3.	A set of permissions for operations for the entity being
> > >enrolled.
> >
> > I'm not sure why this is here. If I understand the list above, the
> > protocol looks a bit like:
> >
> > Alice: "I'm Alice, here is my keying material, and I want the set of
> > permissions called A."
> > Bob: "I agree with your keying material, therefore I agree you are
> > Alice and you get permissions A."
> >
> > A different model that I think is even more common and
> > expected would be:
> >
> > Alice: "I'm Alice, here is my keying material; what
> > permissions do I get?"
> > Bob: "I agree with your keying material, therefore I agree you are
> > Alice, and I give you permissions A."
> >
> > If people agree with that description, then #3 above is not needed.
>
> I consider both models to be acceptable within the framework.  Sometimes
> there is only one thing that can be asked for, some times the enrollee
> wants to ask for certain privelges and some times the enroller wants to
> say that only some things (which can change over time) can change.
>
> >
> > >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:
> > >
> > >1.	A shared secret key
> > >2.	A base asymmetric key
> >
> > I think that is supposed to be "A *bare* symmetric key", yes?
>
> Yes.
>
> >
> > >3.	A bound asymmetric key (e.g. an X.509 certificate).
> > >
> > >Additionally, the group will consider the case of using a
> > credit card
> > >profiling the framework.
> >
> > I don't like limiting it to credit cards. How about "external,
> > human-based trust (such as credit cards)"?
> >
>
> I actually just tossed this in as a last minute thought to see if I got
> some discussion.  I think that we should be able to model real world
> transactions and this was an example of one that we should make sure
> that we could do.  I don't care about limiting it to just credit cards,
> but this is not directly involved in the primary mission of the group.

Credit cards themselves should not be a primary mission. But this
highlights the important of a model like the introduction mechanisms I
just sent out some notes about.

This is a case where the Introducer (user) is leveraging their credit
card as key material between themselves and the Registrar (service
provider). This is should be perfectly acceptable (and is - using the
transitive introduction model) without requiring any specific support from
the device being brought into the new trust relationship.

I think it is important to solve the introduction and enrollment problem
without specifying particular types of credentials end to end.

	- Max

> > >Goals and Milestones:
> > >
> > >Sept 2003	First draft of model
> > >Dec 2003	Last call on model document
> > >Nov 2003	First draft of Framework document
> > >April 2004	Last call on module document
> > >March 2004	First draft of secret key profile
> > >March 2004	First draft of bare asymmetric key profile
> > >March 2004	First draft of bound asymmetric key profile
> > >Aug 2004	Last call on secret key profile
> > >Aug 2004	Last call on bare asymmetric key profile
> > >Aug 2004	Last call on bound asymmetric key profile
> >
> > Looks good to me.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium _______________________________________________
> > ietf-enroll mailing list
> > ietf-enroll at mit.edu
> > https://mailman.mit.edu/mailman/listinfo/ietf-> enroll
> >
>
> _______________________________________________
> ietf-enroll mailing list
> ietf-enroll at mit.edu
> https://mailman.mit.edu/mailman/listinfo/ietf-enroll
>