> -----Original Message-----
> From: Gervase Markham [mailto:g...@mozilla.org]
> Sent: Monday, January 16, 2017 1:44 PM
> To: Doug Beattie <doug.beat...@globalsign.com>; CA/Browser Forum Public
> Discussion List <public@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
_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to