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

[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 changes in the PR, please speak up now.  
Discussion has gone on for some time, and this addresses IESG review.  We’re 
not going to redo WGLC, but expect the next draft to be “it”
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 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 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  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
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
>
>
> ___
> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme
>
>
>
>
> ___
> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 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 > 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 
https://www.ietf.org/mailman/listinfo/acme





___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme




___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 "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 > 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 
https://www.ietf.org/mailman/listinfo/acme





___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 9, 2018 8:19 PM
To: Jacob Hoffman-Andrews 
Cc: IETF ACME 
Subject: Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when 
GET requests for certificates are allowed (#462)

 

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 100% up to the 
server operator.  But the recommendation in the spec should be the conservative 
one.

 

--Richard

 

On Tue, Oct 9, 2018 at 7:49 PM Jacob Hoffman-Andrews mailto:j...@eff.org> > wrote:

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 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

 



smime.p7s
Description: S/MIME cryptographic signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 100% up to the
server operator.  But the recommendation in the spec should be the
conservative one.

--Richard

On Tue, Oct 9, 2018 at 7: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 "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  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
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Jacob Hoffman-Andrews]

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 > 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 
https://www.ietf.org/mailman/listinfo/acme



___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 
certificates. This is probably a good thing anyhow, since the semantics 
of STAR are different than the normal semantics of baseline ACME. In 
baseline ACME, the contents of the certificate URL generally don't 
change after issuance, but in STAR, the goal is to have some URL whose 
contents are expected to change periodically to contain the most 
recently issued certificate for the relevant names.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 09/10/2018, 16:46, "Acme on behalf of Richard Barnes" 
mailto:acme-boun...@ietf.org> on behalf of 
r...@ipv.sx> wrote:

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.  Those are needed for the correlation concerns regardless of GET.

In units of PRs, I think that means:
- Merge #459 (remove GET for certificates)
- Merge #460 (randomize URLs)
- Close #462 (meta flag for GET; obsoleted by #459)
- Close #457 (remove recommendation for capability URLs; obsoleted by #459)

Jacob, Daniel: How does that strike you?

--Richard

On Tue, Oct 9, 2018 at 10:32 AM Daniel McCarney 
mailto:c...@letsencrypt.org>> wrote:
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 
mailto:j...@eff.org>> wrote:

>   
> https://github.com/ietf-wg-acme/acme/pull/462

I'm opposed to this change. It's better for STAR to just extend the Order 
object with a new "gettableCert" URL field. Less complex.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 just killing the "Capability URL" reference,
I would be +1

On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews  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
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Jacob Hoffman-Andrews]

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
https://www.ietf.org/mailman/listinfo/acme

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

[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 
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

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

[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.  Those are needed for the correlation concerns
regardless of GET.

In units of PRs, I think that means:
- Merge #459 (remove GET for certificates)
- Merge #460 (randomize URLs)
- Close #462 (meta flag for GET; obsoleted by #459)
- Close #457 (remove recommendation for capability URLs; obsoleted by #459)

Jacob, Daniel: How does that strike you?

--Richard

On Tue, Oct 9, 2018 at 10:32 AM Daniel McCarney  wrote:

> 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:
>
>> >   https://github.com/ietf-wg-acme/acme/pull/462
>> 
>>
>> I'm opposed to this change. It's better for STAR to just extend the Order
>> object with a new "gettableCert" URL field. Less complex.
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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:

> >   https://github.com/ietf-wg-acme/acme/pull/462
> 
>
> I'm opposed to this change. It's better for STAR to just extend the Order
> object with a new "gettableCert" URL field. Less complex.
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 desired.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Jacob Hoffman-Andrews]

> https://github.com/ietf-wg-acme/acme/pull/462 
 



I'm opposed to this change. It's better for STAR to just extend the 
Order object with a new "gettableCert" URL field. Less complex.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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
https://www.ietf.org/mailman/listinfo/acme

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

[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 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 #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 try
>> GET, but the server may still deny in some cases.  Maybe that could be
>> clarified.
>>
>> On Mon, Oct 8, 2018, 09:24 Eric Rescorla  wrote:
>>
>>> 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 to fetch
 certificates.



 If you opposed please speak up now.



 *From: *Richard Barnes 
 *Reply-To: *ietf-wg-acme/acme <
 reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
 >
 *Date: *Sunday, October 7, 2018 at 3:47 PM
 *To: *ietf-wg-acme/acme 
 *Cc: *Subscribed 
 *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
 requests for certificates are allowed (#462)



 This avoids the need for the client to guess. Assumes that #459
 
 will not be merged.
 --
 You can view, comment on, or merge this pull request online at:

   https://github.com/ietf-wg-acme/acme/pull/462
 
 Commit Summary

- Add a meta flag to indicate when GET requests for certificates
are allowed

 File Changes

- *M* draft-ietf-acme-acme.md

 
(4)

 Patch Links:

- https://github.com/ietf-wg-acme/acme/pull/462.patch

 
- https://github.com/ietf-wg-acme/acme/pull/462.diff

 

 —
 You are receiving this because you are subscribed to this thread.
 Reply to this email directly, view it on GitHub
 ,
 or mute the thread
 
 .[image:
 https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
 ___
 Acme mailing list
 Acme@ietf.org
 https://www.ietf.org/mailman/listinfo/acme

>>> ___
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 #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 try
> GET, but the server may still deny in some cases.  Maybe that could be
> clarified.
>
> On Mon, Oct 8, 2018, 09:24 Eric Rescorla  wrote:
>
>> 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 to fetch
>>> certificates.
>>>
>>>
>>>
>>> If you opposed please speak up now.
>>>
>>>
>>>
>>> *From: *Richard Barnes 
>>> *Reply-To: *ietf-wg-acme/acme <
>>> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
>>> >
>>> *Date: *Sunday, October 7, 2018 at 3:47 PM
>>> *To: *ietf-wg-acme/acme 
>>> *Cc: *Subscribed 
>>> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
>>> requests for certificates are allowed (#462)
>>>
>>>
>>>
>>> This avoids the need for the client to guess. Assumes that #459
>>> 
>>> will not be merged.
>>> --
>>> You can view, comment on, or merge this pull request online at:
>>>
>>>   https://github.com/ietf-wg-acme/acme/pull/462
>>> 
>>> Commit Summary
>>>
>>>- Add a meta flag to indicate when GET requests for certificates are
>>>allowed
>>>
>>> File Changes
>>>
>>>- *M* draft-ietf-acme-acme.md
>>>
>>> 
>>>(4)
>>>
>>> Patch Links:
>>>
>>>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>>>
>>> 
>>>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>>>
>>> 
>>>
>>> —
>>> You are receiving this because you are subscribed to this thread.
>>> Reply to this email directly, view it on GitHub
>>> ,
>>> or mute the thread
>>> 
>>> .[image:
>>> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
>>> ___
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 try
GET, but the server may still deny in some cases.  Maybe that could be
clarified.

On Mon, Oct 8, 2018, 09:24 Eric Rescorla  wrote:

> 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 to fetch
>> certificates.
>>
>>
>>
>> If you opposed please speak up now.
>>
>>
>>
>> *From: *Richard Barnes 
>> *Reply-To: *ietf-wg-acme/acme <
>> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
>> >
>> *Date: *Sunday, October 7, 2018 at 3:47 PM
>> *To: *ietf-wg-acme/acme 
>> *Cc: *Subscribed 
>> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
>> requests for certificates are allowed (#462)
>>
>>
>>
>> This avoids the need for the client to guess. Assumes that #459
>> 
>> will not be merged.
>> --
>> You can view, comment on, or merge this pull request online at:
>>
>>   https://github.com/ietf-wg-acme/acme/pull/462
>> 
>> Commit Summary
>>
>>- Add a meta flag to indicate when GET requests for certificates are
>>allowed
>>
>> File Changes
>>
>>- *M* draft-ietf-acme-acme.md
>>
>> 
>>(4)
>>
>> Patch Links:
>>
>>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>>
>> 
>>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>>
>> 
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub
>> ,
>> or mute the thread
>> 
>> .[image:
>> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[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 to fetch
> certificates.
>
>
>
> If you opposed please speak up now.
>
>
>
> *From: *Richard Barnes 
> *Reply-To: *ietf-wg-acme/acme <
> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
> >
> *Date: *Sunday, October 7, 2018 at 3:47 PM
> *To: *ietf-wg-acme/acme 
> *Cc: *Subscribed 
> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
> requests for certificates are allowed (#462)
>
>
>
> This avoids the need for the client to guess. Assumes that #459
> 
> will not be merged.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/ietf-wg-acme/acme/pull/462
> 
> Commit Summary
>
>- Add a meta flag to indicate when GET requests for certificates are
>allowed
>
> File Changes
>
>- *M* draft-ietf-acme-acme.md
>
> 
>(4)
>
> Patch Links:
>
>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>
> 
>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>
> 
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 
> .[image:
> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme