[cabfpub] Mozilla SHA-1 further restrictions (v4)
gerv at mozilla.org
Mon Jan 16 11:44:08 MST 2017
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
>> 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
Yep. In publicly-trusted hierarchies, if they are going to keep issuing
> 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?
More information about the Public