I'm not hard set against this change, I just don't see much benefit. Allowing GETs for certificate URLs is so low-risk that we weren't going to access-control it at all until a couple weeks ago. Now it's so high-risk that we need to REQUIRE authentication? That's "REQUIRED" in the RFC 2119 sense, since higher up in the section, it says that servers MUST return 405 if they get a GET, except as allowed in that section.
There are reasonable use cases for GETs. STAR is one, but you could imagine non-auto-renewed cases as well. There's no security reason to cut off those GETs, so I don't understand what value we're conserving here. The PR says that having GETs complicates the security analysis, but this is not some inner part of the protocol, it's the output. The only argument that seems at all cogent here is that we don't have any up-front signaling for whether a server supports GET or not, just the error code. So clients have to guess. Maybe that's enough to motivate removing it for now; a later doc could come along and say "allow GETs and signal it with this field in the meta object". But if we do that, we should be clear that we're removing GET to keep the protocol flow clean, not for any security reason. --Richard On Sat, Oct 6, 2018 at 12:53 PM Eric Rescorla <[email protected]> wrote: > Speaking as Area Director: there is no process problem with this > reference. Of course, it's a WG decision whether it's advisable. > > -Ekr > > > On Sat, Oct 6, 2018 at 8:31 AM Salz, Rich <[email protected]> wrote: > >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
