Subject: [pkix] Certificate Renewals in PKIX Protocols

From: Anders Rundgren <[email-masked]>
Date: Sun, 24 Jul 2011 19:11:26 +0200

This is a question to the list.

If you create an initial certificate for a smart card in a trusted environment you
you should be able to tell with a high certainty that the key-pair actually was
created in the smart card, right?

Now, if you perform a certificate renewal, the original key is supposed to
vouch for the authenticity of the request, right?   Here I feel slightly less
convinced since anybody can create a key-pair and get it signed.

Does any of the PKIX enrollment protocols support secure renewals in
the field?  Is it even possible without having an attestation mechanism
that is securely distinguishable from ordinary signatures?

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 16:39:17 +1200

Anders Rundgren <[email-masked]> writes:

>If you create an initial certificate for a smart card in a trusted
>environment you you should be able to tell with a high certainty that the
>key- pair actually was created in the smart card, right?

Not necessarily.  In some cases the keys are generated externally and loaded
into the card to save time.

(This was a serious problem a while back when I refused to accept keys that
weren't generated on the card, at which point I found out just how many cards
did their keygen on the host PC (in the card driver) because doing it on the
card was too slow.  Some drivers also lied about this, claiming on-card
generation when it was on the host PC).

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 07:32:41 +0200

> generation when it was on the host PC).

If the trusted environment is a card production facility this is IMO
perfectly OK but that wasn't the issue.  My question was really about
*renewals* when the trust level is reduced, like in the field or when
a device is doing unmanned renewals.

A IMHO weird example of the latter is the ICAO/BSI scheme for EAC
(Extended Access Control) used by all governments in the world (!)
where they require that keys must reside in HSMs but be automatically
renewed on a frequent basis.  Since HSMs usually can't attest
"I did this key" (and there is no place in the protocol for such an
attestation either...), IMO makes the HSM "prescription" dubious since
the renewal system isn't tamperproof.

I may be wrong, but it *seems* that PKIX protocols  lack support for
secure renewals.

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 17:44:37 +1200

Anders Rundgren <[email-masked]> writes:

>I may be wrong, but it *seems* that PKIX protocols  lack support for secure
>renewals.

What specifically do you mean by "support"?  If you run the whole protocol in
the HSM (or whatever) and sign the new request with the old key, then you've
got what you want.  You'd need some means of signalling this, either
implicitly or via something like an OID in the request, but at that point it
becomes an ecumen^H^H^H^Hpolicy matter.

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 07:52:31 +0200

> becomes an ecumen^H^H^H^Hpolicy matter.

Peter, a $5 TPM can attest authenticity of generated keys using cryptographic
methods.  It can't run networked protocols.  I.e. the latter must "support"
the TPM's attestation capability if you want secure (with respect to key origin...)
renewals.

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 18:06:45 +1200

Anders Rundgren <[email-masked]> writes:

>the TPM's attestation capability if you want secure (with respect to key
>origin...) renewals.

But how would this work?  Is there any OS, or environment, in which TPM
attestation actually works?  Or to use a more specific example, Joe Sixpack is
running a Win7 laptop that happens to be one of the few with a TPM in it.
Then what?

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 08:22:01 +0200

> running a Win7 laptop that happens to be one of the few with a TPM in it.

In order for something to happen it must (in addition to filling
a need), also be technically feasible.  In this particular case
I claim that that there are fundamental things lacking, like attestation
support in PKIX protocols.

The majority of the 0.5 BN TPMs shipped had/have nothing to do.

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 18:59:26 +1200

Anders Rundgren <[email-masked]> writes:

>In order for something to happen it must (in addition to filling a need),
>also be technically feasible.  In this particular case I claim that that
>there are fundamental things lacking, like attestation support in PKIX
>protocols.

You still haven't explained what it is that you're going to attest.  PKIX
protocols all have extension support so you can add your own extension with
whatever semantics you want, but what're you going to attest?  That a TPM was
installed and powered on?

>The majority of the 0.5 BN TPMs shipped had/have nothing to do.

Only "the majority"?

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 09:20:09 +0200

On 2011-07-25 08:59, Peter Gutmann wrote:
> You still haven't explained what it is that you're going to attest.  

TPM: "I did this key".  With a dedicated attestation key.

> "PKIX protocols all have extension support so you can add your own extension with
> whatever semantics you want,

This was essentially the answer I was looking for.

I skimmed through the CMC RFC and didn't find a single reference to
"middleware", "cryptographic module", or "container".

PKIX: Yes, CMC is supposed to be entirely universal, stupid!
AR: You mean it doesn't fit anything *really* well?

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 19:24:26 +1200

>"middleware", "cryptographic module", or "container".

Presumably because it's agnostic to that sort of thing.  If you want
attestation that the TPM did the key, define an extension consisting of 
sign( key hash, TPM ID ) or whatever you want.

If the TPM can talk at a slightly higher level, you don't even need that, it
can sign its ID into the PKCS #10 request.

Peter.

---

From: Max Pritikin <[email-masked]>
Date: Mon, 25 Jul 2011 07:08:03 -0600

> created in the smart card, right?

Effectively the card must have an identity it can assert. The approach I've taken here is to assume a device certificate held by the card itself (something like IEEE 802.1AR). Thus the enrollment protocol needs to be able to leverage that ID in addition to the user's identity.

> that is securely distinguishable from ordinary signatures?

CMC doesn't define renew well although it can be implemented. CMP does a better job in this regard, but your concern seems to be less about the actual messages than how to use the messages when combined with a smart card. The SCEP implementations such as the iphone solution you've provided links to provides something that meets your initial certificate using a particular device (iphone instead of smart card) but SCEP does a very poor job as CA rekey.

I think we have the technology pieces in the various pkix protocols but not a clean discussion of how they should be used. (Thus my interest in EST, as a profile for clarification rather than inventing a bunch of new stuff).

- max

> 
> Anders
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 18:22:24 +0200

On 2011-07-25 15:08, Max Pritikin wrote:
<snip>
> I think we have the technology pieces in the various pkix 
> protocols but not a clean discussion of how they should be used.

It all depends on what your target audience is.  It is not
mentioned in the EST draft.

> (Thus my interest in EST, as a profile for clarification rather
> than inventing a bunch of new stuff).

Inventing a bunch of new stuff may turn out to be easier than
[insanely] extending something that was designed in another
time and for another purpose.

For some people new options mean "an opportunity" for other
people it means just "another way of screwing up".

The trust anchor stuff recently discussed is an example.
According to Dr. Kent vendors SHOULD (or MUST) also support
TAs that are not X.509 certificates.  However, only a tiny
fraction do that.  Who is wrong, the RFC or the Vendors?
>From my user/vendor perspective the RFC is wrong.  There
MAY be other TA forms had been more reasonable.

Anders