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] Rolling keys and pending validations

[Ilari Liusvaara]

On Mon, Jun 19, 2017 at 02:34:45PM -0400, Richard Barnes wrote:
> This seems sensible; rolling keys shouldn't invalidate things in transit
> any more than changing your Gmail password should delete your drafts folder.
> 
> I would have a little bit of a hard time calling this "purely editorial",
> since it specifies server behavior.  But it seems like you're just
> codifying an expectation that at least I already had (TBH, I would not have
> thought to build a server otherwise), so I would be inclined to go ahead
> and merge it if at least one or two other people chime in.
> 
> Here's a PR:  https://github.com/ietf-wg-acme/acme/pull/323

If there is pending validation over key change, which key hash should
the validation use when it is resolved? The old one? The new one?


-Ilari

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

Re: [Acme] Rolling keys and pending validations

[Richard Barnes]

This seems sensible; rolling keys shouldn't invalidate things in transit
any more than changing your Gmail password should delete your drafts folder.

I would have a little bit of a hard time calling this "purely editorial",
since it specifies server behavior.  But it seems like you're just
codifying an expectation that at least I already had (TBH, I would not have
thought to build a server otherwise), so I would be inclined to go ahead
and merge it if at least one or two other people chime in.

Here's a PR:  https://github.com/ietf-wg-acme/acme/pull/323

--Richard


On Mon, Jun 19, 2017 at 2:08 PM, Salz, Rich  wrote:

> Speaking purely as an individual.
>
>
>
> This is about Section 7.3.3
>
>
>
> It can be difficult to change the account credentials, because you have to
> make sure that nothing is “in transit.”  For a large client, or perhaps a
> reseller type of arrangement, this can be difficult if not impossible.
>
>
>
> I would like to see a sentence added to the end of the section that says
> “rolling keys does not invalidate any challenges currently in progress.”
>
>
>
> I leave this to the WG as to whether or not this is strictly editorial.
> Even if there is no consensus, an explicit statement about the validity
> should be added.  I think NOT invalidation is better, as the inverse makes
> changes hard.
>
> --
>
> 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
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Before entering WGLC ...

[Salz, Rich]

How about this:

A CA MAY proceed with issuance if a CAA record is present whose value matches 
the account-uri parameter of the account making the request.
If no CAA records have such a match, then the CA MUST NOT proceed with issuance.

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

Re: [Acme] Before entering WGLC ...

[Hugo Landau]

> Like Russ, I find the statement very difficult to read.  Would
> inverting it be better?
> 
> > A CA MUST NOT issue authorize issuance if a CAA record is present unless 
> > the "account-uri" parameter identifies the account making a certificate 
> > issuance request.
See previous reply. Issuance is not determined by the presence of "a"
CAA record; there may be multiple and issuance is authorized if any are
considered to match the request. Establishing that a specific CAA record
is not matched is not a sufficient condition for refusing issuance,
because another adjacent CAA record might authorise it. I think any
attempt to describe this criterion in terms of specific situational MUST
NOTs with regard to a single CAA record is futile.

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

[Acme] I-D Action: draft-ietf-acme-email-smime-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   : Extensions to Automatic Certificate Management 
Environment for end user S/MIME certificates
Author  : Alexey Melnikov
Filename: draft-ietf-acme-email-smime-00.txt
Pages   : 4
Date: 2017-06-19

Abstract:
   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificates for use for email recipients that want to use S/MIME.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-email-smime-00
https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-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

[Acme] I-D Action: draft-ietf-acme-email-tls-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   : Extensions to Automatic Certificate Management 
Environment for email TLS
Author  : Alexey Melnikov
Filename: draft-ietf-acme-email-tls-00.txt
Pages   : 7
Date: 2017-06-19

Abstract:
   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificates for use by TLS email services.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-email-tls-00
https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-tls-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