Hi! I conducted as second AD review of draft-ietf-acme-star per the AD hand-off. I have the following feedback:
** (From the first AD review) Per the issue of PS vs. Experimental status - I reviewed Section 5, Shepherd Write-up and the ML thread of the previous AD review (https://mailarchive.ietf.org/arch/msg/acme/ZWRzPxrWBrp_xjEn98A4HOBxkc4). From that I see there was one prototype implementation (from MAMI, thanks!) and a hackathon. To following up, who has indicated interest in implementing this draft? ** Section 2.1. Per "The bootstrap phase ends when the Id0 obtains a confirmation from the ACME CA that includes a star-certificate endpoint", what's a "star certificate endpoint" and how is that different than an "order URL for the issued STAR certificate" (per the previous paragraph)? ** Section 2.2. Per "The CA issues the initial certificate, typically when the authorization is done", what is the circumstance where the certificate is issued before the authorization? ** Section 3.1.2. Per "The server MUST NOT issue any additional certificates for this order beyond the certificate that is available for collection at the time of deletion": -- what is "time of deletion"? Is that the same as the time order cancelation? -- What does "beyond the certificate that is available for collection" mean if the text below this sentence says that accessing the star-certificate URL should return a 403 error? ** Section 3.3. The example shows a Link HTTP header but does not explain how it should be populated. ** Section 7. I didn't see any language in the Security Consideration about the impact/exposure of shifting to a model where certificate revocation doesn't occur. In Section 1, [Topalovic] hints at potentially cover this topic, but the site used in the reference section didn't resolve for me. It needs some treatment in the Security Considerations ** Section 7.2. The guidance in Section 7.2 seems appropriate for the identified privacy issue. However, it also seems to apply to the more basic security issue of guessing the URL too. -- Is there a reason why this isn't mentioned as a security issue too? -- Why is the recommendation for a server to choose URLs in a non-guessable only a SHOULD and not a MUST? Under what circumstances would it be advisable for the URLs to be guessable? Editorial Feedback: ** Section 1.0 Per the sentence "The Id0 can terminate the automatic renewal before the natural deadline", what's a "natural deadline"? Isn't it a "negotiated deadline" or "negotiated renewal window"? ** Section 1.1 It seems odd to call out name delegation as the only formal use case. ** Section 2.2. Per Figure 1, this isn't explicitly noted as an example so it strikes me as inappropriate to include "72-hours" as the auto-renew period is negotiated (as it is so specific and could be read as normative). Either call this an example or change "72 hours" to be something on the order of "short validity period". ** Section 2.3. Figure 2 is included in Section 2.3 but is not referenced in the text. ** Sections 3.1.1, 3.1.2. What is the role of the json blob after the first paragraph? It isn't referenced in the text and doesn't have a figure number. ** Section 3.1.1. Add a citation to "Section 7.1.3 of RFC8555" for notBefore and notAfter. ** Section 3.1.1. Add the citation "Section 7.1.6 of RFC8555" to the sentence, "ACME defines the following values ..." to make it clear what part of ACME you are updating/extending. ** Section 3.1.1. The first few paragraphs describing the new STAR items in the request as "attributes". However, the last paragraph starting with "A STAR certificate ..." refers to "certificate" and "star-certificate" as a "key". Be consistent. ** Section 3.2. Typo. /The directory/the directory/ ** Section 3.2. As the meta field is being extended, add a reference to Section 9.7.6 of RFC8555. ** Section 3.2. Use attribute or key to referrer to the additions to the "meta" field, not both. ** Section 3.2, 3.3. Per the example, I recommend making this an explicit figure with a number that you reference instead of introducing it with a long sentence that ends with a colon. ** Section 3.4. The recurrent-certificate-get is referred to as an attribute, but here it is called a key. I recommend making this consistent. ** Section 3.4. Does the sentence "If the server accepts the request, it MUST reflect the key in the Order" mean that if the server accepts the request to support unauthenticated GETs, it will keep the recurrent-certificate-get=true in the order response? If so, I'd recommend making this sentence a little clearer as without the assumed context of the section I didn't understand what it meant to "reflect a key". ** Section 3.5.1. Per the array after the text "The notBefore and notAfter ... paragraph", why is this a JSON styled array? _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
