Re: [pkix] EC key pair

[Erwann Abalea <[e-mail]>]

2015-04-01 9:02 GMT+02:00 Peter Gutmann <[e-mail]>:

> Erwann Abalea <[e-mail]> writes:
>
> >SCEP (as a draft) already supports enrolment of an EC public key with a
> >request encrypted to the RSA public key of the CA/RA.
>
> Uhh, no it doesn't:
>
>    The message types, being based on CMS [3] and PKCS #10 [6], fully
>    support algorithm agility but the requester has to use a key type
>    that is supported by the server.  Specifically, they must employ a
>    PKC algorithm capable of both encryption and signing.  RSA is the
>    only widely-used algorithm that has these properties.
>

Note the "as a draft", I'm not talking about specific implementations.
And in the first example, the CA/RA key is used as the recipient of the
envelopedData part of the CMS, and it works perfectly if the CA/RA has an
RSA key (that's classic). Still in that first example, the PKCS#10 can
enclose an EC public key, be self-signed, etc. Nothing strange here.
The result is only signed.

The second example will only work if you accept RFC5753 or a
derivative/similar work to exchange the symetric key used to encrypt the
payload of that envelopedData. This will involve ECMQV or ECIES, or any
other similar thing based on ECDH/EC-ElGamal.


> >But SCEP is so old that it's probably not the best idea to play with it
> and
> >EC keys. It was changed as "Historic" some years ago, and the latest draft
> >(september 2011) never went published.
>
> The latest draft is from March 2015.  It's also extremely widely deployed
> (unless someone knows of something non-proprietary that's bigger, I'll say
> it's the most widely-deployed cert enrolment protocol), so going with SCEP
> if
> you can manage it ensures widespread support for your whatever-it-is.
>

https://datatracker.ietf.org/doc/draft-nourse-scep/ lists the latest
version of the draft as 2011-09-07. I don't know where is this March 2015
version from.

-- 
Erwann.