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
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
and is never just one.


> -----Original Message-----
> From: Jacob Hoffman-Andrews []
> Sent: Monday, March 5, 2018 5:42 PM
> To: Tim Hollebeek <>;
> 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
> 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
> a game-over bug on its own:
>  - ignoring a critical extension
>  - trusting a self-signed certificate
>  - sending acme/1 ALPN for non-validation traffic

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Acme mailing list

Reply via email to