Hmm, it seems like I may have been misunderstanding something. Allow me to ask a clarifying question:
Is it your intention that the ACME CA inspect the two requested TNAuthList and JWTClaimConstraints identifiers, see whether and how they overlap or modify each other, and then *modify the actual contents of the corresponding extensions it bakes into the resulting certificate* accordingly? My understanding was that the overlap and interactions between the two extensions might only affect how a User Agent trusts and uses the certificate. For example, if the TNAuthList extension restricts "orig" PASSporT claims to just "12345", while the JWTClaimConstraints extension restricts "orig" PASSporT claims to just "67890", then (because the intersection between those two sets is empty) the holder of this certificate would not actually be trusted to make any PASSporT "orig" claims. This doesn't mean the certificate is invalid, or was validated incorrectly, it just means that it is useless, because no client will trust its claims. I do not think that an ACME CA should be modifying the client's requested identifiers before including them in the certificate. It should either be willing to issue the certificate as requested, or it should reject the certificate request. Server policy can dictate whether it wants to reject requests that would result in useless certs. Therefore I do not think that these considerations about how these extensions may affect each other belong in this ACME document, since it does not concern the relationship between the requested identifiers and how they are represented in the cert. Aaron On Wed, Jul 23, 2025 at 9:12 PM David Hancock <[email protected]> wrote: > Thanks for the comments, Aaron. I understand your basic points -- that the > ACME procedures for authorizing multiple identifiers is well-known (at > least by ACME SMEs) and doesn't need to be described in this draft. And the > interaction between this new Authority Token and the already-defined > TNAuthList Authority token are better specified elsewhere. > > For your consideration, I've made the case inline below that the section > 5.5 information does in fact belong in this draft. > > Ultimately, we'll defer to the ACME W-G's guidance on this. > > Thanks, > David > > > On Tue, Jul 22, 2025 at 5:42 AM Aaron Gable <aaron= > [email protected]> wrote: > >> 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. >> >> [dh] In general, section 5.5.2 was added to make sure we understood how > this multiple-identifiers case is supported in ACME (and thanks, you have > confirmed that we got it right). RFC 8555 doesn’t describe a complete > end-to-end example of this case, and so we feel this information would be > useful to readers, especially those not well-versed in all things ACME. > > >> --- >> >> 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. >> > > [dh] This information seems (to me) to be in-scope for an ACME RFC, in > the spirit of the following text from RFC 8555 section 7.4 ... > > “Specifications that define new identifier types must specify where in > the certificate signing request these identifiers can appear. > > A request to finalize an order will result in an error if the CA is > unwilling to issue a certificate corresponding to the submitted CSR. > For example: > > o If the CSR and order identifiers differ > > o If the account is not authorized for the identifiers indicated in > the CSR > > o If the CSR requests extensions that the CA is not willing to > include” > > [dh] I interpret the 3rd bullet above to be referring to both the > inclusion of the extension itself and the inclusion of extension values > (e.g., as part of its validation procedures, the CA can take into account > the fact that the JWTClaimConstraints Authority Token indirectly limits the > TNs identified in the CSR’s TNAuthList extension). > > >> >> 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. >> > > [dh] I agree, this is a valid point. The phrase "ACME challenge response" > was not meant to refer to a single ACME POST containing multiple challenge > responses, but to the multiple challenge responses sent via multiple POSTs. > But I get how this is confusing, and will clarify (if we decide to keep > this section). > > >> 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. >> > > [dh] Section 5.5.1 (and specifically 5.5.1.3) was added for two reasons: > 1) To describe how a JWTClaimConstraints Authority Token supports the case > where the permitted claims and claim values are authorized for a subset of > the TNs that the ACME client is authorized to use (e.g., The ACME client is > authorized to use TN-a and TN-b, and TN-a is authorized to use > calling-name-x while TN-b is authorized to use calling-name-y), and > 2) To place a requirement on the ACME server to verify that there is > overlap among the TN(s) in the CSR TNAuthList extension and the TN(s) > authorized by the two Authority Tokens before issuing the certificate. > > [dh] Do we agree that the mechanism described in section 5.5.1.3 is the > proper way to support this case? If yes, and if we agree that this is > useful information for developers – then where should it be described? > Given that this draft introduces a new Authority Token type that may > interact with the already-defined TNAuthList Authority Token in RFC 9448, > this draft seems to be a logical place to document these things. > > >> >> Therefore I believe that Section 5.5.1 can safely be deleted from the >> document. >> > > [dh] I think that it would help the developer community to describe these > things in this ACME draft. But am open to other proposals if the ACME W-G > feel strongly that this info is out-of-scope of this draft. > > >> --- >> >> 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
