<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<div style="font-family:sans-serif">
<span dir="ltr" style="margin-top:0; margin-bottom:0;"><small>Requesting a cert in a CSR for a key pair that cannot be used for signing is indeed impossible in</small> the widely used PKCS#10 format</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">(except if one break sthe PKCS#10 requirement of a self-signature, e.g., by applying a dummy signature).</span> <br> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">A viable solution is to use a different CSR format, such as CRMF.</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">This format is the preferred one by CMP and CMC (while they also support PKCS#10) because it is much more flexible.</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">CRMF does not strictly require to provide a proof-of-possession (PoP), and it offeres also indirect ways of doing a PoP.</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">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> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">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.</span> <br> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">David</span> <br> <br> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">On Mon, 2022-10-03 at 15:11 +0000, Blumenthal, Uri - 0553 - MITLL wrote:</span> <br>
<blockquote style="margin-top:0; margin-bottom:0;">
<span dir="ltr" style="margin-top:0; margin-bottom:0;">> TLDR;</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> Need to create a CSR for a key pair whose algorithm does not allow</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> signing (either because it’s something like Kyber, or because</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> restriction enforced by HSM). How to do it?</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> </span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> There are several use cases that require certifying long-term</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> asymmetric keys that are only capable of encryption/decryption – but</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> not signing/verification. That could be either because the algorithm</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> itself does not do signing, or because the private key is generated</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> and kept in a secure hardware that enforces usage restriction.</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> </span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> CSR is supposed to be signed by the corresponding private key to</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> prove possession. Obviously, it cannot be done with a key such as</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> described above. How is this problem addressed in the real world?</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> With AuthKEM and KEMTLS, how would these protocols get their</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> certificates?</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> </span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> Thanks!</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> -- </span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> V/R,</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> Uri Blumenthal Voice: (781) 981-1638 </span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> Secure Resilient Systems and Technologies Cell: (339) 223-5363</span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> MIT Lincoln Laboratory </span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> 244 Wood Street, Lexington, MA 02420-9108 </span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> </span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> Web: <a href="https://www.ll.mit.edu/biographies/uri-blumenthal">https://www.ll.mit.edu/biographies/uri-blumenthal</a></span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> Root CA: <a href="https://www.ll.mit.edu/llrca2.pem">https://www.ll.mit.edu/llrca2.pem</a></span> <br> <span dir="ltr" style="margin-top:0; margin-bottom:0;">> </span>
</blockquote>
</div>
</body>
</html>