Would it be possible to add a section for how to follow this pattern in the presence of space constraints?
One possible way would be to divide H(H(kA)) and H(kA) into N pieces as needed to get through the system. Each request would include the "piece number" in some way so that the system can work even in the (probably rare) event that pieces of either H(H(kA)) or H(kA) are identical. The ACME server would make N requests (one for each of the N pieces). If N=1, the piece number would be omitted and only 1 request would be made. In the event of failure, the problem document could indicate the failing pieces in an array. That way, the same pattern works regardless of space constraints. As for key comparison, here are some ideas: 1. Put the key thumbprint (produced using the same hash function H specified in the challenge) in the revised key authorization structure in lieu of the key. Include the key ID as another field in the key authorization structure. 2. Require that only a given subset of JWK fields appears (like the fields required for thumbprints). Include the key ID as another field in the key authorization structure. Sincerely, Logan Widick On Jun 14, 2017 10:22, "Ilari Liusvaara" <[email protected]> wrote: On Wed, Jun 14, 2017 at 09:23:59AM -0400, Richard Barnes wrote: > Hey Ilari, > > Thanks for this analysis. I agree that a tighter and clearer binding of > the challenge/response pair to the validation transaction would be > desireable, as would more uniformity across challenges. I would like to > propose a slightly different structure, though. > > === > > The essential elements of a challenge are (1) the content of the challenge, > (2) the content of the response, (3) the content of the validation query, > and (4) the content of the validation response (where in 3 and 4, we mean > the part that is specific to the validation, vs. .well-known or > _acme-challenge). Right now, (1) and (2) are the same for all challenges, > but (3) and (4) differ. > > http: (1) token (2) keyAuthorization (3) token (4) keyAuthorization > tls: (1) token (2) keyAuthorization (3) H(token) (4) H(keyAuthorization) > dns: (1) token (2) keyAuthorization (3) (nil) (4) H(keyAuthorization) > > I think we could meet the requirements above with the following steps: > > 1. Update the keyAuthorization structure to be a JSON object binding the > validation to a bunch of stuff, e.g.: > > { > "identifier": {"type": "dns", "value": "example.com"}, > "method": "dns-01", > "key": { ... }, > "nonce: "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA" > } > > 2. Have the client provide the serialized keyAuthorization in its response > to the challenge (in ACME) and have the server verify that it decodes > properly, has only the identified fields, and the fields have the proper > values. This has the raw key, which means one has to compare raw keys. IIRC, that is somewhat frowned on. > 3. Derive the validation query and response values from the serialized > keyAuthorization value provided in the response, using a "reveal the > preimage" pattern, either: > 3.a. query = H(kA), response=kA, or > 3.b. query = H(H(kA)), response=H(kA) > > I kind of like the latter better, because it meets all the transport > requirements for DNS and TLS (since the hashes are small). It also enables > the server to verify that a challenge/response pair is valid without > necessarily revealing to the server the details of the validation; if the > server really wants to know, it can demand the raw key authorization. I expect the most common check is check for identifier. But being able to calculate where the response goes from the key authorization (e.g. 'http://somehost3.example.net/.well-known/acme-challenge/yeag2...', '_acme-validation.somehost3.example.net' or 'gesc3<...>.token.acme.invalid') is sure nice to have. > That would give us a uniform structure across challenges: > > all: (1) token (2) keyAuthorization (3) H(H(keyAuthorization)) (4) > H(keyAuthorization) I don't think there is any extra space in DNS for the query. IIRC, there is 255 byte total length restriction for DNS QNAMEs in addition to the 63 byte per-component limit. > What would folks think of that? It's a large-ish change for this stage of > the process, but it seems like the regularity it provides will help > simplify analysis and make implementation easier, so I'm inclined to do it. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
