In order to address an issue raised during IESG review, unauthenticated GET for
ACME server resources was changed to a simple POST that had a signed message
body, providing authentication. Some raised the issue that they still wanted
GET for certificates, as they’re public information and that sometimes a
different process (without the account credentials) might be involved in the
deployment workflow. STAR was mentioned as an example.
There is now concern about calling out STAR, as it is still a WG draft and the
full extent of its requirements are not known.
If you have anything else to add to this discussion, please do so now.
diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
index 26eeeef..f1ca93f 100644
--- a/draft-ietf-acme-acme.md
+++ b/draft-ietf-acme-acme.md
@@ -463,17 +463,6 @@ resources (see {{resources}}), in addition to POST-as-GET
requests
for these resources. This enables clients to bootstrap into the
ACME authentication system.
-The server MAY allow GET requests for certificate resources in
-order to allow certificates to be fetched by a lower-privileged
-process, e.g., the web server that will use the referenced
-certificate chain. (See {{?I-D.ietf-acme-star}} for more advanced
-cases.) A server that allows GET requests for certificate resources
-can still provide a degree of access control by assigning them
-capability URLs {{?W3C.WD-capability-urls-20140218}}.
-As above, if the server does not allow GET requests for a given
-resource, it MUST return an error with status code 405 "Method Not
-Allowed" and type "malformed".
-
## Request URL Integrity
It is common in deployment for the entity terminating TLS for HTTPS to be
different
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
