Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

[Yaron Sheffer]

On 25/06/17 03:52, Martin Thomson wrote:

On 24 June 2017 at 02:24, Yaron Sheffer  wrote:

Expires is to ensure that the certificate is not
cached beyond the point where a newer certificate will be issued.  You
should remove this text.

OK

Is there some other common header to denote that the value of a URL is only
good for X time?

Isn't enough to rely on the server echoing your parameters?  (Another
reason to use absolute values for the end of the recurring interval.)
I'm not following you. In Sec. 3.4 we're saying that the (periodically 
rolling) certificate is always available on the same URL, the 
"certificate endpoint". Since the content available at that URL changes 
from time to time, we wanted to indicate its end-of-validity with an 
HTTP header. If "Expires" is not the right header, is there a better way 
to do it?



Don't mention time-sensitive policy actions by the CA/B Forum.

Makes sense.

I disagree. CA/B forum decisions (unlike IETF standards) are mandatory for
some parties to follow and so can be relied upon by the DNO.

This is a protocol.  What CABF do with it is entirely up to them.
They aren't the only ones creating policy that might affect someone
using this protocol.
But people are not obligated to implement IETF protocols. OTOH some 
organizations *are* bound by CA/B Forum rules. And this section is 
predicated on the assumption at all "reasonable" CAs do honor CAA 
records, otherwise a rogue CDN employee can create a certificate for the 
domain on a non-ACME CA, if they only require a proof of ownership of 
the web server.



Can't you simply ensure that the CDN can't modify the CAA record?

This is the minimum we could say.  At this point, I think we are trying
to explore a bit what other mitigations can be put in place.

Unfortunately this is insufficient, because in the case of CDN's, some of
the authorization methods are subject to spoofing.

If the CAA record exists, then spoofing won't result in the
certificate being issued, so what is the problem?
Basic CAA, prior to Hugo's draft, only says which CA you are trusting. 
But that CA can still choose the spoofable http-01 authorization - 
spoofable if you are the CDN and so you control the web pages.


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

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

[Martin Thomson]

On 24 June 2017 at 02:24, Yaron Sheffer  wrote:
>>> Expires is to ensure that the certificate is not
>>> cached beyond the point where a newer certificate will be issued.  You
>>> should remove this text.
>>
>> OK
>
> Is there some other common header to denote that the value of a URL is only
> good for X time?

Isn't enough to rely on the server echoing your parameters?  (Another
reason to use absolute values for the end of the recurring interval.)

>>> Don't mention time-sensitive policy actions by the CA/B Forum.
>>
>> Makes sense.
>
> I disagree. CA/B forum decisions (unlike IETF standards) are mandatory for
> some parties to follow and so can be relied upon by the DNO.

This is a protocol.  What CABF do with it is entirely up to them.
They aren't the only ones creating policy that might affect someone
using this protocol.

>>> Can't you simply ensure that the CDN can't modify the CAA record?
>>
>> This is the minimum we could say.  At this point, I think we are trying
>> to explore a bit what other mitigations can be put in place.
>
> Unfortunately this is insufficient, because in the case of CDN's, some of
> the authorization methods are subject to spoofing.

If the CAA record exists, then spoofing won't result in the
certificate being issued, so what is the problem?

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

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

[Yaron Sheffer]

Hi Martin, Thomas,

Hi Martin,

Thanks for your review.

On 19/06/2017, 23:34, "Acme on behalf of Martin Thomson"  wrote:

A few brief comments on this draft.


[snip]

I don't understand Section 3.3 at all.  I'd recommend removing this
section.  The DNO will decide what authorizations it requests amply
without this level of proscription in standards.

Yaron: thoughts on this?
This is yet another LURK leftover, where we make assumptions about the 
capabilities of the NDC. Prescription makes sense in some particular 
cases, but I agree this should be folded into the security 
considerations (specifically Sec. 5.1) instead of the protocol's body.



In Section 3.4, the use of the Expires header field is a common
mistake.  This is an HTTP caching directive.  It should probably be
shorter than the expiration time of the certificate (half in fact),
but not for the reasons that you might think.  The purpose of a
recommendation on Expires is to ensure that the certificate is not
cached beyond the point where a newer certificate will be issued.  You
should remove this text.

OK
Is there some other common header to denote that the value of a URL is 
only good for X time?


[snip]




Don't mention time-sensitive policy actions by the CA/B Forum.

Makes sense.
I disagree. CA/B forum decisions (unlike IETF standards) are mandatory 
for some parties to follow and so can be relied upon by the DNO.



Can't you simply ensure that the CDN can't modify the CAA record?

This is the minimum we could say.  At this point, I think we are trying
to explore a bit what other mitigations can be put in place.
Unfortunately this is insufficient, because in the case of CDN's, some 
of the authorization methods are subject to spoofing.


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

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

Hi Martin,

Thanks for your review.

On 19/06/2017, 23:34, "Acme on behalf of Martin Thomson"  wrote:
> 
> A few brief comments on this draft.
> 
> On 16 June 2017 at 22:19,   wrote:
> This memo proposes an ACME extension to enable the issuance of short-
> term and automatically renewed certificates.  This allows a domain
> name owner to delegate the use of certificates to another party,
> while retaining the capability to cancel this delegation at any time
> with no need to rely on certificate revocation mechanisms.
> 
> I found the introduction overly specific.  The generic use case is to
> simplify the deployment of certificates to unprivileged nodes.  The
> unprivileged nodes then only need to be configured with a URL for
> their certificates.
> 
> That requires a couple of paragraphs of exposition at most.  This
> extends to Section 2, which describes a system architecture that
> implies the existence of protocol elements that are simply not defined
> in this document.
> 
> Sections 1 and 2 could much more clearly describe what *this* document
> provides.  It provides an extension to ACME that allows for the
> creation of a certificate that automatically renews.
> 
> The focus on the CDN case affects the entire document.  The point is
> that the authorized entity is delegating the ability to use a
> certificate for its name to an unprivileged node.  Don't use "CDN",
> "content owner" or any of these highly specific terms.  Use generic
> terms; make new terms if necessary.  FWIW, while NDC is a cute
> reversal, "consumer" really isn't accurate.

Agree, there is still a bit of LURK baggage attached (especially here,
but also in a few other points).

We will do an editorial pass to streamline the document before -01
and take in the suggestions above.

> draft-iab-web-pki-problems has been abandoned.  It's not a great idea
> to cite it.

OK, will drop the reference -- too bad, though.

> In Section 3.1.1, I think that the resolution of these fields, being
> in days, is not conducive to reducing granularity.  (Or will you
> permit 5.7e-3 as a value?)

Seconds granularity then?  32 bit should be enough for >100 years while
allowing baryon-like lifetimes on the other end of the scale :-)

(Personally, I'd avoid any string representation, but that's my taste.)

> Section 3.1.1 needs to clearly articulate how
> "recurrent-certificate-validity" (could this be any more verbose and
> hard to type?) relates to "expires".

OK

> Please include a definition for the new attributes, rather than just
> providing an example and commenting the JSON.

OK

> In Section 3.1.2, you REALLY, REALLY need to authenticate this
> request.  

Sure.  Every non-RO operation needs to be authenticated.  We forgot to
be explicit about that; thanks for spotting it.

> My suggestion is to change this to a POST request with {
> "recurrent": false }.  (I'd have suggested PUT or PATCH, but ACME's
> reliance on JWS perverts that in ways that is incompatible with those
> methods.)

I have no strong opinion about the syntax of the order termination.
DELETE just seemed the most natural to me (certainly more
straightforward than POSTing '{ "recurrent": false }'), but I'm probably
missing something?

> In Section 3.2, the discussion about a Proxy is misleading.  The only
> relevant actor in this is an ACME client.  This section could be
> reduced to:
> 
> An ACME client discovers whether a server supports this extension by
> examining a newly created order.  The "recurrent" member will exist if
> the server supports automatic recurring certificate issuance; the
> "recurrent" member will be true if the server accepts the request.

Yes, agreed.  This is another example of the LURK clean-out that we need
to finish off.

> Can the server specify a shorter value for "recurrent-total-lifetime"?

Yes.  And if the client is not happy with the chosen value I guess it
will just abandon the order and let it expire (as suggested in 3.2).

> I don't understand Section 3.3 at all.  I'd recommend removing this
> section.  The DNO will decide what authorizations it requests amply
> without this level of proscription in standards.

Yaron: thoughts on this?

> In Section 3.4, the use of the Expires header field is a common
> mistake.  This is an HTTP caching directive.  It should probably be
> shorter than the expiration time of the certificate (half in fact),
> but not for the reasons that you might think.  The purpose of a
> recommendation on Expires is to ensure that the certificate is not
> cached beyond the point where a newer certificate will be issued.  You
> should remove this text.

OK

> Section 5.1 should be promoted to Section 5

OK

> Don't mention time-sensitive policy actions by the CA/B Forum.

Makes sense.

> Can't you simply ensure that the CDN can't modify the CAA record?

This is the minimum we could say.  At this point, I think we are 

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

[Salz, Rich]

As chair: Thanks for the detailed review.  

As an individual: I agree we need a new term other than CDN. All the good words 
are taken, but perhaps Agent works?

> draft-iab-web-pki-problems has been abandoned.

I didn't notice that.  Rats.



--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richs...@jabber.at Twitter: RichSalz

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

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

[Martin Thomson]

One further thought. ACME uses an absolute time for expiration. This uses a
relative time. I think that I prefer the former. I realize that consistency
might be impossible in this case, since the recurrent duration is
necessarily relative, but I though it worth raising.

On 19 Jun. 2017 10:08 am, "Martin Thomson"  wrote:

> A few brief comments on this draft.
>
> On 16 June 2017 at 22:19,   wrote:
> >This memo proposes an ACME extension to enable the issuance of short-
> >term and automatically renewed certificates.  This allows a domain
> >name owner to delegate the use of certificates to another party,
> >while retaining the capability to cancel this delegation at any time
> >with no need to rely on certificate revocation mechanisms.
>
> I found the introduction overly specific.  The generic use case is to
> simplify the deployment of certificates to unprivileged nodes.  The
> unprivileged nodes then only need to be configured with a URL for
> their certificates.
>
> That requires a couple of paragraphs of exposition at most.  This
> extends to Section 2, which describes a system architecture that
> implies the existence of protocol elements that are simply not defined
> in this document.
>
> Sections 1 and 2 could much more clearly describe what *this* document
> provides.  It provides an extension to ACME that allows for the
> creation of a certificate that automatically renews.
>
> The focus on the CDN case affects the entire document.  The point is
> that the authorized entity is delegating the ability to use a
> certificate for its name to an unprivileged node.  Don't use "CDN",
> "content owner" or any of these highly specific terms.  Use generic
> terms; make new terms if necessary.  FWIW, while NDC is a cute
> reversal, "consumer" really isn't accurate.
>
> draft-iab-web-pki-problems has been abandoned.  It's not a great idea
> to cite it.
>
> In Section 3.1.1, I think that the resolution of these fields, being
> in days, is not conducive to reducing granularity.  (Or will you
> permit 5.7e-3 as a value?)
>
> Section 3.1.1 needs to clearly articulate how
> "recurrent-certificate-validity" (could this be any more verbose and
> hard to type?) relates to "expires".
>
> Please include a definition for the new attributes, rather than just
> providing an example and commenting the JSON.
>
> In Section 3.1.2, you REALLY, REALLY need to authenticate this
> request.  My suggestion is to change this to a POST request with {
> "recurrent": false }.  (I'd have suggested PUT or PATCH, but ACME's
> reliance on JWS perverts that in ways that is incompatible with those
> methods.)
>
> In Section 3.2, the discussion about a Proxy is misleading.  The only
> relevant actor in this is an ACME client.  This section could be
> reduced to:
>
> An ACME client discovers whether a server supports this extension by
> examining a newly created order.  The "recurrent" member will exist if
> the server supports automatic recurring certificate issuance; the
> "recurrent" member will be true if the server accepts the request.
>
> Can the server specify a shorter value for "recurrent-total-lifetime"?
>
> I don't understand Section 3.3 at all.  I'd recommend removing this
> section.  The DNO will decide what authorizations it requests amply
> without this level of proscription in standards.
>
> In Section 3.4, the use of the Expires header field is a common
> mistake.  This is an HTTP caching directive.  It should probably be
> shorter than the expiration time of the certificate (half in fact),
> but not for the reasons that you might think.  The purpose of a
> recommendation on Expires is to ensure that the certificate is not
> cached beyond the point where a newer certificate will be issued.  You
> should remove this text.
>
> Section 5.1 should be promoted to Section 5
>
> Don't mention time-sensitive policy actions by the CA/B Forum.
>
> Can't you simply ensure that the CDN can't modify the CAA record?
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt

[Martin Thomson]

A few brief comments on this draft.

On 16 June 2017 at 22:19,   wrote:
>This memo proposes an ACME extension to enable the issuance of short-
>term and automatically renewed certificates.  This allows a domain
>name owner to delegate the use of certificates to another party,
>while retaining the capability to cancel this delegation at any time
>with no need to rely on certificate revocation mechanisms.

I found the introduction overly specific.  The generic use case is to
simplify the deployment of certificates to unprivileged nodes.  The
unprivileged nodes then only need to be configured with a URL for
their certificates.

That requires a couple of paragraphs of exposition at most.  This
extends to Section 2, which describes a system architecture that
implies the existence of protocol elements that are simply not defined
in this document.

Sections 1 and 2 could much more clearly describe what *this* document
provides.  It provides an extension to ACME that allows for the
creation of a certificate that automatically renews.

The focus on the CDN case affects the entire document.  The point is
that the authorized entity is delegating the ability to use a
certificate for its name to an unprivileged node.  Don't use "CDN",
"content owner" or any of these highly specific terms.  Use generic
terms; make new terms if necessary.  FWIW, while NDC is a cute
reversal, "consumer" really isn't accurate.

draft-iab-web-pki-problems has been abandoned.  It's not a great idea
to cite it.

In Section 3.1.1, I think that the resolution of these fields, being
in days, is not conducive to reducing granularity.  (Or will you
permit 5.7e-3 as a value?)

Section 3.1.1 needs to clearly articulate how
"recurrent-certificate-validity" (could this be any more verbose and
hard to type?) relates to "expires".

Please include a definition for the new attributes, rather than just
providing an example and commenting the JSON.

In Section 3.1.2, you REALLY, REALLY need to authenticate this
request.  My suggestion is to change this to a POST request with {
"recurrent": false }.  (I'd have suggested PUT or PATCH, but ACME's
reliance on JWS perverts that in ways that is incompatible with those
methods.)

In Section 3.2, the discussion about a Proxy is misleading.  The only
relevant actor in this is an ACME client.  This section could be
reduced to:

An ACME client discovers whether a server supports this extension by
examining a newly created order.  The "recurrent" member will exist if
the server supports automatic recurring certificate issuance; the
"recurrent" member will be true if the server accepts the request.

Can the server specify a shorter value for "recurrent-total-lifetime"?

I don't understand Section 3.3 at all.  I'd recommend removing this
section.  The DNO will decide what authorizations it requests amply
without this level of proscription in standards.

In Section 3.4, the use of the Expires header field is a common
mistake.  This is an HTTP caching directive.  It should probably be
shorter than the expiration time of the certificate (half in fact),
but not for the reasons that you might think.  The purpose of a
recommendation on Expires is to ensure that the certificate is not
cached beyond the point where a newer certificate will be issued.  You
should remove this text.

Section 5.1 should be promoted to Section 5

Don't mention time-sensitive policy actions by the CA/B Forum.

Can't you simply ensure that the CDN can't modify the CAA record?

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

[Acme] I-D Action: draft-ietf-acme-star-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
of the IETF.

Title   : Use of Short-Term, Automatically-Renewed (STAR) 
Certificates to Delegate Authority over Web Sites
Authors : Yaron Sheffer
  Diego Lopez
  Oscar Gonzalez de Dios
  Antonio Agustin Pastor Perales
  Thomas Fossati
Filename: draft-ietf-acme-star-00.txt
Pages   : 13
Date: 2017-06-16

Abstract:
   This memo proposes an ACME extension to enable the issuance of short-
   term and automatically renewed certificates.  This allows a domain
   name owner to delegate the use of certificates to another party,
   while retaining the capability to cancel this delegation at any time
   with no need to rely on certificate revocation mechanisms.

   [RFC Editor: please remove before publication]

   While the draft is being developed, the editor's version can be found
   at https://github.com/yaronf/I-D/tree/master/STAR.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-star/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-star-00
https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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