On Tue, Mar 27, 2018 at 9:16 PM, Sophie Herold <[email protected]> wrote:
> On 27/03/18 22:54, Daniel McCarney wrote: > > Are you also > > proposing that authorizations should be retrieved only by authenticated > > POST? > > 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. > 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 > guessable. > 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 > > That assumes an account order's list URL is predictable or can be learned > > 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 > > 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. > > "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 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
