[cabfpub] Ballot 152 - Issuance of SHA-1 certificates through 2016)

[Dean Coclin]

" One thing that wasn't really clear in the discussions in Istanbul, because the news of the new break broke and we never really clarified it, is this: are these customers wanting simply a change in the CAB Forum BRs, or are they also wanting the browser makers to change their code (because for us, it would be a code change) to accept such 2016->2016 certificates?"

--> As far as I've heard, no one is asking Mozilla to change their code. 

"It still remains an option for CAs to withdraw particular roots from browsers, and so from BR compliance, before the end of the year, if they are quick. Although that does raise a question for Ryan: how are the following two scenarios different? A) CA withdraws a root from the public root stores and then uses it to issue SHA-1. B) CA doesn't withdraw such a root, but all browsers refuse to accept the issued SHA-1 certs. In both cases, the certs are not accepted by the browsers. In fact, in case B), you could have a harder fail if you wanted."

--> Yes, if CAs have a particular root that can be withdrawn, then it can be considered a private root and not subject to BRs. This would be great in the 2nd case I highlighted. But I would reckon that most CAs don't have extra roots hanging around that they want to remove from the public trust.

"My last point is one I made in Istanbul: it was obvious in 2007, when the CAB Forum started, that issuing non-public certs from the same roots as public certs was a bad idea, and it's even more obvious now. Any CA still doing this for non-legacy deployments needs their head examining."

--> My dear Gerv: I'm sure you understand that people buy things from companies and don't say what they are doing with them ;-). Things have changed dramatically since 2007 and I would venture to say that nowadays CAs will explicitly tell companies not to use public roots for private applications. 



-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Tuesday, October 20, 2015 3:31 AM
To: Dean Coclin; Ryan Sleevi; Jacob Hoffman-Andrews (jsha at eff.org)
Cc: public at cabforum.org
Subject: Re: [cabfpub] Ballot 152 - Issuance of SHA-1 certificates through 2016)

On 20/10/15 03:15, Dean Coclin wrote:
> Thanks to you and Jacob for providing the relevant information. I’ll 
> be sure to pass it on.  Does anyone have anything else to add?

One thing that wasn't really clear in the discussions in Istanbul, because the news of the new break broke and we never really clarified it, is this: are these customers wanting simply a change in the CAB Forum BRs, or are they also wanting the browser makers to change their code (because for us, it would be a code change) to accept such
2016->2016 certificates?

It still remains an option for CAs to withdraw particular roots from browsers, and so from BR compliance, before the end of the year, if they are quick. Although that does raise a question for Ryan: how are the following two scenarios different? A) CA withdraws a root from the public root stores and then uses it to issue SHA-1. B) CA doesn't withdraw such a root, but all browsers refuse to accept the issued SHA-1 certs. In both cases, the certs are not accepted by the browsers. In fact, in case B), you could have a harder fail if you wanted.

I would also add a little bit to Ryan's points on the first mover problem. If you have a single hard deadline when everything has to stop
- issuance and acceptance - history shows us that people do the thing you don't want them to do right up to the deadline, and then complain and ask for it to be moved so there can be a "more ordered transition".
A phased transition is what we now have - no issuance from Jan 1 2016, no acceptance from Jan 1 2017. Moving back towards the "everything at once" model runs, IMO, a greater risk of problems at the transition point.

My last point is one I made in Istanbul: it was obvious in 2007, when the CAB Forum started, that issuing non-public certs from the same roots as public certs was a bad idea, and it's even more obvious now. Any CA still doing this for non-legacy deployments needs their head examining.

Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151020/4eeb223c/attachment-0001.p7s>