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

Doug Beattie doug.beattie at globalsign.com
Mon Jan 16 21:02:32 UTC 2017

> -----Original Message-----
> From: Gervase Markham [mailto:gerv at mozilla.org]
> Sent: Monday, January 16, 2017 1:44 PM
> To: Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> Subject: Re: [cabfpub] Mozilla SHA-1 further restrictions (v4)
> On 13/01/17 15:47, Doug Beattie wrote:
> > 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?

Sure, that would work for me.

> > 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)".

I'm not sure why pathlen=0 is important in the first place.  Is that needed?  Why?

Also, you need to clarify which CAs (roots and/or intermediates) need to have the EKU extension.  The way it’s currently worded you would permit a CA without the EKU extension to sign SHA-1 certificates, and I believe that is not your intent.  Most roots do not have EKU, so be careful how you word this.

> > 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?

I don’t know if anything will "break", but it’s not trivial working with customers to generate and configure new CAs which are nearing their end of life anyway.

Maybe Mozilla could flag SHA-1 CA certificates that are not supposed to be used for TLS and effectively disable any TLS certificates issued by these CAs?  We could identify any these SHA-1 CAs in the SalesForce system for you.

Side note: SHA-1 CAs that are in Maintenance mode (no longer issuing, just providing OCSP and CRL services) may need to sign SHA-1 OCSP signing certificates.  I hope that these CAs can continue issuing SHA-1 OCSP signing certificates so that revocation services can remain current and operational as they are.

> >>> 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?

It's unlikely that anyone will post OCSP signing Precertificates, but why do you want to prohibit it?  Nobody is checking to see if DV certificates have SCTs, but some of us are doing it because it’s the right thing to do.  I don’t see why this should be prohibited.

> Gerv

More information about the Public mailing list