Hi Tim! Ah yes, the "Who is the audience?" question. I think you're right that you don't want to repeat core content from ACME RFCs nor from the OIDC spec (both because repetition is bad, and because you want to give those specs space to change in the future).
> I think it's fair to expect that readers of this document are familiar with the OpenID Federation (OIDF) specification ( https://openid.net/specs/openid-federation-1_0.html). I think that may be true for the final RFC publication, but also consider that you have submitted this document to the IETF ACME WG, so it also needs to be written for the technical reviewers here who know ACME well but don't know OIDF that well (Aaron and myself are probably reasonable representatives). To that point, I don't think it's reasonable to expect members of the ACME WG to suddenly become experts in OIDC / OIDF because we are handling one ACME-OIDF cross-over document. One trick I have seen done in Internet Drafts is to put an EDNOTE block with additional explanatory content that is intended only for the review process; something like: ~~~ BEGIN EDNOTE ~~~ To be removed before publication. blah blah blah ~~~ END EDNOTE ~~~ Regardless of all that, I think it's reasonable to put some text in the Introduction that says whether we're talking about server certs (ie the DN / SANs will be DNS Names), or human certs (ie the DN / SANs will be a name, and email address, or equivalent human identifier). When I think of OIDC, I think of a human at a login page in a browser doing MFA with a Passkey and then getting HTTP redirected back to the RP site, and I got pretty deep into this document before realizing that's probably not what's going on here (and having gotten to the bottom, I think we're talking about federated DNS names for TLS server certs, but I'm honestly still not completely sure). I'm not asking for any normative technical changes; but I think a fluffy paragraph or two in the Intro that explains the intended use case would give the reader the context to understand where this document fits in the world. Some of the text you put in your last email would do nicely. To this point: > The trust mechanism here is OpenID Federation. OIDF is conveyed over TLS, but the Entity Statements it uses are JWTs whose integrity and trust can be evaluated in the context of an OpenID Federation hierarchy, independently of trust at the transport layer. I'd argue that it's the job of the OpenID Federation specification to discuss the relationship between TLS trust and OIDF trust, not this document. That sort of thing would go well into the Security Considerations section. I have in the past seen Sec Cons that say something like "It is imperative for security that the Link Layer be configured correctly according to <link to 500 page manual>". That's fine, Security Considerations don't need to be a thorough and complete manual, but they do need to mention anything that the security model of this document takes as an assumption. On Wed, 30 Jul 2025 at 09:57, Tim Geoghegan <timgeog+i...@gmail.com> wrote: > Hi Mike, > > [just in case email headers get mangled: I am responding to Mike > Ounsworth's message > https://mailarchive.ietf.org/arch/msg/acme/qCeNQ_gHnMI4RRsa_Yl1oLqlQus/] > > Thanks for taking the time to review the document. > > I do have some feedback, which I suspect all has a root-cause that the >> Intro is not concrete enough and I’m confused about whether we are talking >> about TLS server certs? human email certs? human-attached device certs? >> Something else? > > > I think you're right about the root cause issue here. This touches on an > ever-tricky question for technical documents like this: who is the > audience? Is it ACME experts who need help understanding some OpenID > Federation essentials? Or conversely, is it OpenID Federation experts who > need a tutorial on how ACME works? Your observations echo and mirror the > feedback we got from Aaron Gable ( > https://mailarchive.ietf.org/arch/msg/acme/MwoKF7sluK0w-Q7hLaOqey3Xmbs/) > that there's too much material that re-explains how ACME works. > > I think it's fair to expect that readers of this document are familiar > with the OpenID Federation (OIDF) specification ( > https://openid.net/specs/openid-federation-1_0.html). For the same > reasons that we wouldn't want this document to repeat material from RFC > 8555, we wouldn't want it to step on OIDF's toes. > > The document editors have discussed publishing a separate document, > perhaps just in a GitHub repository wiki, that provides all this contextual > and motivating information, so that the draft that ACME (hopefully) takes > on can stick to specifying mechanisms. Thus the intended audience is ACME > implementers who want to know what they have to add to their CA > implementation, and OIDF entity operators who want to know what kind of > entity metadata they need to advertise in order to get certs. > > > https://github.com/peppelinux/draft-demarco-acme-openid-federation/issues/104 > > To answer your question: the value of the new ACME identifier type is the > OIDF Entity Identifier, but this document doesn't spell out any issuance > profile for CAs using this challenge type. We do define a new otherName > type for OpenID Federation entity identifiers, but the issued cert could > instead or also contain a CommonName, or a dnsName SAN, or an IP address, > or anything at all, based on either the client's CSR or other metadata > advertised in the requestor's OpenID Federation metadata, alongside the > `acme_requestor` defined in this document. > > That's perhaps frustratingly vague, but the motivation here is that we > have groups (government departments, universities, whatever) that want to > use OIDF as the source of truth for entity metadata, hierarchical trust and > federation of trust. But, there are legacy systems and appliances out there > that need X.509 certificates and won't be updated to learn about OIDF and > its JWTs. So this ACME extension is intended as a bridge. The exact nature > of the certs needed will depend on the particulars of each legacy system > (e.g., maybe *this* printer needs a cert with a special OID in it but > *that* combine harvester needs a particular SAN), so it's hard for this > specification to get concrete about it without losing the flexibility that > makes it valuable. > > I got almost all the way through this document assuming >> that “Identifiers” referred to some human thing like an email address, and >> only somewhere around the middle of section 6 did I start to suspect that >> we’ve been talking about DNS Name certs the whole time. … are we talking >> exclusively about DNS Name certs? Is that the only type of identifier that >> OpenID Federation 1.0 can federate, or are other things possible? > > > Sadly the term "identifier" is overloaded here since ACME and OIDF both > define it! We should clarify when we mean an ACME Identifier (since this > document defines a new identifier type) and an OpenID Federation *Entity > Identifier* ( > https://openid.net/specs/openid-federation-1_0.html#section-1.2-3.4). We > can also put something in our "Terminology" section introducing the OIDF > entity identifier. > > > https://github.com/peppelinux/draft-demarco-acme-openid-federation/issues/103 > > Section 6.3. >> This may get answered later, but normally the point of an ACME http-01 >> challenge, the host to which the ACME server will react out is related to >> the requested cert identifier. >> Here, I assume you’re requesting a cert for a human name, and you’re sent >> to server to obtain an Entity Configuration to validate that identity. Ok. >> How is the domain name of the server determined in this case? Is there >> some >> authoritative binding between the Federation Entity and the server on >> which >> their Entity Configuration will be hosted? > > > An OpenID Federation Entity Identifier is itself an https URL relative to > which the OpenID Federation Entity's Entity Configuration may be fetched, > from a `.well-known` path. This is laid out in the OIDF specification. > > Why do we need a level of indirection here? Why can’t the requestor just >> upload the Entity Configuration blob directly embedded in the POST >> /new-order ? > > > This is a neat idea, but I'm not sure how we'd do it in ACME. A new order > request (https://datatracker.ietf.org/doc/html/rfc8555/#section-7.4) > doesn't have an obvious place to stick a big JSON blob like the EC, and I > think it'd be awkward to smuggle it into the ACME identifier, inside the > "value". > > Maybe we could do this during challenge verification, though. I've filed > an issue to discuss this idea further: > https://github.com/peppelinux/draft-demarco-acme-openid-federation/issues/105 > > If so, I think there are security questions to be asked about whether you >> trust the host of that server, and what can go wrong if you don’t. > > > The trust mechanism here is OpenID Federation. OIDF is conveyed over TLS, > but the Entity Statements it uses are JWTs whose integrity and trust can be > evaluated in the context of an OpenID Federation hierarchy, independently > of trust at the transport layer. I'd argue that it's the job of the OpenID > Federation specification to discuss the relationship between TLS trust and > OIDF trust, not this document. > > Editorial point: the flow diagram figure is very wide and does not render >> well in in the fixed-width HTML doc. You may need to do some creative >> re-modelling to how this is structured. > > > Since the flow diagram restates a lot of the ACME order flow from 8555, I > think we're likely to punt it to the explainer doc. > > I assume these is the set of public keys that can act as ACME Client >> Account keys for requesting certs for this Federation Entity? This should >> be stated explicitly in 6.3. > > > Yes, you're right. This has been clarified on `main` since we cut -00. > > Thanks for the feedback, > Tim > > > _______________________________________________ > 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
