<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 4:19 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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I am moving house next week, and so cannot guarantee my ability to<br>
participate in this discussion.<br>
<br>
Mozilla approves the application from TSYS (that is to say, we will<br>
accept a qualified BR audit from their CA where the qualifications<br>
relate to this event) on the condition that the serial numbers of the<br>
final certificates follow some documented strict construction process,<br>
in broadly the manner PHB outlined, using a modern crypto hash algorithm<br>
in the process of serial number generation, using an earlier form of the<br>
cert as input. I believe this should be a sufficient stopgap to reassure<br>
the public (who cannot see inside the CA's or TSYS's operations) that<br>
collisions are not being attempted. Other CAs may want the process<br>
nailed down; the above is intended to be vague enough to accommodate<br>
whatever they decide.<br>
<br>
We do not (although others may) require that TSYS reuse old keys, or<br>
remove the random identifiers from the OU.<br>
<br>
Dean indicated on yesterday's call that following this type of process<br>
was possible for Symantec if approval from browsers was provided<br>
quickly. This is an attempt to provide such approval with the necessary<br>
speed.<br></blockquote><div><br></div><div>As with Gerv, our primary concern for the immediate issuance is the concern with the OU. Steps taken to remedy that - either the step suggested by Geoff or as proposed by Gerv - reasonably address this, in as much as they provide reasonable public assurance, above and beyond the countercryptanalysis, that there was limited opportunity for malfeasance, both in fact and appearances.</div><div><br></div><div>While we appreciate TSYS's continued attention to the questions as we look for opportunities, as an industry forum, to improve outreach, education, and understanding about how these transitions have worked in practice, we don't believe the remaining questions to be a blocker towards accepting this issuance. We do hope they'll continue to assist in our understanding and improvement though.</div><div><br></div><div>Given the difficulty Symantec has had in following the process previously, we're more than willing to assist Symantec in the production of a tbsCertificate that meets the suggested changes by Gerv and Geoff, and incorporating in such feedback as that by Peter Bowen in <a href="https://cabforum.org/pipermail/public/2016-July/008055.html">https://cabforum.org/pipermail/public/2016-July/008055.html</a> - most notably, ensuring that the serial number is properly encoded (as a positive integer). This assistance is easier because the production of a tbsCertificate, to the scheme proposed (that is, using a rigid serial construction rather than a random), allows for such tbsCertificates to be produced without any form of CA ceremony, and can be produced on any machine, by any party, and in any security zone.</div></div></div></div>