> On 12/01/17 19:06, Doug Beattie wrote: > > Is there a provision for signing SHA-1 OCSP signing certificates? > > Perhaps this is covered in #1, but specifically allowing SHA-1 OCSP > > Signing certificates (under SHA-1 CAs which have active SHA-1 TLS > > certificates) would be a good idea for clarity. > > It is covered in #1. Do you see a problem?
Are OCSP signing certificates covered by the BRs? TLS certs, CAs, CRLs and OCSP messages are all covered and this implies that OCSP signing certificates are also, in my view, as they are normally used for signing OCSP responses. Section 7.1.3 places a requirement on OCSP signing certificates (may sign OCSP signing certs with SHA-1 until 1/1/2017) So, your statement implies we cannot issue SHA-1 OCSP signing certificates. Is that the intent? > > For #2: - Can roots issue SHA-1 signed certificates? You seem to > > preclude this, but of course we need that for OCSP signing certs. - > > You suggest changing to "the issuing intermediate or root"? If you do that, then the pathlen:0 constraint does not apply. I think you need to change the heading and bullets to reflect your intent. Is this what you mean? 2) The issuing CA: * must be a SHA1 signed CA * must not have ever been used to issue TLS <or code signing?> certificates * must not be used to issue TLS certificates in the future > > What if the Intermediate (or root if you permit that) does not have an > > EKU, can that be used to sign certificates? I'm guessing most older > > intermediate CAs don't have EKU, so this means most SHA-1 CAs can be > > used to issue certificates (I'm not sure if this was your intent). > > You mean "can't be used"? That is the intent, but the new clause about > signing hashes over issuing intermediates is there to allow such certs to be > replaced with a new cert which is identical but which has an EKU. > > But actually, that doesn't help, does it, because an attacker could just use > the > old version. I guess we also need to require key rotation? That will be an issue - are you saying we need to replace all current SHA-1 CAs that don’t have EKUs with new CAs that have new keys and EKUs? We have some SHA-1 CAs that are used to issue non BR certificates that we need to keep on-line until the applications all support SHA256. > > Why can's CAs sign Precertificates? > > Well, certs going into CT are under the BRs anyway, so in what > circumstances would you want to and be allowed to do this by existing policy > anyway? We've posted some SHA1 OCSP signing certs into the CT logs recently. These were not Precertificates, just the issued certificates, but is there a reason we could not have posted Precertificates for these? Asking again, are OCSP signing certs covered by the BRs or not? If yes, then you need to change this requirement. > Gerv _______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
