Subject: [Acme] Reminder: Orders List

From: Sophie Herold <[email-masked]>
Date: Tue, 27 Mar 2018 22:23:35 +0200

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

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 27 Mar 2018 16:54:18 -0400

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-masked]>
wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Sophie Herold <[email-masked]>
Date: Tue, 27 Mar 2018 23:16:06 +0200

On 27/03/18 22:54, Daniel McCarney wrote:
> Are you also

The information contained in an order will be (more or less) part of the
certificate. Therefore, it seems plausible that this information is not
"that" private.

By the way, I did propose that *all* generated GET URLs shouldn't be
guessable.

> without POSTing the account details, no?

Yes. And right now, I don't see why this is different from account URLs,
which have "MUST NOT respond to GET requests".

Note, that the example contains the orders URL
"https://example.com/acme/acct/1/orders". This sound pretty guessable to
be.

> Let's Encrypt's ACME server

"orders" is a required key and LE committed to never implementing it?
Doesn't that sounds like an argument for removing this feature from this
spec?

Best,
Sophie

---

From: Richard Barnes <[email-masked]>
Date: Tue, 27 Mar 2018 21:30:45 +0000

> certificate. Therefore, it seems plausible that this information is not

This is certainly my understanding.  That is, account objects are private,
because they have things like contact info.  But everything else is OK to
be public, i.e., accessible by GET.

> By the way, I did propose that *all* generated GET URLs shouldn't be

FWIW, the term of art that gets used for this is "capability URL".  Was
there a PR where you proposed this, Sophie?

https://www.w3.org/TR/capability-urls/

TBH, I don't see a lot of mileage in adding this requirement.  If CAs
consider certain resources sensitive, then they can make capability URLs,
but I don't think most ACME resources merit it.  I would be OK adding a
note to the Operational Considerations or Security Considerations
suggesting capability URLs, but not a requirement.

--Richard