[cabfpub] A better way to do SHA-1 legacy

[Ryan Sleevi]

Dean,

To be fair, there are still a number of outstanding questions posed to
TSYS, so it's not readily apparent that they share your suggested sense of
urgency. I do hope it was perhaps an oversight that
https://cabforum.org/pipermail/public/2016-July/008027.html has yet to be
answered.

Also, please realize that this issue is precisely because the only request
so far has every appearance of attempting to exploit the very thing the
process was designed to protect against. The choice of random OUs is
exceptionally concerning to us and members of the relying community, and
the explanation in
https://cabforum.org/pipermail/public/2016-July/008041.html doesn't do much
to assuage those concerns. Equally concerning is Symantec's own inability
to follow a secure process in generating the tbsCertificates - a topic we
explicitly discussed in Bilbao during the discussion about how a CA, such
as Symantec, would be able to make use of this process, given that your
systems would have difficulty with the serial number production.

I think it's reasonable to be concerned that the process as proposed may
not be as foolproof as we'd all hoped, given the events surrounding the
request, and the proposed change could be a very concrete way to address
those concerns - AND the concerns with the very request you reference.

But I think perhaps most important to consider was the repeated
communication that this should not just be assumed to be a rubberstamp
process. Faced between a choice of rejecting the request for these
concerning and opaque irregularities, or modifying the process to provide
reassurances, I'm sure you can see why the latter would be preferred.

On Tue, Jul 19, 2016 at 5:50 PM, Dean Coclin <Dean_Coclin at symantec.com>
wrote:

> All,
>
> The proposal to deal with SHA-1 issuance was discussed and debated in
> Bilbao, further discussed on list after Andrew drafted the proposal (which
> took into account the Bilbao discussion) and then further discussed on the
> CABF call with industry representatives at the end of June. This resulted
> in the "final" procedure which applicants used to prepare their info to the
> forum. One has come forward, based on all these adjustments and
> discussions, and prepared (in good faith) an application for consideration
> by the forum, browsers and the public.
>
> It would be very unfair at this stage to change that procedure especially
> as we have one party going through the process with an especially urgent
> request.
>
> In my opinion, the time to comment on the current procedure has passed. We
> should be fair to everyone by sticking to what was published. However, if
> the group wants to amend the procedure for upcoming applicants, that should
> be discussed and approved for the future.
>
> Dean
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
> Behalf Of philliph at comodo.com
> Sent: Tuesday, July 19, 2016 8:06 PM
> To: Erwann Abalea <Erwann.Abalea at docusign.com>
> Cc: CABFPub <public at cabforum.org>
> Subject: Re: [cabfpub] A better way to do SHA-1 legacy
>
> The point is that it is not possible t change just one bit in a
> certificate at a time. Any change to the cert whatsoever will cause
> unpredictable changes to at least 128 bit in the cert.
>
> I know that we agreed to do something different. The reason I am proposing
> to revisit is that the original scheme isn’t auditable and people seem to
> be screwing it up.
>
>
>
> > On Jul 19, 2016, at 6:59 PM, Erwann Abalea <Erwann.Abalea at docusign.com>
> wrote:
> >
> > The attacker can tweak the public key and obtain a resulting tbsCert
> until a set of attacker-defined conditions is met. He doesn’t need to
> interact with anybody for that, and we don’t know what kind of «
> attacker-defined conditions » is acceptable.
> > In my view, it’s a regression from the current scheme.
> >
> > Cordialement,
> > Erwann Abalea
> >
> >> Le 19 juil. 2016 à 16:53, Gervase Markham <gerv at mozilla.org> a écrit :
> >>
> >> On 19/07/16 15:44, Erwann Abalea wrote:
> >>> There’s no need to collide SHA2 with this scheme.
> >>> The attacker can know in advance what the serial number will be; it
> >>> may not be sequential, but is nevertheless predictable. So the
> >>> attacker
> >>
> >> But the attacker can only know the serial number when the entire
> >> remainder of the certificate is fixed. So how can they tweak it to
> >> enable the attack? If they tweak it, the serial number changes.
> >>
> >> Gerv
> >>
> >
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> 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/20160719/0c36dd22/attachment-0003.html>