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

Tue Oct 20 09:47:56 MST 2015

Re-posting

From: Eric Mill [mailto:eric at konklone.com] 
Sent: Tuesday, October 20, 2015 12:39 PM
To: Dean Coclin
Cc: Gervase Markham; Ryan Sleevi; Jacob Hoffman-Andrews (jsha at eff.org)
Subject: Re: [cabfpub] Ballot 152 - Issuance of SHA-1 certificates through 2016)

(Please feel free to re-post to the public list, if you think it's merited.)

Sigbjørn touched on this point, but I think it bears some elaboration -- the CA/Browser Forum has a few crucial audiences with which it needs to maintain credibility. The browsers and CAs that make it up are the most obvious and important ones. 

Large enterprises/customers are also important, and they have a clear voice in this process, which they can express to members of this forum privately and publicly. While they may not always get their way, I would say their interests are well-represented.

But another crucial audience, just as important or perhaps more so, is the public. By "the public", I don't just mean scattered humanity, but also their more direct representatives -- civil society groups, elected and appointed government officials, the press, and civil servants in agencies, libraries, and universities the world over. 

The credibility of the CA/B Forum to that audience is vitally important today, in a way that it wasn't in 2007 or 2011 or even 2013. The CA/B Forum isn't "mainstream", but it has passed a critical threshold of visibility among the public and the public sector -- people get that the world has placed a lot of trust in this Forum, and that the decisions here matter a lot.

If the Fortune 50 companies that have put certs in hard-to-reach places lose confidence in the CA/B Forum as a result of this process, the only practical negative consequences I can imagine are that they stop using public roots for those kinds of applications. Perhaps they even feel enough spite to switch CAs who they feel didn't represent them in the Forum. This might result in some loss of business for individual CAs, but is consistent with what everyone on this thread has been saying so far: don't use public roots for enterprise applications where they are not necessary. The less that happens, the stronger the public ecosystem is.

If the public loses confidence that the CA/B Forum is an institution where the public interest is well-represented, the consequences -- while much slower and more subtle -- could be much more sweeping.

While this ballot and discussion is just about the deprecation of one algorithm, it's also a very helpful symbol and predictor of how the CA/B Forum's politics are likely to work in the future, and whether diffuse interests are as well-represented as concentrated interests.

Dean is ably making sure that the concerns and specific questions of enterprises having trouble with this deadline are well-represented, and that is good for everyone. To the extent it reveals that some of these enterprises may not really understand the threat model of certificate issuance -- and perhaps have never really *had* to, until this year -- that is also good for everyone. 

In 2017, we'll be in a better place, not just in having killed SHA-1, but having made publicly clear that the CA/B Forum is an institution that can balance the interests of everyone that has placed their trust in them.

-- Eric

On Tue, Oct 20, 2015 at 11:56 AM, Dean Coclin <Dean_Coclin at symantec.com> wrote:

" 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

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

-- 

konklone.com | @konklone <https://twitter.com/konklone> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151020/6dc29c90/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151020/6dc29c90/attachment-0001.bin 