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

[Håvard Molland]

On Tue, Oct 20, 2015 at 9:31 AM, Gervase Markham <gerv at mozilla.org> wrote:

> 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.
>
>
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.

That said, since this seem to happen every time something in deprecated,
can we take look at how things can be improved?

Here are four reasons I can come up with for how a company ends up in this
situation:

1) A company knows and understands the new policies, but gamble on an
extension
2) A company knows and understand the policies and tried to migrate without
success.
3) A company knows and thinks they understand the new policy but really
don't.
4) A company haven't heard about it until it's too late.

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.

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

1) Explanation of the ballot.
2) An analysis of the consequences for clients and servers.
3) Advisable action points.

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?

Thoughts?

Håvard



> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151020/d1dd45c5/attachment-0003.html>