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 -- [email protected] To unsubscribe send an email to [email protected]
