Ben, Thank you for the feedback. Given that this document is earlier in the stream, we still have opportunities to improve its encoded structure or properties.
> My recollection from the email+S/MIME document (which is to be published as > an RFC imminently) is that the token-part2 was playing the role of a way to > bind the authorization to the specific ACME order. I also wanted to have a > unique identifier that binds the challenge email to the ACME order, and > that aspect changed a fair amount during the review process, but IIRC we > ended up with a bit of a fudge where the ACME exchange includes the "From:" > header field for the challenge email, and that could be unique to the order > but isn't required to be. Unfortunately in the case of bundles the source must be a fixed Node ID so we don't have the option of a similar challenge-specific address. Is there any value in having the ACME server use a unique-but-constant-per-order, and shown- to-the-client, <token-part1> value? Currently the distinguishing characteristic of <token-part1> is that it _only_ comes via bundle so knowing it means that you've seen the challenge bundle (which an on-path attacker can do equally as well) but this avoids the possibility of a response bundle being able to be produced before the challenge bundle is even received. Any value in a three-part nonce token (as recommended earlier, the names can be changed to reflect the use) as defined here? * Part 1 arrives only via challenge bundle, unique to that bundle (not just the order). * Part 2 arrives only via ACME HTTPS, unique to the order. * Part 3 is indicated in both the ACME HTTPS and the challenge bundle and provides a unique filter in the tuple of (Source Node ID, token-part3). This would be similar to the randomized email address. > That said, I have a (very vague, for which I apologize) recollection that > earlier in the evolution of the TCPCLv4 document there was an option where > certain TLS certificates would have an indication that the CA asserts that > the holder of the private key is trusted to provide its Node ID in the > TCPCL SESS_INIT even if the Node ID itself is not included in the > certificate. If that indication from the CA was the id-kp-bundleSecurity > EKU, then requiring ACME to always include that EKU in the issued > certificate would have surprising semantics. That said, it looks like in > at least the latest version of the TCPCLv4 draft, id-kp-bundleSecurity does > not play that role, so there is no issue. I'm only mentioning it now > because the potential scope of consequences is so large, and I am sure that > you will do the right thing (assuming I have been able to describe the > situation I'm worried about clearly enough). You are correct in your conclusion. The last recommended security policy (sent to the RFC editor) is to require a proper Node ID SAN and ignore any other SANs present. There is no recommended policy about implying the ownership/validity of a Node ID.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
