<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 10:35 AM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank" class="cremed">Rick_Andrews@symantec.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> -----Original Message-----<br>
> From: Ben Laurie [mailto:<a href="mailto:benl@google.com" class="cremed">benl@google.com</a>]<br>
> Sent: Tuesday, January 14, 2014 5:49 AM<br>
> To: Gervase Markham<br>
> Cc: Rick Andrews; Mads Egil Henriksveen; <a href="mailto:public@cabforum.org" class="cremed">public@cabforum.org</a><br>
> Subject: Re: [cabfpub] CT Precertificates and the BRs<br>
><br>
</div><div class="im">> On 14 January 2014 10:04, Gervase Markham <<a href="mailto:gerv@mozilla.org" class="cremed">gerv@mozilla.org</a>> wrote:<br>
> > On 14/01/14 04:41, Rick Andrews wrote:<br>
> >> Ben, the poison extension only ensures it can't be used in SSL with<br>
> >> modern browsers. We recently had to use the poison extension to<br>
> >> create a BR-incompatible SSL cert for a non-browser app.<br>
> ><br>
> > Surely if the non-browser app in question understands what the<br>
> "poison<br>
> > extension" means, then it's not a poison extension any more, it's<br>
> just a<br>
> > critical extension that one app understands :-)<br>
><br>
> Exactly, and no app should understand the CT poison extension.<br>
<br>
</div>Exactly, but my point is that there are non-browser applications out there that a) don't understand poison critical extensions, and b) don't fail on poison critical extensions that they don't understand. That's what allowed this SSL cert to work for our non-browser customer.<br>

<br>
I'm trying to say that the poison extension is poison only to applications that correctly implement critical extension handling. There are probably even some very old browser versions that don't handle critical extensions properly. The poison extension isn't as watertight as we might like.<br>

<span class="HOEnZb"><font color="#888888"><br>
-Rick<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" class="cremed">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank" class="cremed">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">Rick,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think we need to be *very* careful on how much we allow legacy to hold us back, and under what situations. There's a tricky balance between valid-but-undesirable behaviours (such as accepting hostnames in CNs) and out-and-out buggy behaviour (such as mishandling critical extensions).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Applications that fail to implement critical extension handling have almost certainly botched many other elements of the certificate processing, so I don't think we should let them be the lower bar. I also have no doubt they're in the vast minority of SSL/TLS users - and, if not, then by God they should be, with security like that...</div>
</div>