Hi Thomas! > -----Original Message----- > From: Thomas Fossati [mailto:[email protected]] > Sent: Monday, July 1, 2019 4:58 PM > To: Roman Danyliw <[email protected]>; [email protected] > Cc: Thomas Fossati <[email protected]> > Subject: Re: [Acme] Second AD Review: draft-ietf-acme-star > > Hi Roman, > > Thank you very much for the review. > > > 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_xjEn98A4HOBxk > c4). > > 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? > > Provided that as editors we have no say in the matter (we just do as told by > the working group), a few additional data points: > - The MAMI implementation is being integrated with the OSM orchestrator > [0] for NFV workloads; > - GSMA is considering ACME STAR as one of the reference solutions for > handling encrypted content in CDNI (see also [1]); > - In the past few months there's been discussion related to the use of > short-term certs for non-web use cases (see [2]), for example in the > ANIMA control plane [3]. > > [0] https://osm.etsi.org > [1] https://datatracker.ietf.org/doc/draft-ietf-cdni-interfaces-https- > delegation > [2] https://www.ietf.org/archive/id/draft-nir-saag-star-01.txt > [3] https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control- > plane
Given this information, I'm more comfortable with it being PS. All of the new text in -06 or clarifications below address my concerns. Thanks for the revisions and clarifications. I'll advance the draft. Roman > > ** 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)? > > You are right that the wording is not precise enough. > > We have modified Section 2.1., paragraph 3: > > OLD: > > [...]. Per normal ACME processing, the IdO is given back an > order URL for the issued STAR certificate to be used in subsequent > interaction with the CA (e.g., if the certificate needs to be > terminated.) > > NEW: > > [...]. Per normal ACME processing, the IdO is given back an > Order resource associated with the STAR certificate to be used in > subsequent interaction with the CA (e.g., if the certificate needs to > be terminated.) > > And Section 2.1., paragraph 4: > > OLD: > > The bootstrap phase ends when the IdO obtains a confirmation from the > ACME CA that includes a star-certificate endpoint. > > NEW: > > The bootstrap phase ends when the ACME CA updates the Order resource > to include the URL for the issued STAR certificate. > > > > ** 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? > > Not sure how "typically" ended up here. > > Section 2.2., paragraph 1: > OLD: > > The CA issues the initial certificate, typically when the > authorization is done. [...] > > NEW: > > The CA issues the initial certificate after the authorization > completes successfully. [...] > > > ** 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.1.2., paragraph 4: > OLD: > > The server MUST NOT issue any additional certificates for this order, > beyond the certificate that is available for collection at the time > of deletion. > > NEW: > > After a successful cancellation, the server MUST NOT issue any > additional certificates for this order. > > > ** Section 3.3. The example shows a Link HTTP header but does not > > explain how it should be populated. > > As per ACME spec (Section 7.1) the Link header points to the directory > resource: > > The "index" link relation is present on all resources other than the > directory and indicates the URL of the directory. > > > ** 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 > > Thanks for catching the broken ref, updated: > > [Topalovic] > Topalovic, E., Saeta, B., Huang, L., Jackson, C., and D. > Boneh, "Towards Short-Lived Certificates", 2012, > <http://www.ieee-security.org/TC/W2SP/2012/papers/ > w2sp12-final9.pdf>. > > > With regards to the Security Consideration, we have lifted the text from (the > currently expired) draft-nir-saag-star: > > 7.1. No revocation > > STAR certificates eliminate an important security feature of PKI > which is the ability to revoke certificates. Revocation allows the > administrator to limit the damage done by a rogue node or an > adversary who has control of the private key. With STAR certificates > expiration replaces revocation so there is a timeliness issue. To > that end, see also the discussion on clock skew in Section 4.1. > > It should be noted that revocation also has timeliness issues, > because both CRLs and OCSP responses have nextUpdate fields that tell > RPs how long they should trust this revocation data. These fields > are typically set to hours, days, or even weeks in the future. Any > revocation that happens before the time in nextUpdate goes unnoticed > by the RP. > > More discussion of the security of STAR certificates is available in > [Topalovic]. > > > ** 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? > > This is the same requirement level that we have in 8555 (Section 10.5); we > have added an explicit reference to avoid any future confusion. > > Section 7., paragraph 5: > OLD: > > In order to avoid correlation of certificates by account, if > unauthenticated GET is negotiated (Section 3.4) the server SHOULD > choose URLs of certificate resources in a non-guessable way, for > example using capability URLs [W3C.WD-capability-urls-20140218]. > > NEW: > > In order to avoid correlation of certificates by account, if > unauthenticated GET is negotiated (Section 3.4) the recommendation in > Section 10.5 of [RFC8555] regarding the choice of URL structure > applies, i.e. servers SHOULD choose URLs of certificate resources in > a non-guessable way, for example using capability URLs > [W3C.WD-capability-urls-20140218]. > > > Editorial Feedback: > > Please see https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-06 for the > details. > > > ** 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"? > > That's definitely better. Fixed. > > > ** Section 1.1 It seems odd to call out name delegation as the only > > formal use case. > > It's not the only formal use case, but one that is maybe non-obvious, so we > think it's worth calling it out. > > > ** 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". > > Fixed. > > > ** Section 2.3. Figure 2 is included in Section 2.3 but is not > > referenced in the text. > > Fixed. > > > ** 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. > > Removed -- in fact, the subsequent "attribute-name (optionality, type)" > makes it redundant. > > > ** Section 3.1.1. Add a citation to "Section 7.1.3 of RFC8555" for > > notBefore and notAfter. > > Fixed. > > > ** 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. > > Fixed. > > > ** 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. > > Fixed (s/key/attribute/g). > > > ** Section 3.2. Typo. /The directory/the directory/ > > Fixed. > > > ** Section 3.2. As the meta field is being extended, add a reference > > to Section 9.7.6 of RFC8555. > > Fixed. > > > ** Section 3.2. Use attribute or key to referrer to the additions to > > the "meta" field, not both. > > Fixed. > > > ** 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. > > Fixed. > > > ** 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. > > Fixed (see above). > > > ** 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". > > Yes, your guess is correct. The term "reflect" is used in various places in > the > base ACME spec to the same purpose. Please, check if the following is > clearer: > > OLD: > > If the server accepts the request, it MUST reflect the key in the > Order. > > NEW: > > If the server accepts the request, it MUST reflect the attribute > setting in the resulting Order object. > > > ** Section 3.5.1. Per the array after the text "The notBefore and > > notAfter ... paragraph", why is this a JSON styled array? > > No specific reason; it seemed to me like a convenient way to compactly > express both intervals' ordering and extent... It turns out Yaron also didn't > like it and took your hint to reformat the content into a table. > > Cheers & thanks again for the great feedback! > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
