[cabfpub] SHA-1 Wiki Posted

Thu Oct 1 16:49:28 UTC 2015

I agree that our document is inconsistent with the BRs, and I think this is something we need to discuss at the face-to-face next week. We need to figure out how we are going to deal with those customers that need to have a SHA-1 cert between 2016 and 2017, and how we can implement a process that allows CAs to issue these on an exception basis without violating the BRs and thereby invalidating their audits. Let’s put this on the agenda for next week.

From: Doug Beattie [mailto:doug.beattie at globalsign.com]
Sent: Wednesday, September 30, 2015 11:23 AM
To: Brad Hill <hillbrad at gmail.com>; Ryan Sleevi <sleevi at google.com>; Jody Cloutier <jodycl at microsoft.com>
Cc: Microsoft Trusted Root Certificate Program <trustcert at microsoft.com>; public at cabforum.org
Subject: RE: [cabfpub] SHA-1 Wiki Posted

Bill,

That’s one of many vague areas.  There is not a MUST that says “CAs MUST stop using SHA-1 signed OCSP signing certificates” in the BRs.

Section 7.1.3 says: Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm.
  But, it does not prohibit issuing OCSP signing certificates.  If this was to be specifically prohibited it should be listed here, probably with a different date.

Section 7.1.3 says: CAs MAY continue to sign certificates to verify OCSP responses using SHA1 until 1 January 2017.
  But, it does not say you cannot issue them after 1 Jan 2017, it is implied you shouldn’t, but not prohibited.

That’s the way I read it anyway.

Doug

From: Brad Hill [mailto:hillbrad at gmail.com]
Sent: Wednesday, September 30, 2015 2:09 PM
To: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>; Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>>; Jody Cloutier <jodycl at microsoft.com<mailto:jodycl at microsoft.com>>
Cc: Microsoft Trusted Root Certificate Program <trustcert at microsoft.com<mailto:trustcert at microsoft.com>>; public at cabforum.org<mailto:public at cabforum.org>
Subject: Re: [cabfpub] SHA-1 Wiki Posted

Will the BRs be updated to correspond to this?  Right now they prohibit signing OCSP and CRL with SHA-1, even for SHA-1 certificates that remain valid, after Jan 1, 2017.

On Wed, Sep 30, 2015 at 5:19 AM Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>> wrote:
Hi Ryan,

We agree with the updates Jody made as this allows CAs to continue supporting SHA-1 signed OCSP and CRLs for our SHA-1 CAs “indefinitely”.  While Windows 10 and other clients may start to reject SHA-1 signed OCSP responses, those customer using SHA-1 will continue to function within their ecosystem until the certificates expire or the CA certificate is revoked.

I can’t find support for your statement “SHA-2 is required *and* enforced on 2017/01/01” as it relates to OCSP signatures.  I see that MS may not trust them, but I don’t see a requirement that CAs must not use SHA-1 after 1/1/2017.  Did I miss something in the MS article?

Doug

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org<mailto:public-bounces at cabforum.org>] On Behalf Of Ryan Sleevi
Sent: Tuesday, September 29, 2015 6:49 PM
To: Jody Cloutier <jodycl at microsoft.com<mailto:jodycl at microsoft.com>>
Cc: Microsoft Trusted Root Certificate Program <trustcert at microsoft.com<mailto:trustcert at microsoft.com>>; public at cabforum.org<mailto:public at cabforum.org>

Subject: Re: [cabfpub] SHA-1 Wiki Posted

Jody,

Thanks for the quick response. I realize there's two parts to this - what the Microsoft root program expects, and what Windows will enforce. It's perfectly reasonable to expect something that isn't (yet) enforced - the Baseline Requirements are a great example of collaborating on setting expectations, even if we don't all programatically enforce them (e.g. validity period ranges of certificates, which only Chrome enforces, even though all of us expect it by virtue of the BRs)

With the new update, I want to make sure I'm reading this correctly:

http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx#Enforcement_in_General
Under Bullet 7 (typod OSSP, btw), the Microsoft *policy* is that OCSP signatures must use SHA-2 beginning 2016/01/01

This is "Microsoft requires CAs to start issuing new OCSP signatures using only the SHA-2 algorithm after January 1, 2016 for SHA-2 SSL certificates"

This seems to conflict with Enforcement Details section, that describes the difference between Windows Behaviour and Microsoft Policy ( http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx#H1_B )

which is that Microsoft policy is that CAs should move to SHA-2 (but presumably, if they should, it's not that they must). This seems consistent with your updated timeline under the Schedule section, which explicitly calls it out as SHOULD.

So I guess the ambiguity is whether the "requires" in Enforcement in General is a MUST or if it's a SHOULD.

I think the rest is clear (SHA-2 is required *and* enforced starting 2016/01/01 for anything with Must-Staple; SHA-2 is required *and* enforced on 2017/01/01), but it's a question about whether SHA-2 is required *but not* enforced starting 2016/01/01 - Schedule and Enforcement are clear that it's not enforced, but "Enforcement in General" is inconsistent with them both with regards to requirements of Microsoft Policy.
_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151001/0791bad2/attachment-0002.html>