Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-11 Thread Salz, Rich
* Chairs: It looks like there's consensus among the author team to close out this discussoin by merging #459, #460, and #463. Is that all right with you? Yes. Thanks for everyone working so hard on this at the last minute, and coming to agreement. If anyone on the WG objects to the

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-10 Thread Richard Barnes
Chairs: It looks like there's consensus among the author team to close out this discussoin by merging #459, #460, and #463. Is that all right with you? On Wed, Oct 10, 2018 at 5:23 PM Jacob Hoffman-Andrews wrote: > Pushed some more changes. > > On 10/10/2018 02:06 PM, Jacob Hoffman-Andrews

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-10 Thread Jacob Hoffman-Andrews
Pushed some more changes. On 10/10/2018 02:06 PM, Jacob Hoffman-Andrews wrote: Updated to include Orders and Authorizations in the example as you requested. https://github.com/ietf-wg-acme/acme/pull/463/files On 10/09/2018 04:49 PM, Jacob Hoffman-Andrews wrote: I'll revise this to include

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-10 Thread Jacob Hoffman-Andrews
Updated to include Orders and Authorizations in the example as you requested. https://github.com/ietf-wg-acme/acme/pull/463/files On 10/09/2018 04:49 PM, Jacob Hoffman-Andrews wrote: I'll revise this to include examples from the other URLs. One of my goals is to switch away from the

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-10 Thread Tim Hollebeek
I suspect that the guessable account numbers is something the LE folks will eventually regret for one reason or another. It’s poor security design to make something public and/or guessable if it doesn’t need to be. -Tim From: Acme On Behalf Of Richard Barnes Sent: Tuesday, October

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-09 Thread Richard Barnes
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

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-09 Thread Jacob Hoffman-Andrews
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

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-09 Thread Diego R. Lopez
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:

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-09 Thread Richard Barnes
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

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-09 Thread Jacob Hoffman-Andrews
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

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-09 Thread Richard Barnes
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.

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-09 Thread Daniel McCarney
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: > >

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-08 Thread Eric Rescorla
Thanks for clarifying. On Mon, Oct 8, 2018 at 10:58 AM Salz, Rich wrote: > >- No, because GET+capability > GET. If you're going to have GET at >all, you should have GET+capability > > > > And more importantly, you do not HAVE to do it; the text just has pointers > on how to do it if

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-08 Thread Jacob Hoffman-Andrews
> https://github.com/ietf-wg-acme/acme/pull/462 I'm

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-08 Thread Salz, Rich
* No, because GET+capability > GET. If you're going to have GET at all, you should have GET+capability And more importantly, you do not HAVE to do it; the text just has pointers on how to do it if desired. ___ Acme mailing list Acme@ietf.org

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-08 Thread Richard Barnes
No, because GET+capability > GET. If you're going to have GET at all, you should have GET+capability. On Mon, Oct 8, 2018 at 12:43 PM Eric Rescorla wrote: > My question is whether you would remove the text that JSHA was objecting > to about capabilities URLs. > > On Mon, Oct 8, 2018 at 6:31 AM

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-08 Thread Eric Rescorla
My question is whether you would remove the text that JSHA was objecting to about capabilities URLs. On Mon, Oct 8, 2018 at 6:31 AM Richard Barnes wrote: > Not sure which existing text you're referring to. No conflict comes to > mind. > > In particular, this seems compatible with the stuff in

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-08 Thread Richard Barnes
Not sure which existing text you're referring to. No conflict comes to mind. In particular, this seems compatible with the stuff in #post-as-get about how the server indicates that it doesn't allow GET. The model I have in mind is that this flag indicates that it's reasonable for the client to

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

2018-10-08 Thread Eric Rescorla
Speaking as an individual. Just to be clear, this change would be expected to coexist with the existing capabilities text? Richard, does it require that we retain that text? -Ekr On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich wrote: > WG, this PR adds a new optional indicator that GET can be used