We’re talking the former (re-signing a key used in a previous cert that was revoked by the CA itself for key compromise). There isn’t an obligation for a CA to check to see if a key is compromised. The current process just kicks off a perpetual 24 hour revocation period as long as the public can find the compromised key.
“Thus, I would expect that CAs are checking for reuse of compromised private keys prior to issuance.” This is definitely not happening. “My assumption is a certificate which has been revoked due to compromise has a “weak Private Key.” As such, based on the current BRs, a CA should reject certificate requests using a key from a certificate that they revoked due to compromise.”This also doesn’t happen across CAs. Too ambiguous on what is a “weak Private Key”, although this is mixed results (all CAs seem to prevent 1024 bit certs but not all fail for Heartbleed issues) From: Wayne Thayer <[email protected]> Sent: Tuesday, August 21, 2018 3:56 PM To: Bruce Morton <[email protected]>; CA/Browser Forum Public Discussion List <[email protected]> Cc: Tim Hollebeek <[email protected]>; Jeremy Rowley <[email protected]>; Ryan Sleevi <[email protected]> Subject: Re: [cabfpub] [EXTERNAL]Re: Issuance of certificates for keys reported as compromised On Tue, Aug 21, 2018 at 2:15 PM Bruce Morton via Public <[email protected] <mailto:[email protected]> > wrote: BR 6.1.1.3 states “The CA SHALL reject a certificate request if the requested Public Key does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or if it has a known weak Private Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys).” My assumption is a certificate which has been revoked due to compromise has a “weak Private Key.” As such, based on the current BRs, a CA should reject certificate requests using a key from a certificate that they revoked due to compromise. If we're talking about the same CA re-signing a key previously used in a certificate that the CA revoked due to key compromise, then [if nothing else] the CA must revoke the new certificate within 24 hours per 4.9.1.1(3). Thus, I would expect that CAs are checking for reuse of compromised private keys prior to issuance. If we're talking about other CAs rejecting the compromised key, then I have to question whether there is enough benefit to offset the substantial effort involved in designing and running a system that isn't susceptible to the concerns Ryan raised. It'd be interesting to see a proposal. Bruce. From: Public [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Tim Hollebeek via Public Sent: August 21, 2018 4:55 PM To: Jeremy Rowley <[email protected] <mailto:[email protected]> >; Ryan Sleevi <[email protected] <mailto:[email protected]> >; CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Subject: [EXTERNAL]Re: [cabfpub] Issuance of certificates for keys reported as compromised Yes, certainly, at a minimum, CAs should not be issuing new certificates for keys they themselves have previously determined to be compromised. As you correctly note, this is currently a fairly common occurrence. -Tim
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
