Sent from my mobile device On Jul 24, 2025, at 9:41 AM, Q Misell <q=40as207960....@dmarc.ietf.org> wrote:
> 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.
In my view, the issue here is making normative text on how this identifier and challenge are to be used. That is, unintentionally restricting future use of the standard in a different way. It may be better as a non-normative motivation/discussion appendix.
Thank you, that was also good feedback in the meeting and aligns to the intent of the draft. I’ll make that change with the next update. It was a good suggestion.
Best regards, Kathleen
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574, LEI 875500FXNCJPAPF3PD10.
ICO register №: ZA782876.
UK VAT №: GB378323867.
EU VAT №: EU372013983.
Turkish VAT №: 0861333524.
South Korean VAT №: 522-80-03080.
AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532.
Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.
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 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 -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
|
