Hi Ryan S.,
> Isn’t this effectively suggesting that a certificate, not a key, signs a > response? That doesn’t seem to square with any of the technologies in play. > That is, such an OCSP response would still be signed by the root’s private > key, which is the key issue here. My understanding is that the requirements surrounding the inclusion of the digitalSignature KU have in mind a theoretical client that will reject OCSP responses unless the client can build a certification path (through being presented such certificates through the “certs” field of the BasicOCSPResponse, local policy, etc.) where the signing key is certified to create digital signatures (i.e., KU includes digitalSignature). CAs are under an obligation to serve OCSP responses that will be accepted by this theoretical client, but we know from BR section 4.9.9 that CAs may employ OCSP delegated signing certificates to accomplish this. Do you agree that this is the goal of the requirements, or do you see it differently? > This approach would have significant comparability risk, for all the issues > that doppelgängers have to begin with, so it doesn’t seem to be functionally > any different. It seems like the goal is to work around the CPS issue, but > that wouldn’t address the underlying compliance issue, right? This solution would provide the theoretical client described above with sufficient information to verify the signature on the OCSP response, so I believe it does resolve both the compliance issue and the practical client interoperability issue. > Note: While the key reuse issue is the functional root problem, even ignoring > it, this option would have issues, in that the certs field of the > BasicOCSPResponse isn’t part of the signed data - it’s supplemental data. So > the signature is still not bound to the “new” certificate. Not sure why this matters here, because this is a general issue for all delegated OCSP signing; an attacker can mangle the response to strip out such information so that the client rejects the response. But if they can do that, they can likely just block the response entirely from ever being received by the client, achieving the same goal. Thanks, Corey From: Ryan Sleevi <[email protected]> Sent: Wednesday, December 22, 2021 2:02 PM To: Corey Bonnell <[email protected]> Cc: Ryan Dickson <[email protected]>; [email protected] Subject: Re: Root Replacement with digitalSignature Key Usage to Sign OCSP responses On Wed, Dec 22, 2021 at 1:37 PM 'Corey Bonnell' via [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > wrote: There may be a third option which avoids the complexity of OCSP delegated responder key management but resolves the compliance and potential client interoperability issues. The root can issue a self-signed end-entity OCSP responder certificate (same name + key as the root, but BC cA=False and EKU = id-kp-OCSPSigning and KU=digitalSignature, etc.) and all subsequently generated OCSP responses will include this certificate in the “certs” field of the BasicOCSPResponse. This will provide clients with the certificates necessary to validate the OCSP response signature, as they can build a certification path of root -> OCSP delegated responder certificate. Would such a solution also remediate the issues? Isn’t this effectively suggesting that a certificate, not a key, signs a response? That doesn’t seem to square with any of the technologies in play. That is, such an OCSP response would still be signed by the root’s private key, which is the key issue here. This approach would have significant comparability risk, for all the issues that doppelgängers have to begin with, so it doesn’t seem to be functionally any different. It seems like the goal is to work around the CPS issue, but that wouldn’t address the underlying compliance issue, right? Note: While the key reuse issue is the functional root problem, even ignoring it, this option would have issues, in that the certs field of the BasicOCSPResponse isn’t part of the signed data - it’s supplemental data. So the signature is still not bound to the “new” certificate. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186BB293880AC62EDBA14EF927D9%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
