During IETF 123, I said that I like the overall structure of this draft: introducing a new identifier type, describing how that identifier type corresponds to a structure within the resulting certificate, and providing a validation method for that identifier type. It's concise and clearly motivated.
I also said that I was very confused by Section 5.5, which discusses the intricacies of certificates which assert both a JWTClaimConstraints and a TNAuthList. My thesis is this: the section doesn't need to exist. --- The current Section 5.5.2 describes everything relevant to the ACME flow: 1. The client requests a new Order, including two Identifiers (one of type TNAuthList, and one of type JWTClaimConstraints) in the request. 2. The server creates two new Authorization objects, one for each of those identifiers. 3. The client fulfills one challenge for each authorization, separately. This is, in my opinion, so obvious that it doesn't need to be said. This is simply how ACME orders and authorizations work, per RFC 8555. The fact that these two identifiers have similar semantics has no bearing on how they are validated. An analogous situation would be making a new-order request with both "example.com" (a dns identifier) and "23.192.228.80" (an ip identifier, for one of the IPs to which example.com resolves) in it. Those identifiers represent very similar things, and validating their Authorizations with http-01 Challenges may involve making requests to the exact same webserver, but they'll nonetheless be validated wholly independently. Therefore I believe that Section 5.5.2 can be safely deleted from the document. --- The current Section 5.5.1 is where most of my confusion stems from, and I believe the correct remedy is also to delete this section. For one thing, most of the section is concerned with how two different claims -- one TNAuthList, and one JWTClaimConstraints -- within a single certificate interact. They might overlap, or one may be a strict subset of the other, etc. This is, in my opinion, outside the purview of the ACME WG. How to correctly handle a certificate that contains both extensions is a matter for the working groups which defined those extensions. Worse, this section repeatedly mentions that there will be "two Authority Tokens in the ACME challenge response". This, to the best of my understanding, should never be the case. As discussed above, there will be one Authority Token in the challenge response for the TNAuthList identifier, and there will be one Authority Token in the challenge response for the JWTClaimConstraints identifier. Ne'er the twain shall meet. It is not the purview of the ACME server to determine whether these two claims *make sense* together; as long as the client can successfully fulfill the tkauth-01 challenge for each separate identifier, the order is valid. Therefore I believe that Section 5.5.1 can safely be deleted from the document. --- Overall, I think that all of Section 5.5 can be reduced to a single paragraph in the Security Considerations section, pointing out that the JWTClaimConstraints and TNAuthList extensions have complex interactions, that any ACME Clients intending to request certificates containing both identifiers should understand those interactions, and referring readers to the RFCs in which these x509 extensions were originally defined. I think that none of that complexity carries over to the ACME protocol, or the way in which these identifiers are (separately!) validated. Thanks for the great presentation today! Aaron
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
