Subject: [Acme] I-D Action: draft-ietf-acme-acme-13.txt

From: [email-masked]
Date: Tue, 17 Jul 2018 15:13:27 -0700

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 WG of the IETF.

        Title           : Automatic Certificate Management Environment (ACME)
        Authors         : Richard Barnes
                          Jacob Hoffman-Andrews
                          Daniel McCarney
                          James Kasten
	Filename        : draft-ietf-acme-acme-13.txt
	Pages           : 86
	Date            : 2018-07-17

Abstract:
   Certificates in PKI using X.509 (PKIX) are used for a number of
   purposes, the most significant of which is the authentication of
   domain names.  Thus, certificate authorities in the Web PKI are
   trusted to verify that an applicant for a certificate legitimately
   represents the domain name(s) in the certificate.  Today, this
   verification is done through a collection of ad hoc mechanisms.  This
   document describes a protocol that a certification authority (CA) and
   an applicant can use to automate the process of verification and
   certificate issuance.  The protocol also provides facilities for
   other certificate management functions, such as certificate
   revocation.

   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
   this draft is maintained in GitHub.  Suggested changes should be
   submitted as pull requests at https://github.com/ietf-wg-acme/acme
   [1].  Instructions are on that page as well.  Editorial changes can
   be managed in GitHub, but any substantive change should be discussed
   on the ACME mailing list ([email-masked]).

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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-13

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/

---

From: Corey Bonnell <[email-masked]>
Date: Wed, 18 Jul 2018 13:01:22 +0000

Hello,
In section 7.4.2 (https://tools.ietf.org/html/draft-ietf-acme-acme-13#section-7.4.2), it is stated several times that certificate resources are immutable. Given that this isn't the case with an ACME server that supports the STAR extension, it might be good to remove the language around resource immutability to avoid potential confusion. In addition, the verbiage concerning the setting of cache control headers for the certificate resource may also cause confusion in the context of an ACME STAR server. 

On the other hand, since the language in 7.4.2 appears to be correct for the base ACME specification (ignoring STAR), I could see why the existing language should remain.

Thanks,
Corey Bonnell
Senior Software Engineer

Trustwave | SMART SECURITY ON DEMAND
https://www.trustwave.com

On 7/17/18, 6:14 PM, "Acme on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

    
    Abstract:
    
       submitted as pull requests at https://scanmail.trustwave.com/?c=4062&d=w-rO20a3QMhWrSVuXInhjs8zAw1bWrG0tELzhbEIcA&s=5&u=https%3a%2f%2fgithub%2ecom%2fietf-wg-acme%2facme

    The IETF datatracker status page for this draft is:
    https://scanmail.trustwave.com/?c=4062&d=w-rO20a3QMhWrSVuXInhjs8zAw1bWrG0tBX3heYJIQ&s=5&u=https%3a%2f%2fdatatracker%2eietf%2eorg%2fdoc%2fdraft-ietf-acme-acme%2f
    
    There are also htmlized versions available at:
    https://scanmail.trustwave.com/?c=4062&d=w-rO20a3QMhWrSVuXInhjs8zAw1bWrG0tEKghb9eKA&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2fdraft-ietf-acme-acme-13
    https://scanmail.trustwave.com/?c=4062&d=w-rO20a3QMhWrSVuXInhjs8zAw1bWrG0tBXw1L9adQ&s=5&u=https%3a%2f%2fdatatracker%2eietf%2eorg%2fdoc%2fhtml%2fdraft-ietf-acme-acme-13
    
    A diff from the previous version is available at:
    https://scanmail.trustwave.com/?c=4062&d=w-rO20a3QMhWrSVuXInhjs8zAw1bWrG0tBGk1rYOcg&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2frfcdiff%3furl2%3ddraft-ietf-acme-acme-13

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at http://scanmail.trustwave.com/?c=4062&d=w-rO20a3QMhWrSVuXInhjs8zAw1bWrG0tBWnhuZcKQ&s=5&u=http%3a%2f%2ftools%2eietf%2eorg

    _______________________________________________
    Acme mailing list
    [email-masked]
    https://scanmail.trustwave.com/?c=4062&d=w-rO20a3QMhWrSVuXInhjs8zAw1bWrG0tBOl1b9TIg&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 18 Jul 2018 09:22:05 -0400

> On the other hand, since the language in 7.4.2 appears to be correct for
> the base ACME specification (ignoring STAR), I could see why the existing
> language should remain.

This would be my preference. I don't think the base specification should
change this close to last call for this case.

On Wed, Jul 18, 2018 at 9:01 AM, Corey Bonnell <[email-masked]>
wrote:

> Hello,
> In section 7.4.2 (https://tools.ietf.org/html/draft-ietf-acme-acme-13#
> section-7.4.2), it is stated several times that certificate resources are
> immutable. Given that this isn't the case with an ACME server that supports
> the STAR extension, it might be good to remove the language around resource
> immutability to avoid potential confusion. In addition, the verbiage
> concerning the setting of cache control headers for the certificate
> resource may also cause confusion in the context of an ACME STAR server.
>
> On the other hand, since the language in 7.4.2 appears to be correct for
> the base ACME specification (ignoring STAR), I could see why the existing
> language should remain.
>
> Thanks,
> Corey Bonnell
> Senior Software Engineer
>
> On 7/17/18, 6:14 PM, "Acme on behalf of [email-masked]" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>        submitted as pull requests at https://scanmail.trustwave.
> com/?c=4062&d=w-rO20a3QMhWrSVuXInhjs8zAw1bWrG0
> tELzhbEIcA&s=5&u=https%3a%2f%2fgithub%2ecom%2fietf-wg-acme%2facme
>     https://scanmail.trustwave.com/?c=4062&d=w-
> rO20a3QMhWrSVuXInhjs8zAw1bWrG0tBX3heYJIQ&s=5&u=https%3a%2f%
> 2fdatatracker%2eietf%2eorg%2fdoc%2fdraft-ietf-acme-acme%2f
>
>     https://scanmail.trustwave.com/?c=4062&d=w-
> rO20a3QMhWrSVuXInhjs8zAw1bWrG0tEKghb9eKA&s=5&u=https%3a%2f%
> 2ftools%2eietf%2eorg%2fhtml%2fdraft-ietf-acme-acme-13
>     https://scanmail.trustwave.com/?c=4062&d=w-
> rO20a3QMhWrSVuXInhjs8zAw1bWrG0tBXw1L9adQ&s=5&u=https%3a%2f%
> 2fdatatracker%2eietf%2eorg%2fdoc%2fhtml%2fdraft-ietf-acme-acme-13
>
>     https://scanmail.trustwave.com/?c=4062&d=w-
> rO20a3QMhWrSVuXInhjs8zAw1bWrG0tBGk1rYOcg&s=5&u=https%3a%2f%
> 2fwww%2eietf%2eorg%2frfcdiff%3furl2%3ddraft-ietf-acme-acme-13
>
>
>     until the htmlized version and diff are available at
> http://scanmail.trustwave.com/?c=4062&d=w-rO20a3QMhWrSVuXInhjs8zAw1bWrG0
> tBWnhuZcKQ&s=5&u=http%3a%2f%2ftools%2eietf%2eorg
>
>     https://scanmail.trustwave.com/?c=4062&d=w-
> rO20a3QMhWrSVuXInhjs8zAw1bWrG0tBOl1b9TIg&s=5&u=https%3a%2f%
> 2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme
>
>
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jul 2018 13:25:06 +0000

*   This would be my preference. I don't think the base specification should change this close to last call for this case.

I agree.  If we need to fix things after the STAR document becomes an RFC, we can publish an errata.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 18 Jul 2018 17:37:19 +0300

On Wed, Jul 18, 2018 at 01:25:06PM +0000, Salz, Rich wrote:
>   *   This would be my preference. I don't think the base
>       specification should change this close to last call
>       for this case.
> 
> I agree.  If we need to fix things after the STAR document
> becomes an RFC, we can publish an errata.

Or have the STAR document explicitly call that it controverts
this requirement. I think that is a good idea to explicitly
call conflicting requirements (and I have seen examples of
trouble when this has not been done because implementers
were just confused).

-Ilari

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Wed, 18 Jul 2018 14:58:05 +0000

> trouble when this has not been done because implementers

This looks like a good suggestion.

And I guess when we publish STAR we can add "Updates: RFC-ACME".