Thanks for sharing this! Below are my notes on the current draft: ---
In the last bullet of Section 1, I wouldn't say that this document "extends the ACME newOrder resource" -- if it does, then it equivalently also extends the order and authorization resources, which also contain Identifier subobjects. Instead, I think it is more concise and correct to say that this document extends the ACME IANA registries by registering a new identifier type and a new challenge type which can be used to validate identifiers of that type. --- I fully admit I don't understand the purpose of Section 5. It's not formatted like an introduction or an overview, but it doesn't appear to say anything that isn't better-said by Section 6. --- I would rearrange Section 6 to more closely reflect previous RFCs which have introduced new identifier types and corresponding challenges, such as RFC 8738 <https://www.rfc-editor.org/rfc/rfc8738.html>. Specifically, I believe the most readable flow here is: 1. Define the new identifier type (currently very vaguely defined in Section 6.5). Describe, as per RFC 8555, Section 7.4 <https://datatracker.ietf.org/doc/html/rfc8555#section-7.4>, where in the CSR these identifiers can appear (currently Section 6.7.1) 2. Define the new challenge type, how the client fulfills the challenge, and how the server validates the challenge (currently Section 6.7). This would also include Section 6.4.2, since the validation protocol requires that the Requestor's Entity Configuration Metadata be correct for validation to succeed. 3. Then, in a new top-level section, discuss discovery. This is where the Preconditions (currently Section 6.1), Discovery (Section 6.2), and Issuer Metadata (Section 6.4.1) would move to. This is placed lower in the document because, as far as I can tell, it's not actually necessary for the ACME challenge validation to succeed. It's just a mechanism for clients and servers to discover each other in a federation. I almost question whether it belongs in this document, as it is describing extensions to a non-ACME protocol, but this is probably fine. That's basically it. I think that Section 6.3 is unnecessary, as the contents flow described there is identical to the standard RFC 8555 flow, and readers should simply be referred to that document. I believe that Section 6.6 is unnecessary for the same reason: given a definition of a new identifier type, a description of how to create a newOrder request with that identifier contains no new information. --- Section 8 says that "it is up to the Certificate Issuer to decide the expiration time of the X.509 Certificate". This directly contradicts RFC 8555, which says that the client can specify a notAfter time, and the server MUST return an error if it cannot fulfill that request as specified. If you want to server to be able to adjust the expiration date based on the validity of the Trust Chain presented by the client, you'll need to say that clients MUST NOT include a notAfter in their newOrder request. Or simply say that Servers should consider whether they want to be able to do this adjustment, and if they do, then they should reject all requests which specify a notAfter. --- Thanks! Overall I really like this draft. I think there's a clear use-case here, I like the inclusion of autodiscovery, and I think the new identifier type and challenge type are well-thought-out. I mostly just think things need to be rearranged to present each new extension to the ACME protocol as standalone building blocks that together achieve the document's aim. Aaron On Tue, Jul 22, 2025 at 6:41 AM Leif Johansson <[email protected]> wrote: > These are the slides that we didn't get to today. > > Please read and comment on > https://datatracker.ietf.org/doc/draft-demarco-acme-openid-federation/ > > I am here in Madrid all week if anyone wants to chat. > > Cheers Leif > _______________________________________________ > 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]
