<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>Hi Thom, Uri, et al,</div>
<div><br>
</div>
<div>I had responded to Uri on the openssl-users list on Oct 3rd <span style="font-size: 14.666667px;">at 21:12 +0200 as follows:</span></div>
<div><br>
</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">
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<span class="Apple-converted-space"> </span></div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">
(except if one break sthe PKCS#10 requirement of a self-signature, e.g., by applying a dummy signature).<span class="Apple-converted-space"> </span></div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">
<br>
</div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">
A viable solution is to use a different CSR format, such as CRMF.<span class="Apple-converted-space"> </span></div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">
This format is the preferred one by CMP and CMC (while they also support PKCS#10) because it is much more flexible.<span class="Apple-converted-space"> </span></div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">
CRMF does not strictly require to provide a proof-of-possession (PoP), and it offeres also indirect ways of doing a PoP.<span class="Apple-converted-space"> </span></div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">
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,<span class="Apple-converted-space"> </span></div>
<div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Cantarell; font-size: 14.666667px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tap-highlight-color: rgba(0, 0, 0, 0.4); -webkit-text-stroke-width: 0px; text-decoration: none;">
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.</div>
</blockquote>
<div><br>
</div>
<div>Here are two additions to that:</div>
<div><br>
In order for the CA to actually get the PoP for encryption-only keys, the EE needs to receive a strong value </div>
<div>derived from the decrypted contents of the new cert, such as a hash value of the decrypted cert.<br>
In CMP this is achieved using the certConf message (which the CA acknowledges, as usual, with a pkiConf response).</div>
<div>See also <a href="https://www.rfc-editor.org/rfc/rfc4210#section-5.2.8">https://www.rfc-editor.org/rfc/rfc4210#section-5.2.8</a></div>
<div><br>
</div>
<div>This procedure actually works with OpenSSL 3.0 and the Insta Demo CA, but so far only for RSA keys:</div>
<pre>  export OPENSSL_CONF=/path/to/openssl/apps/openssl.cnf  # adapt as needed</pre>
<pre>  openssl genrsa -out insta.priv.pem  # or any other way of generating key</pre>
<pre>  openssl cmp -section insta -popo 2  # 1 means SIGNATURE, 2 means KEYENC</pre>
<div><br>
</div>
<div><span></span></div>
<div><br>
</div>
<div>And some responses to today's email by Thom:<br>
<br>
</div>
<div>On Thu, 2022-10-06 at 09:58 +0200, Thom Wiggers wrote:</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div dir="ltr">
<div>Op di 4 okt. 2022 om 17:07 schreef Blumenthal, Uri - 0553 - MITLL <<a href="mailto:uri@ll.mit.edu">uri@ll.mit.edu</a>>:</div>
<div class="gmail_quote">
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div>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?<br>
</div>
<br>
</blockquote>
<div><br>
</div>
<div>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.<br>
[1]: <a href="https://www.douglas.stebila.ca/research/papers/CCS-GHLOSZ22/">https://www.douglas.stebila.ca/research/papers/CCS-GHLOSZ22/</a></div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Not checking the PoP (if this is what you mean here) would not be a good idea.<br>
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).<br>
<br>
</div>
<div><br>
</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_quote">
<div>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. </div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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:<br>
<br>
</div>
<pre>CMP:apps/cmp.c:2793:CMP info: using section(s) 'insta' of OpenSSL configuration file 'apps/openssl.cnf'</pre>
<pre>CMP:apps/cmp.c:1953:CMP info: will contact <a href="http://pki.certificate.fi:8700/pkix/">http://pki.certificate.fi:8700/pkix/</a></pre>
<pre>CMP:crypto/cmp/cmp_client.c:166:CMP info: sending IR</pre>
<pre>CMP:crypto/cmp/cmp_client.c:186:CMP info: received IP</pre>
<pre>CMP:crypto/cmp/cmp_client.c:166:CMP info: sending CERTCONF</pre>
<pre>CMP:crypto/cmp/cmp_client.c:186:CMP info: received PKICONF</pre>
<pre>CMP:apps/cmp.c:2004:CMP info: received 1 extra certificate(s), saving to file 'insta.extracerts.pem'</pre>
<pre>CMP:apps/cmp.c:2004:CMP info: received 1 enrolled certificate(s), saving to file 'insta.cert.pem'</pre>
<pre><br></pre>
<div><br>
</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>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 :)<br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>BTW, you may note that an update of RFC 4211 is in the pipeline:</div>
<div><a href="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-algs">https://datatracker.ietf.org/doc/html/draft-ietf-lamps-crmf-update-algs</a></div>
<div>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):</div>
<div><a href="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates">https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates</a></div>
<div><a href="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile">https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile</a></div>
<div><a href="https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-algorithms">https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-algorithms</a></div>
<div><br>
</div>
<div>Cheers,</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>David</div>
<div><br>
</div>
<blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_quote">
<div></div>
</div>
</div>
</blockquote>
</body>
</html>