On Sun, Aug 21, 2016 at 8:32 PM, Jacob Hoffman-Andrews <[email protected]<mailto:[email protected]>> wrote: On 08/21/2016 04:31 PM, Richard Barnes wrote: > How about this as a compromise proposal: Have the JWS header contain > *both* the account URL and the account public key. That way you get > fast rejection based on crypto failures, and you also get protection > against any issues related to relying on public keys alone. This doesn't achieve the goal of making sure that ACME servers are validating based on account data they already have, rather than validating based on a key provided in the request.
>What do you mean by "validating"? >There are two types of validation to do here: >1. Validating that the signature on the message is good >2. Validating that the key belongs to a the right account for this request > >You can do the first of these without any knowledge of the account status of a >key. Doesn't require any database lookup if you provide the key in >the >header. There's no harm to doing this validation without knowing whether the >key is good, and there's benefit in rejecting bad signatures quickly. The point is that if you: take an account id from message → lookup account → use public key from account to verify signature; then it is hard to see how an implementer can get #2 wrong. But you have to do the DB lookup before the crypto verification. Richard’s alternative approach takes a public key from a message and tries to match that to a public key in an account. That should work, but it is less clear that there are not easy implementer traps. Matching keys is less obvious. How to do it isn’t specified. You could calculate JWK Thumbprints [RFC7638] and match those strings. Thumbprints ignore optional fields; hopefully that’s okay. Thumbprints can’t be relied on to be unique (eg shouldn’t be used in a blacklist); hopefully Acme implementations only need them to be unambiguous, not unique, for security. I hope an implementation doesn’t assume a “kid” (key-id) provided by a client is a thumbprint. Having both (public key and account-id) in a message raises the risk that a sloppy implementation verifies with the former, does the lookup with the latter, then fails to properly link the two. -- James Manger
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
