Skip to main content

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

Yes

Roman Danyliw

No Objection

Alvaro Retana
(Alissa Cooper)
(Barry Leiba)
(Deborah Brungard)
(Magnus Westerlund)

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

Roman Danyliw Yes

Alvaro Retana No Objection

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)

É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

(Adam Roach; former steering group member) (was Discuss) Yes

Yes (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.

(Alexey Melnikov; former steering group member) (was Discuss) No Objection

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

(Alissa Cooper; former steering group member) No Objection

No Objection (for -09)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -09)

                            

(Benjamin Kaduk; former steering group member) (was Discuss) No Objection

No Objection (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.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -09)

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection (for -09)