[lamps] [TLS] Q: Creating CSR for encryption-only cert?

Thu Oct 6 09:59:38 UTC 2022

Hi Thom, Uri, et al,

I had responded to Uri on the openssl-users list on Oct 3rd at 21:12 +0200 as follows:

Requesting a cert in a CSR for a key pair that cannot be used for signing is indeed impossible in the widely used PKCS#10 format
(except if one break sthe PKCS#10 requirement of a self-signature, e.g., by applying a dummy signature).

A viable solution is to use a different CSR format, such as CRMF.
This format is the preferred one by CMP and CMC (while they also support PKCS#10) because it is much more flexible.
CRMF does not strictly require to provide a proof-of-possession (PoP), and it offeres also indirect ways of doing a PoP.
For instance, for encryption keys the new cert can be returned by the CA in encrypted form (using the new public key) to the EE,
and the EE will only be able to make use of the cert if it is able to decrypt it, which proves possession of the private key.

Here are two additions to that:

In order for the CA to actually get the PoP for encryption-only keys, the EE needs to receive a strong value
derived from the decrypted contents of the new cert, such as a hash value of the decrypted cert.
In CMP this is achieved using the certConf message (which the CA acknowledges, as usual, with a pkiConf response).
See also https://www.rfc-editor.org/rfc/rfc4210#section-5.2.8

This procedure actually works with OpenSSL 3.0 and the Insta Demo CA, but so far only for RSA keys:

  export OPENSSL_CONF=/path/to/openssl/apps/openssl.cnf  # adapt as needed

  openssl genrsa -out insta.priv.pem  # or any other way of generating key

  openssl cmp -section insta -popo 2  # 1 means SIGNATURE, 2 means KEYENC

And some responses to today's email by Thom:

On Thu, 2022-10-06 at 09:58 +0200, Thom Wiggers wrote:
Op di 4 okt. 2022 om 17:07 schreef Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu<mailto:uri at ll.mit.edu>>:
CSR is supposed to be signed by the corresponding private key to prove possession. Obviously, it cannot be done with a key such as described above. How is this problem addressed in the real world?  With AuthKEM and KEMTLS, how would these protocols get their certificates?

Yeah, that's something that came up a few times while we were working on KEMTLS (and it eventually resulted in this paper by Güneysu, Hodges, Land, Ounsworth, Stebila, and Zaverucha [1]). They also have some nice references for the kinds of attacks that "sloppy" issuance could lead to in Appendix A. I've not tried to work out if they apply to TLS/KEMTLS/AuthKEM, but ruling them out anyway because of the many applications of certificates seems worth it.
[1]: https://www.douglas.stebila.ca/research/papers/CCS-GHLOSZ22/

Not checking the PoP (if this is what you mean here) would not be a good idea.
What you MUST do in any case is source authentication of the EE being the cert requester (i.e., proof of origin of the request).

A different naive approach for issuance (that I have done zero security analysis on) could be simply creating the cert for key PK and encrypting it to a key encapsulated to PK. Then the owner of PK would need to decrypt the certificate; using it the first time immediately proves possession. Of course, in the real-world we also have things like CT logs and such; and it would be terribly annoying if I could spam you with CT log alerts for yourwebsite dot com. So this approach doesn't seem very favorable over a "fancy" ZKP or interactive approach.

This indirect way of doing the PoP is essentially what I wrote above, while CMP nicely encapsulates the two round trips needed in a transaction:

CMP:apps/cmp.c:2793:CMP info: using section(s) 'insta' of OpenSSL configuration file 'apps/openssl.cnf'

CMP:apps/cmp.c:1953:CMP info: will contact http://pki.certificate.fi:8700/pkix/

CMP:crypto/cmp/cmp_client.c:166:CMP info: sending IR

CMP:crypto/cmp/cmp_client.c:186:CMP info: received IP

CMP:crypto/cmp/cmp_client.c:166:CMP info: sending CERTCONF

CMP:crypto/cmp/cmp_client.c:186:CMP info: received PKICONF

CMP:apps/cmp.c:2004:CMP info: received 1 extra certificate(s), saving to file 'insta.extracerts.pem'

CMP:apps/cmp.c:2004:CMP info: received 1 enrolled certificate(s), saving to file 'insta.cert.pem'

We weren't aware of CRMF, so it seems I've got some reading to do as I write some paragraphs on KEM certificates in my PhD thesis :)

BTW, you may note that an update of RFC 4211 is in the pipeline:
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-algs
as well as an update of RFC 4210, as well as an industrial CMP profile and a new RFC on details of algorithms that may be used with CMP(+CRMF):
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-algorithms

Cheers,
David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221006/acbc1c38/attachment-0001.htm>