You seem to be trying to approach this point-by-point. What Adam and I
have been saying is that randomizing everything, you don't have to do the
analysis case by case. That's why that's the desired recommendation --
it's conservative.
If you want to do the analysis, go ahead. The URL plan is
So here's the compromise I would propose:
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.
2. Keep the security considerations about capability URLs and the
randomized examples.
I am also opposed to this change. I think it is a clunky solution and there
hasn't been convincing justification of why the base ACME draft needs to
carry this complexity instead of having STAR add the extensions it
requires.
On Mon, Oct 8, 2018 at 3:27 PM Jacob Hoffman-Andrews wrote:
> >
I'm strongly in favour of Jacob's suggestions in 459.
On Fri, Oct 5, 2018 at 7:17 PM Jacob Hoffman-Andrews wrote:
> Here's my proposal that removes the STAR special-casing in ACME, making
> certificate URLs behave the same way as all other fetchable resources:
>
> The narrow fix -- Remove "orders." No one implements it, and this is the
> least disruptive option to a mature spec.
I support this narrow fix.
On Mon, Oct 8, 2018 at 3:25 PM Jacob Hoffman-Andrews wrote:
> The POST-as-GET mess started because Adam Roach pointed out that the
> "orders" URL
On 10/09/2018 03:28 PM, Diego R. Lopez wrote:
If I understood this compromise proposal, that implies to put STAR out
of play… Or am I missing something?
Not at all, it just means that STAR needs to define a new field on the
Order resource that specifies a polling URL for frequently-updating
If I understood this compromise proposal, that implies to put STAR out of play…
Or am I missing something?
--
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/
e-mail:
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
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
