<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 20, 2015 at 9:31 AM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 20/10/15 03:15, Dean Coclin wrote:<br>
> Thanks to you and Jacob for providing the relevant information. I’ll be<br>
> sure to pass it on.  Does anyone have anything else to add?<br>
<br>
</span>One thing that wasn't really clear in the discussions in Istanbul,<br>
because the news of the new break broke and we never really clarified<br>
it, is this: are these customers wanting simply a change in the CAB<br>
Forum BRs, or are they also wanting the browser makers to change their<br>
code (because for us, it would be a code change) to accept such<br>
2016->2016 certificates?<br>
<br>
It still remains an option for CAs to withdraw particular roots from<br>
browsers, and so from BR compliance, before the end of the year, if they<br>
are quick. Although that does raise a question for Ryan: how are the<br>
following two scenarios different? A) CA withdraws a root from the<br>
public root stores and then uses it to issue SHA-1. B) CA doesn't<br>
withdraw such a root, but all browsers refuse to accept the issued SHA-1<br>
certs. In both cases, the certs are not accepted by the browsers. In<br>
fact, in case B), you could have a harder fail if you wanted.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I would also add a little bit to Ryan's points on the first mover<br>
problem. If you have a single hard deadline when everything has to stop<br>
- issuance and acceptance - history shows us that people do the thing<br>
you don't want them to do right up to the deadline, and then complain<br>
and ask for it to be moved so there can be a "more ordered transition". </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
A phased transition is what we now have - no issuance from Jan 1 2016,<br>
no acceptance from Jan 1 2017. Moving back towards the "everything at<br>
once" model runs, IMO, a greater risk of problems at the transition point.<br>
<br></blockquote><div><br></div><div><div>As it looks, a successful attack on SHA-1 most likely needs the ability to issue new certificates. So I think that we should stick to the current plan and stop issuing of new SHA-1 certs. Opera will vote no on attempts to change that.</div></div><div><br></div><div>That said, since this seem to happen every time something in deprecated, can we take look at how things can be improved?</div><div><br></div><div>Here are four reasons I can come up with for how a company ends up in this situation:</div><div><br></div><div>1) A company knows and understands the new policies, but gamble on an extension</div><div>2) A company knows and understand the policies and tried to migrate without success.</div><div>3) A company knows and thinks they understand the new policy but really don't.</div><div>4) A company haven't heard about it until it's too late.</div><div><br></div><div>I doubt #1 happens often. #2 might be a bit more realistic but that is simply a discussion about dates. Hopefully #4 doesn't happen too often but I'm afraid it does.</div><div><br></div><div>It might be possible to improve on #3 and #4. Many CAs do a good job informing their customers, both in blogs and I'm sure in emails too. However, in rare cases like this, and in addition to publishing the ballot, we could create a document containing</div><div> </div><div>1) Explanation of the ballot.</div><div>2) An analysis of the consequences for clients and servers.</div><div>3) Advisable action points.</div><div><br></div><div>This document should then be distributed to all customers by the CAs. I can see this really does seem like spoon-feeding, but if it can improve the situation next time we need to deprecate something it may be worth the effort?</div><div><br></div><div>Thoughts?</div><div><br></div><div>Håvard</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
My last point is one I made in Istanbul: it was obvious in 2007, when<br>
the CAB Forum started, that issuing non-public certs from the same roots<br>
as public certs was a bad idea, and it's even more obvious now. Any CA<br>
still doing this for non-legacy deployments needs their head examining.<br>
<br>
Gerv<br>
<div class=""><div class="h5">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div></div>