Re: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-delegation-01.txt

[Thomas Fossati <[e-mail]>]

Hi Ryan,

Thanks very much for the comments.  I'm going to address some of your
points and let Yaron comment on the rest.

On Tue, Aug 27, 2019 at 2:28 AM Yaron Sheffer <[e-mail]> wrote:
> 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?

Yes, it is.

> 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.

There is no typo.  A CDN is just one type of NDC.  We'll make sure
there's no ambiguity here.

> 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.

Makes sense, we'll fix.

> 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

This is the CDNI use case, so we reuse CDNI terminology: 'u' is for
"upstream", 'd' is "downstream".  In the CDNI model the upstream CDN is
a "normal" CDN that maybe lacks the geographical footprint to
efficiently cover a portion of its end-users population and makes
agreements (transparently to the content provider) with a "downstream"
(regional, network operator run) CDN to extend its delivery footprint.

> 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.

I think the policy that we can express is solely between adjacent
parties (this is the CDNI interface model).

> 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.

I think Yaron is better placed than me to comment on these two.

Cheers!

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.