That's a fair point. Although note that critical extension bugs don't tend to be of the "ignore critical extension" variety (though that happens), they tend to be of the "understand the critical extension for the purposes of rejecting it and then getting the logic backwards" or something similar.
The self-signedness is probably the most important mitigating factor ... we might want to make sure that the draft has enough requirements to make sure that the margin of error is two to three software bugs in all compliant implementations, and is never just one. -Tim > -----Original Message----- > From: Jacob Hoffman-Andrews [mailto:j...@eff.org] > Sent: Monday, March 5, 2018 5:42 PM > To: Tim Hollebeek <tim.holleb...@digicert.com>; email@example.com > Subject: Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt > > On 03/05/2018 04:37 PM, Tim Hollebeek wrote: > > I think we may come to regret using that trick so much. Such schemes > > are only one software bug away from having rather profound effects on > > trust decisions and the entire ecosystem. > This is a good point, but an important mitigating factor is that these are self- > signed certificates, as compared to CT's precertificates, which are signed by a > trusted issuer but poisoned. And they are only presented when the acme/1 > ALPN is negotiated. So you'd need three software bugs, each of which would be > a game-over bug on its own: > > - ignoring a critical extension > - trusting a self-signed certificate > - sending acme/1 ALPN for non-validation traffic
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme