On 13/01/17 15:47, Doug Beattie wrote: > >> 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.
I'm not sure how that logic follows; my gut feeling would be that they aren't covered but I'm sure there are many people on this list with more familiarity than I have. Can anyone say or give a pointer? > 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? No. Would the fix be to add them as a separate thing one can sign? >>> 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 I don't think that's what I mean, because that's language of intent, not capability. I can change it to "the issuing intermediate or root" and then change the "pathlen=0" thing to be "(intermediates only)". > 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? Yep. In publicly-trusted hierarchies, if they are going to keep issuing SHA-1 certificates. > 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. Does switching intermediates break this? If so, why? Pinning? >>> 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? Why would you want to? Who is checking embedded CT in OCSP signing certs? Gerv _______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
