[cabfpub] Mozilla SHA-1 further restrictions (v4)

Gervase Markham 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
>>> 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


More information about the Public mailing list