Hi ACME!
[review as an individual]
This is a well-written document that explains its motivation and usecase
very well.
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 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?
Specific comments:
Section 2 Use Cases: is it possible to make this more concrete? Are these
human entities? Automated clients? Servers? All of the above?
I see in Section 3 that “It operates a web server for hosting its Entity
Configuration.”, but this still doesn’t tell me whether the requestor is a
human or not.
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?
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 ?
Requestor’s
OpenID Federation
Web Server
Anchor
ACME Server
| GET /.well-known/openid-federation |
|<----------------------------------------------------
UPDATE, does it come from here?
POST /acme/new-order HTTP/1.1
…
"payload": base64url({
"identifiers": [
{
"type": "openid-federation",
"value": "https://requestor.example.com";
}
??
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.
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.
"metadata": {
"acme_requestor": {
"jwks": {
"keys": [
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.
_______________________________________________
Acme mailing list -- [email protected]
To unsubscribe send an email to [email protected]
