Subject: Re: [pkix] cert enrollment requirements

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 5 Apr 2011 19:26:46 -0700 (Pacific Daylight Time)

My comments inline.

On Mon, Apr 4, 2011 at 1:56 PM, Stephen Kent <[email-masked]> wrote:
>
> What kinds of subjects do we plan to support: people and devices?

People and the property which Persons own.  In other words, people and not merely personal-property devices as you're contemplating, but also devices built into real property.

> Do we require people have crypto tokens, or not?

We require Persons to have their own crypto implementations and containers, but they should not be forced into any particular form factor.  These containers must understand the protocols we are creating.

We allow for a signature by a token-specific certificate (embedded by its manufacturer) which can certify under what conditions a given key was generated.

> If we require a token, does the token need to have an embedded processor,
> like a smart card?

The container must be able to have its own identity, separate from but subordinate to the Person who owns it.  The container also has other attributes which can be attested to independent of its owner's identity.

> What kinds of devices (end systems, network elements, embedded processors,
> ...) do we support?

Everything.

We need a means to enroll a key in the PKI of the issuer (which essentially means "add a key record and point it to my master information, using whatever policy and procedure you must"), we need a means to assert under what conditions a key was created, and we need a means to assert what minimum conditions a given issuer requires.

Those are the tasks for which we need data formats and semantics.  (Since we don't have a workable solution right now, we don't have to worry about interoperability with the numerous proprietary schemes.)

> How do subjects authenticate to issuers, e.g., PIN/password, device cert,
> OTP token, ...?

Device certificate is not used to authenticate a subject to an issuer, it's used to authenticate a device's assertion that it created a key in the manner required.

Subjects authenticate to issuers the way subjects authenticate to issuers now.  It's the workflow done under that authentication which needs to change.

> Will we support only those subjects that connect to an issuer in realtime or
> will we support staged delivery as well?

Staged delivery would be useful.  It would permit the issuer to be a completely separate empire from the customer-interaction team.

There is no need for realtime connection, because we're dealing with atoms on the wire -- things which cannot be further broken down without destroying their essential characteristic of verifiability.  Thus, we're dealing essentially with "blobs of information which need to move from one place to another".

> What cert management functions will we support: cert request, renewal,
> rekey, revocation request, ...?

enroll, renew, rekey, disenroll

We can also support additional cert management functions (like "ensure that the person's really serious about enrolling this key by requiring a signature by the person's enrollment key on top of the person's identity key") if we stop thinking in terms of bits and start thinking in terms of "what information does this entity need?  Now, what form do we want to create to get that information to that entity?"

> WIll we support only RSA keys for the subject, or will sig-only alg keys or
> key-agreement only alg keys be ok too? (Hint: since algorithm agility is now
> mandated by the IESG, RSA-only is NOT a viable answer :-).)

There is no reason we have to even think about anything other than algorithm-agnosticism, or format-agnosticism.  SubjectPublicKeyInfo is a well-defined system, as is Signature.  Even if they weren't, OpenPGP has a need to provision keys too, and it is standard enough that it should be contemplated in what we're doing here.  There is no reason to include details from one protocol in any other. 

> Will we support PoP for subject keys? (again, a trick question :-).)

Even PKCS#10 supports and mandates Proof of Possession, which moves this out of the realm of 'trick question' and into the realm of 'belabored point'.

> Do we assume that the issuer has an X.509 CA cert?

There's no need.  All we have to do is get the subject's assertions about his key and his authority to request the enrollment of the key to the issuer, and then get the issuer's authentication credentials to the subject, to back up the issuer's assertions about the subject.

The real question is:  Do we assume that the goal is to provide a PKIX-format-derived certificate to the subject?  Or do we assume that the goal is to securely provision a device's enrollment into whatever form of PKI exists for the subject and relying party?

Do we assume that the purpose of this kind of protocol is to convey identity information to enroll in a PKI?  Or, do we assume that this protocol can be useful for things other than the state identity purpose conceived and standardized (currently in RFC5280) by this group?  (This is something of a trick question -- bank account numbers are just as much 'identity' as our legal names are.  They differ only because they refer to the records kept about a particular ongoing relationship by a private entity, as opposed to the records kept about a particular life-long relationship by a state entity.)

> This is just a start, but these are the types of questions that need to be
> answered if we are to make progress.

I wholeheartedly agree.  Thank you for starting the discussion.

-Kyle H