Thank you Aaron, Me and the editors now got something precious to continue our work along with your contribution. We'll try to summarize your notes within GitHub issues to include them within the present-future milestone and provide feedback here to you and people in the mailing list
best, Giuseppe Il mar 22 lug 2025, 23:21 Aaron Gable <aaron= [email protected]> ha scritto: > 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] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
