I'll revise this to include examples from the other URLs. One of my
goals is to switch away from the "counting accounts" or "counting
authzs" examples (which I think we can't effectively mitigate) to more
specific examples of correlations. However, I think I can make that
point with examples from across all the different resource types.
On 10/09/2018 12:27 PM, Richard Barnes wrote:
Thanks for the PR.
My only issue is with the changes in there that slim down the
example. ISTM that we should be encouraging unguessable URLs as
widely as possible; guessable URLs should be a justified exception (as
you noted in your description of what LE does).
If you could slim this down to just killing the "Capability URL"
reference, I would be +1
On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews <j...@eff.org
<mailto:j...@eff.org>> wrote:
On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote:
> 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.
Here's a PR improving the correlations section of security concerns:
https://github.com/ietf-wg-acme/acme/pull/463
_______________________________________________
Acme mailing list
Acme@ietf.org <mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
