Re: [pkix] Derived Credentials. Was: Simple Certificate Enrollment Protocol (SCEP)

[Anders Rundgren <[e-mail]>]

On 2014-11-12 18:45, Johannes Merkle wrote:
> Anders Rundgren wrote on 12.11.2014 10:25:
>
>> AFAICT, end-to-end security with respect to the *key-container* is outside of all
>> PKIX enrollment protocols.
>
> you have stated that several times but still I don't understand the issue. Could you please elaborate on that? What
> exactly do you mean by "end-to-end security with respect to the key-container" and how should it be solved?
>

SM (Secure Messaging) is a standard feature in cards conforming to GlobalPlatform specifications.
Neither PKIX protocols, nor PKCS #11 support SM.

What it means is that you during provisioning have like a "TLS" channel with
the key container itself so that you know that the keys actually resides in the
designated device.

Regarding how to solve it, Google have managed in record-time gather just about
everybody from platform vendors, smart card manufacturers to VISA around their
U2F-concept which *presumes* end-to-end-security provisioning.  Somewhat simplified
the cert-req is counter-signed by a built-in attestation key which for obvious
reason is only allowed to sign such data.

I guess Apple use something similar for Apple Pay.

Anders