Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
RFC 8739

Note: This ballot was opened for revision 09 and is now closed.

Roman Danyliw Yes

(Adam Roach) (was Discuss) Yes

Comment (2019-10-01 for -09)
Thanks for the work that everyone put into this document! I have
a small number of very minor editorial nits. 

[Sorry for the earlier DISCUSS; I had mixed up the cert issuance
model in my head again].

§3.3:

>  The Server SHOULD include the "Cert-Not-Before" and "Cert-Not-After"
>  HTTP headers in the response.

Nit: "...HTTP header fields..."

>  Following are further clarifications regarding usage of these
>  headers, as per [RFC7231] Sec. 8.3.1.  All apply to both headers.

Nit: "...header fields..."

>
>  o  This header is a single value, not a list.

Nit: "...header field..."

>  o  The header is used only in responses to GET, HEAD and POST-as-GET

Nit: "...header field..."

>     requests, and only for MIME types that denote public key
>     certificates.
>  o  Header semantics are independent of context.

Nit: "Header field..."

>  o  The header is not hop-by-hop.

Nit: "...header field..."

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>     that if present, the header value equals the corresponding value

Nit: "...header field..."

>     within the credential.
>  o  The header is not appropriate for a Vary field.

Nit: "...header field..."

>  o  The header is allowed within message trailers.

Nit: "...header field..."

>  o  The header is not appropriate within redirects.

Nit: "...header field..."

>  o  The header does not introduce additional security considerations.

Nit: "...header field..."

>     It discloses in a simpler form information that is already
>     available inside the credential.

---------------------------------------------------------------------------

§3.3:

>  o  Intermediaries MAY insert or delete the value, but MUST ensure
>     that if present, the header value equals the corresponding value
>     within the credential.

This probably isn't what you want to say. Read literally, this imposes
a requirements on intermediaries who are neither removing nor adding
these header fields to validate that they match the value in the certs.
That's clearly an unrealistic expectation. I suspect the intention here
is that any entity who inserts a value must ensure that the newly inserted
value matches the corresponding value in the certificate.

Deborah Brungard No Objection

Alissa Cooper No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-10-18 for -10)
Thank you for addressing my Discuss point!

I will note that https://example.com/acme/cert/mAt3xBGaobw is used
here as a star-certificate URL but was used in RFC 8555 as a certificate
URL; it's probably worth putting a different random string in this document.

Warren Kumari No Objection

Comment (2019-10-01 for -09)
This is a fascinating approach / solution - thanks for writing this document, it's nice and clear.

Please review and address the comments in https://datatracker.ietf.org/doc/review-ietf-acme-star-06-opsdir-lc-ersue-2019-07-21/ -- they are useful (and thanks to Mehmet for the review)

Barry Leiba No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2019-10-21 for -10)
Thank you for addressing my DISCUSS and comment.

Alvaro Retana No Objection

Éric Vyncke No Objection

Comment (2019-10-03 for -09)
Thank you for the work put into this document. While I am balloting "no objection", I support Alexey's DISCUSS.

I am also wondering what is the impact of the increased rate of request to the ACME server. While sections 4 and 5 answered most of the questions popping up in my mind when reading the document; I am still concerned that going from a 90 days to a 3 days validity is probably multiplying the load by 30 on ACME server, are the free existing ACME server ready to continue their free services?

Regards,

-éric

Magnus Westerlund No Objection