Hi Sophie,
> Shouldn't the orders list objects be protected in the same way as the account > objects? I don't think so. Authorizations objects also contain domain names and are retrievable by GET. Why shouldn't an order be the same way? Are you also proposing that authorizations should be retrieved only by authenticated POST? Let's Encrypt recommends to use one account for all managed domains. But this > currently implies that all domains managed by an account can be retrieved > without authorization. This sounds like a privacy issue to me. That assumes an account order's list URL is predictable or can be learned without POSTing the account details, no? Let's Encrypt's ACME server doesn't implement the "orders" field of an account object at all, I don't think its a good example to reference for this argument. I think there's sufficient flexibility in the spec as-is for servers to devise a way to make orders accessible only to someone that can POST the account object if that's their preference. - Daniel / cpu On Tue, Mar 27, 2018 at 4:23 PM, Sophie Herold <[email protected]> wrote: > Hi, > > I raised this issue before but I think it was never really discussed. > > Section "7.3.3. Account Information" says > > > If a client wishes to query > > the server for information about its account (e.g., to examine the > > "contact" or "orders" fields), then it SHOULD do so by sending a POST > > request with an empty update. > > Shouldn't the orders list objects be protected in the same way as the > account objects? > > Let's Encrypt recommends to use one account for all managed domains. But > this currently implies that all domains managed by an account can be > retrieved without authorization. This sounds like a privacy issue to me. > > Best, > Sophie > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
