Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
RFC 8739
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Roman Danyliw Yes
Alvaro Retana No Objection
Warren Kumari No Objection
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
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
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
Thank you for addressing my DISCUSS and comment.
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
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
(Magnus Westerlund; former steering group member) No Objection