I'd like to add that adding a challenge-response POP need to be built into protocols as well, not only in CSR formats/specification. Only adding a method for this to PKCS#10, without also specifying how it is to be used in ACME, CMP, EST and SCEP will most likely wreak total havoc.
/Tomas ________________________________ From: von Oheimb, David <david.von.ohe...@siemens.com> Sent: Friday, October 7, 2022 7:21 PM To: pgut...@cs.auckland.ac.nz <pgut...@cs.auckland.ac.nz>; Mike.Ounsworth=40entrust....@dmarc.ietf.org <Mike.Ounsworth=40entrust....@dmarc.ietf.org>; john.g...@entrust.com <john.g...@entrust.com>; tim.holleb...@digicert.com <tim.holleb...@digicert.com>; Tomas Gustavsson <tomas.gustavs...@keyfactor.com> Cc: morgan...@dataio.com <morgan...@dataio.com>; sp...@ietf.org <sp...@ietf.org>; tls@ietf.org <tls@ietf.org> Subject: Re: [lamps] [TLS] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert? CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email info...@keyfactor.com with any questions. Whether it is really worth requiring a PoP for keys that do not support signatures, when facing the - likely - drawback that a single round trip will no more be sufficient, is certainly debatable. I tend to think "yes" for both reasons mentioned below: * As Tim pointed out, omitting the PoP check can easily be exploited for nuisance and confusion. * As Mike and others point out in Appendix A of https://eprint.iacr.org/2022/703<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2022%2F703&data=05%7C01%7CTomas.Gustavsson%40keyfactor.com%7Cf4bea7dbc6b84f50202008daa8885e2c%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638007600934137258%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RvCAI%2BO%2Fb4vGlsP957fKaY40Zt9I4boyjN%2BzjEsG5W8%3D&reserved=0>, there are scenarios where requiring the PoP prevents an attack. Peter, the argument you gave below: I mean what actual attack that's been actively exploited in the real world will use of PoP prevent? We've been shipping raw PKCS #10's around for decades (with no PoP) without causing the collapse of civilisation. appears invalid to me because PKCS#10 requires a self-signature (at least, this is how they are understood/used by most implementations) and thus does provide a PoP - and maybe civilization has survived just because of that [;-)] Strictly speaking, it is invalid (also) because the absence of known real-world attacks does not prove that real attacks do not exist by now or cannot be found in the future. In any case, I'd like to remind again that much more important for the security of certificate enrollment is the proof of origin (PoO) of the CSR, i.e., source authentication of the cert requester. And this often neglected by naive users of PKCS#10 CSRs simply because it is not part of that structure (well, unless done indirectly in a convoluted way, (ab-)using special attributes like the challengePassword for a MAC-based POO, which most implementers neither know nor understand). The PoO topic is entirely independent of the key being issued and possibly used in a PoP. BTW, talking about non-signing keys, looks like we'd face similar trouble when using such keys for PoO of a CSR like when using them for PoP: a second message (containing a challenge response) by the requester to the CA will be needed. David On Fri, 2022-10-07 at 14:55 +0000, Tim Hollebeek wrote: It largely isn’t necessary. I like proof of possession for issuance, but mostly just to avoid nuisances. But this topic is widely misunderstood. I think if you took a poll of PKI professionals, you’d find that lots of them erroneously believe that issuance of a certificate certifies that the subscriber has the corresponding private key. It doesn’t (in most ecosystems). It just means the subscriber has asked for that particular public key to be associated with their identity. It’s not uncommon for security researchers to grab a prominent public key, for example, a public WebPKI root, get a certificate issued to themselves for it, and claim to have found a security hole, when the proper response is: “You don’t have the private key. What do you think you are able to do with that?” This comes up semi-regularly on mozilla.dev.security-policy. So I like proof of possession just to avoid those sorts of nuisance scenarios. If you can do it (e.g. in an automated issuance protocol), I think you should. But I also like not being forced to do proof of possession, because there are scenarios where being forced to do it makes things worse. They tend to involve things like offline systems where it’s easier to securely get a bare public key across an air gap than it is to attempt to sign and transport a CSR. There are probably others. There’s also the problem that there’s no standard for secure proof of possession for revocation, despite a number of us calling for one for years. This means losing control of your CSR can be dangerous as some Certification Authorities will accept them as proof of possession for revocation purposes. -Tim From: Spasm <spasm-boun...@ietf.org> On Behalf Of Mike Ounsworth Sent: Thursday, October 6, 2022 10:05 PM To: Peter Gutmann <pgut...@cs.auckland.ac.nz>; von Oheimb, David <david.von.ohe...@siemens.com>; John Gray <john.g...@entrust.com>; tomas.gustavs...@keyfactor.com Cc: sp...@ietf.org; morgan...@dataio.com; tls@ietf.org Subject: Re: [lamps] [TLS] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert? Hi Peter, We grappled with that same question in our recent work on non-interactive KEM PoPs, and I have to admit, came up emptier than we expected. See appendix A of: https://eprint.iacr.org/2022/703<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2022%2F703&data=05%7C01%7CTomas.Gustavsson%40keyfactor.com%7Cf4bea7dbc6b84f50202008daa8885e2c%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C638007600934137258%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RvCAI%2BO%2Fb4vGlsP957fKaY40Zt9I4boyjN%2BzjEsG5W8%3D&reserved=0> --- Mike Ounsworth ________________________________ From: Peter Gutmann <pgut...@cs.auckland.ac.nz<mailto:pgut...@cs.auckland.ac.nz>> Sent: Thursday, October 6, 2022 8:51:17 PM To: von Oheimb, David <david.von.ohe...@siemens.com<mailto:david.von.ohe...@siemens.com>>; John Gray <john.g...@entrust.com<mailto:john.g...@entrust.com>>; Mike Ounsworth <mike.ounswo...@entrust.com<mailto:mike.ounswo...@entrust.com>>;tomas.gustavs...@keyfactor.com<mailto:tomas.gustavs...@keyfactor.com> <tomas.gustavs...@keyfactor.com<mailto:tomas.gustavs...@keyfactor.com>> Cc: sp...@ietf.org<mailto:sp...@ietf.org> <sp...@ietf.org<mailto:sp...@ietf.org>>;morgan...@dataio.com<mailto:morgan...@dataio.com> <morgan...@dataio.com<mailto:morgan...@dataio.com>>;tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>> Subject: Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert? A general question, motivated by "I need a different hammer because the one I'm currently using isn't able to pound screws in properly": Why is PoP actually required? And by this I don't mean "why is it in theory a good thing", I mean what actual attack that's been actively exploited in the real world will use of PoP prevent? We've been shipping raw PKCS #10's around for decades (with no PoP) without causing the collapse of civilisation. Peter. Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
