[cabf_validation] FW: [Acme] Potential future incompatiblity between HTTP-01 and CABForum BRs

[Ben Wilson]

Has anyone been following this?

-----Original Message-----
From: Acme [mailto:acme-bounces at ietf.org] On Behalf Of Ilari Liusvaara
Sent: Tuesday, April 11, 2017 12:34 PM
To: Roland Bracewell Shoemaker <roland at letsencrypt.org>
Cc: acme at ietf.org
Subject: Re: [Acme] Potential future incompatiblity between HTTP-01 and
CABForum BRs

On Mon, Apr 10, 2017 at 10:14:39PM +0300, Ilari Liusvaara wrote:
> On Mon, Apr 10, 2017 at 10:55:25AM -0700, Roland Bracewell Shoemaker
wrote:
> > I'm not sure why the contents of the http-01 challenge could not be 
> > considered a 'request token'? A favorable interpretation that would 
> > require no changes would be that the random token (in ACME speak) is 
> > only half of the 'request token' (CABF speak) that is required for 
> > validation and therefore the full 'request token' _is not_ present 
> > in the request (since the required key authorization contains both 
> > the random token and the thumbprint of the JWK public key).
> 
> The problem here is two SHALL (i.e. RFC2119 MUST) -level requirements 
> on Request Tokens:
> 
> - They incorporate the "key used in the certificate request"
> - Non-timestamped Request Tokens are single-use (timestamped ones are
>   valid for maximum of 30 days).
> 
> (Section 1.6.1 of CABForum baseline requirements version 1.4.4)
> 
> My reading of "key used in the certificate request" is the CSR public 
> key, which can't match the account key anyway (and in the case of 
> Let's Encrypt as of today, isn't even known). There is no definition 
> of "certifiate request" as far as I can see.

Well, thinking about it, ACME-01 as used by LE seems to imply that
challenges are in response to "certificate requests" (regardless of what
ACME calls it). And those requests _are_ keyed by the account key.

Things get more screwy when one moves to ACME-06 (which is presumably close
to ACME-final) without preauthorization. Now the requests have two keys, and
BRs assume there is only one...


(One also seemingly has to take somewhat wide interpretations of things to
get TLS-SNI-01/TLS-SNI-02 to fit into "10 methods").
 
> As for the second requirement, there is actually a twisted reading 
> that might be met: There is no requirement to bind the timestamp or 
> the use-once diversification to the rest of the token in any way.
> Let's throw the random value as use-once diversification (LOL), it 
> certainly renders the response unique...



-Ilari

_______________________________________________
Acme mailing list
Acme at ietf.org
https://www.ietf.org/mailman/listinfo/acme
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4974 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20170411/c3d43ce8/attachment.bin>