Subject: [pkix] cert enrollment requirements

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Apr 2011 16:56:19 -0400

Max,

I think we (you?) should start to enumerate requirements for this 
protocol, based on a set of scenarios.  I suggest that we begin with 
an outline that enumerates examples of what we MUST support, and then 
discusses characteristics that we want from the protocol, and 
going-in assumptions about ways to satisfy the requirements and meet 
the design goals.

What kinds of subjects do we plan to support: people and devices?

Do we require people have crypto tokens, or not?
If we require a token, does the token need to have an embedded 
processor, like a smart card?

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

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

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

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

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

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

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

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

Steve

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 05 Apr 2011 04:41:43 +0200

Steve,

Now you rock!
Really good questions all the way.

Anders

On 2011-04-04 22:56, Stephen Kent wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Thierry Moreau <[email-masked]>
Date: Tue, 05 Apr 2011 10:19:12 -0400

Stephen Kent wrote:
> protocol, based on a set of scenarios.  I suggest that we begin with an 
> outline that enumerates examples of what we MUST support, and then 
> discusses characteristics that we want from the protocol, and going-in 
> assumptions about ways to satisfy the requirements and meet the design 
> goals.
> 
Just to let you glimpse at what the world looks like when PKC 
capabilities are viewed outside of the PKI straight jacket, here are my 
quick responses.

> What kinds of subjects do we plan to support: people and devices?
Two related things: people authenticated through a device (PKC capable), 
and devices installed with a human-operator-in-the-loop (provisioning 
without human witness is not in the present enrollment scope).

> processor, like a smart card?
A local issue. See answer to next question.

> processors, ...) do we support?
PKC capable in some sense.

> How do subjects authenticate to issuers, e.g., PIN/password, device 

Enrollment:
Step 1: subject submits anonymous contextual information, namely a 
one-time pass query, protected by an enrollment clearinghouse TA
Step 2: subject-related information sent in a secure session where the 
server authenticity is ascertained in part by the one-time pass query

Production:
By the subject PKC key pair established during enrollment (ah yes, 
enrollment did securely establish a secure authentication relationship 
in addition to just pretend you did)

> realtime or will we support staged delivery as well?
On-line capabilities are quite common these days, aren't they? So, no 
requirement to limit the number of round-trips in the protocol. Actually 
enrollment step 1 requires a small number of round-trips.

> What cert management functions will we support: cert request, renewal, 
> rekey, revocation request, ...?
> 
Impulsively, none of those, just enroll your credentials and use them 
with first party verifier. Actually, I list "PKC enrollment 
requirements" and not "PKI cert enrollment requirements", and I do list 
them just as an example of how things may be looked at by taking a 
broader perspective.

> 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 :-).)
> 
The answer is in the question. But it's a fun question anyway. May I 
suggest that the IESG algorithm  agility mandate be fulfilled with 
agility among RSA and Rabin-Williams? Out of sheer laziness, I'm a bit 
too ignorant of discrete log / ECC cryptosystem family, and maybe I'm 
not the only designer with this attitude.

> Will we support PoP for subject keys? (again, a trick question :-).)
PoP is achieved with the crypto/protocol potential of combined 
enrollment steps 1 and 2 above.

> Do we assume that the issuer has an X.509 CA cert?
Yes, for issuer authentication during enrollment step 2. But its 
criticalness is limited to MITM attacks, not the easier phishng/pharming 
attacks.

> This is just a start, but these are the types of questions that need to 
> be answered if we are to make progress.
> 
Making progress with PKI enrollment without considering bare PKC 
capabilities first (and foremostly?) appears indeed somehow challenging.

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

---

From: max pritikin <[email-masked]>
Date: Tue, 5 Apr 2011 15:41:48 -0600

On Apr 4, 2011, at 2:56 PM, Stephen Kent wrote:

> Max,
> 
> I think we (you?) should start to enumerate requirements for this protocol, based on a set of scenarios.  I suggest that we begin with an outline that enumerates examples of what we MUST support, and then discusses characteristics that we want from the protocol, and going-in assumptions about ways to satisfy the requirements and meet the design goals.

I'll use these threads and my own ideas to put together a section on requirements so that folks can provide concrete suggestions against a formal document. 

My initial thoughts are inline in response to your excellent questions,

> What kinds of subjects do we plan to support: people and devices?

Yes. As follows,

S1. People - During enrollment authentication/authorization of only the person is necessary.(Obviously a device is involved for storage and protocol communication but in this case the user is the authenticated entity during enrollment and the resulting certificate likely indicates the user as the subject. 

S2. Devices - During enrollment device is authenticated/authorized and the resulting certificate likely indicates the device as the subject. 

S3. People & Devices - During enrollment both the user and the device are authenticated/authorized. The server has sufficient information to indicate within the issued credential a combined subject although specifications concerning the issued credentials are out of scope.

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

We should not require this at all, it is the CA that enforces a policy decision of this type. We should provide sufficient information to the enrollment server to allow this form of policy check. For example see S3 above. 

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

Thierry's response is my first thought: "PKC capable in some sense". A better question might be to ask if there are any devices we want to exclude (Answer: no). Thus the value of S1 because it is completely independent of device authentication/authorization. 

It is still the server policy responsibility to add additional restrictions - but that policy is out of scope of the enrollment protocol itself.

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

This closely parallels the question on subjects. We'll need methods that provide reasonable flexibility for the subjects targeted. As per my discussions on thread I feel we can limit ourselves to a small set of very common methods with extensibility for *future* options. I don't feel we need to invent anything really new.

A1. username/password

A2. password/PIN (w/o an associated username)

A3. existing certificate (device based or other)

A4. A combination of A1+A3 or A2+A3.

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

Again, I agree with Thierry: Realtime connections are prevalent and we should focus on them. Existing protocols include more than sufficient complexities to support staged methods which has impacted their use for simpler realtime solutions.

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

Only the minimal subset necessary to join and maintain the key/certs necessary for all the other management functions. This is not a trust anchor management nor ongoing PKI management solution. This is minimum necessary for 

M1. Distribution of current CA credentials - necessary as a bootstrap method and for CA rekey/renew operations (which client needs in order to successfully renew/rekey itself). 

M2. Enrollment 

M3. Renewal/Rekey 

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

K1. Algorithm agility in all messages/methods.

K2. suite-b compatibility 

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

R1. PoP of subject keys 

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

Yes, but more specifically,

I1. Server only has a certificate from a "private" (self-signed) hierarchy. This is the common case of standing up a PKI by generating a self-signed certificate. 

I2. Server also has a certificate from a "common" (mutually trusted) hierarchy. In addition to being a member and enrollment server for the private hierarchy the server may also have a certificate issued by a mutually trusted hierarchy.

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

And as the list develops folks will be able to provide concrete textual suggestions or comments,

- max

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Apr 2011 11:16:43 -0400

At 3:41 PM -0600 4/5/11, max pritikin wrote:
>...
>I'll use these threads and my own ideas to put together a section on 
>requirements so that folks can provide concrete suggestions against 
>a formal document.

great, and I think your set of answers is a good start for a 
requirements doc discussion.

Steve

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 06 Apr 2011 17:46:13 +0200

If any meaningful exchange of ideas is to be performed on the
list it may be useful separating [hopefully] independent issues.

Here is such a topic.

In TPMs (Trusted Platform Modules) as well as when using that
fluffy term "Secure Messaging" (ISO GP SKS), self-signed requests
are either not not used at all or play a less significant role,
because it is rather the (trusted/trustworthy) *container* that
vouches for the authenticity of container-generated public keys.

The value of the traditional PoP in a scenario where the issuer
has no control, knowledge, or interaction with the crypto container
seems a bit exaggerated since anybody can create a key-pair.  In the
case the issuer has full control PoP appears slightly redundant.
Even if you know (how?) that the client has a trustworthy container,
PoP does not add much to verify that.

The potential PKIX effort is of course free to support whatever
"PoP" method you like, just beware of the fact that they are very
different with Secure Messaging as the extreme...

Anders

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Apr 2011 13:30:27 -0400

>vouches for the authenticity of container-generated public keys.

OK, but that is at most one scenario of what is to be supported.

>seems a bit exaggerated since anybody can create a key-pair.

the rationale for PoP is to establish that the requester of a
cert holds the private key corresponding to the public key in the
cert.

>  In the
>case the issuer has full control

Since the issuer is generally not the same entity as the creator
of the "container," PoP still makes sense. In fact, because
the container is not perfectly secure, if the interactions takes place
as a distance, the issuer can't be sure that the request has not been 
fabricated by a tampered container, so PoP makes sense even in that 
case.

>  PoP appears slightly redundant.

PoP does what I mentioned earlier, i.e., it counters requests that
attempt to associate someone else's public key with an identity not
selected by the holder of the private key.

Steve