Hi Roman: You wrote: >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?
The Streaming Video Alliance (SVA) (1) is implementing CDNI RFCs to enable delegation between CDNs, specifically, a use case where a commercial CDN (uCDN) delegates to a CDN (dCDN) within an operator network or any other commercial CDN where the upstream CDN may not have presence. The SVA have also proposed extensions to existing CDNI RFCs (2). WRT delegation between CDNI, there is currently a draft (3) in CDNI that adds CDNI's Metadata Interface to support HTTPS delegation. The metadata is specifically created to support delegation methods such as STAR (4) and sub-certificates (5). In light of above usage it will be ideal if ACME STAR draft takes a standards track. This helps use of CDNI based implementations follow the "standards" track RFCs. Regards Sanjay 1. https://www.streamingvideoalliance.org/technical-work/working-groups/open-caching/ 2. https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/ 3. https://datatracker.ietf.org/doc/draft-ietf-cdni-interfaces-https-delegation/ 4. https://datatracker.ietf.org/doc/draft-ietf-acme-star/ 5. https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ -----Original Message----- From: Acme [mailto:[email protected]] On Behalf Of Roman Danyliw Sent: Friday, June 21, 2019 7:58 AM To: [email protected] Subject: [E] [Acme] Second AD Review: draft-ietf-acme-star 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://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_acme_ZWRzPxrWBrp-5FxjEn98A4HOBxkc4&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=Z8DN4CFMEnApJigfCFWHcUdLeXhUaOlwT4RhVbdl37E&s=5yYWrxOs70ZpHqY0Ag_-8HyeI3ihZkqmQIM90e_T_Pc&e= ). 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=Z8DN4CFMEnApJigfCFWHcUdLeXhUaOlwT4RhVbdl37E&s=XvyHQINuFMISJ3O8HjW9SC2jY9KVKgqAfn0OiLJW9CQ&e= -----Original Message----- From: Acme [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, July 3, 2019 8:13 AM To: [email protected] Subject: [E] Re: [Acme] Second AD Review: draft-ietf-acme-star Hi Roman, > 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://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_acme_ZWRzPxrWBrp-5FxjEn98A4HOBxkc4&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=yLAaMF-MGwjWB3Jp8WZmw8HRR93MAhg5RdwhPA5od70&s=0YR44tNW-n0As-n276FdL6fsPAJHssSl-AzoJ_OkJ78&e= > ). > 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? I do think telcos are very interested in having a standardized solution to create short-term certificates based on ACME. For instance, in CDNI, we are looking to enable the delegation of secured traffic between an uCDN and a dCDN. ACME-STAR enables it and complies with CDNI requirements for controlling revocation. Moreover, as far as OpenCaching is concerned, CDNs will need open and standard interfaces to enable delegation from other parties. I believe that ACME-STAR needs to be in STD track. Regards, Frederic _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Acme mailing list [email protected] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=yLAaMF-MGwjWB3Jp8WZmw8HRR93MAhg5RdwhPA5od70&s=azc-m_m3NVHw4eGaWJcI1OoAOawOtTn2TtsX6_Hjonc&e= _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
