On 10/09/2018 07:45 AM, Richard Barnes wrote:
1. Remove GET for certificates. I think this is a mistake, but I can
grant that it's clunky as-is, and it will be straightforward to re-add
it later if it's needed.
Great.
2. Keep the security considerations about capability URLs and the
randomized examples. Those are needed for the correlation concerns
regardless of GET.
Ah, I had missed this. The relevant text:
> In order to avoid leaking these correlations, servers SHOULD assign
> capability URLs for dynamically-created resources
> {{?W3C.WD-capability-urls-20140218}}. These URLs incorporate large
> unpredictable components to prevent third parties from guessing
> them. These URLs SHOULD NOT have a structure that would enable a
> third party to infer correlations between resources.
This is not really the correct use of the term "capability URL," since
knowledge of a URL doesn't grant access to a resource. I would instead
just say "URLs with unpredictable components" (as the second sentence uses).
Also, I would add a caveat that this type of URL design is only
necessary for properties that the CA considers secret. For instance,
Let's Encrypt does not consider its number of accounts secret, and
assigns serially incrementing IDs to account URLs.
I'll send a PR later today tweaking this section. I'll also review #460
in more detail. In principle I'm not opposed to randomizing some of the
entity URLs where it helps demonstrate the concepts from the security
considerations section.
That said, I'd just like to reiterate: Capability URLs are *bad*. The
second sentence in https://www.w3.org/TR/capability-urls/ is:
"There are times when this is useful, for example one-shot password
reset URLs, but overuse can be problematic as URLs cannot generally be
kept secret."
I hope no one walks away from this conversation thinking "I'd like to
incorporate capability URLs into my next project!"
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
