On Tue, Aug 27, 2019 at 2:28 AM Yaron Sheffer <[email protected]> wrote:
> The new version contains some significant changes: > > - Addition of the STIR use case. > - Refinement of the CDNI use case. > - Addition of the CSR template (partial, more work required). > - Further security considerations (work in progress). > > Thanks, > Yaron > I was a bit surprised to not see any references to the Delegated Credentials for TLS ( https://tools.ietf.org/html/draft-ietf-tls-subcerts ) specification. Is my understanding correct that these are functionally addressing the same problem? Introduction: The introduction introduces the concept of NDC, but then transitions to use the acronym CDN. Perhaps it would be useful to explicitly specify if you meant a Content Delivery Network (CDN) to be a Name Delegation Consumer (NDC), or if perhaps that was just a typo. Also in the introduction, it states "Understandably, most IdOs balk at sharing their long-term private keys", but this is difficult to quantify. It would imply that most sites do not use CDNs, when I suspect the reality is actually inverted - more sites use CDNs or hosting provider than those that don't. Perhaps this should be updated to say "some IdOs", or perhaps quantify as "IdOs may balk", both of which indicate possibilities without indicating magnitude. 4.1.2 Chained Delegation The use of the terms uCDN and dCDN are... a bit surprising. Could you indicate a bit what those letters are meant to specify? My worry is that the u will be seen as similar to the Greek letter mu - aka the prefix typically used to indicate micro. That said, I admit, I'm a bit confused about the protocol design attempting to accommodate this. The motivation appears to be because "IdO may not even know about dCDN", but then immediately following, it notes that such proxying as proposed by the protocol is "governed by policy and contracts between the parties". It seems that if the intent is to leave it to policy, such accommodation may not be necessary. Alternative, if the intent is to explicitly support this, it may be desirable to allow the IdO to express its policy to the uCDN as to expectations related to the dCDN, rather than relying upon an out-of-band mechanism. 6.1 Restricting CDNs to the Delegation Mechanism There are RFC 2119 MUSTs attached here, when it seems these functionally should be SHOULDs. That is, I think it's fair to highlight the consideration of concerns between the IdO and the CDN, but I don't think it's reasonable to normatively specify the policy consideration mechanism. For example, as specified, those requirements would not be sufficient to guarantee that a conforming CA uses this mechanism, as a number of CAs "comply with ACME" (second bullet), but also offer additional validation methods/issuance flows which also use the "dns-01" method. As CAA is intentionally flexible to allow for CA-specific policy identifiers to be expressed between the IdO and the CA, I think it's best to change these to SHOULD, and to recognize that CAs may devise other means of technically expressing this conformance, and that's between the IdO and the CA. CAA provides the necessary component (to allow them to restrict to CAs that respect CAA, to allow CA-specific policy), but I think that's the extent to which policy-specific requirements can be made.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
