Re: [CDNi] Review of draft-ietf-cdni-delegation-acme-00

["Kevin J. Ma" <[e-mail]>]

Hi Frederic,

  Looking good.  A couple other minor comments:
  - in the time-window description, should the "must"s be capital "MUST"s?  if not, can we rephrase?
  - in section 4.1, make the reference to section 3.1 instead of 3
  - in the security considerations, i still think it would be useful to add a sentence about what an attacker could do if they got the acme-delegation URL.  could they generate certs and masquerade as the site, or is it innocuous?  

thanx!

--  Kevin J. Ma

Sent from my iPhone

> On Feb 10, 2023, at 1:56 PM, [e-mail] wrote:
> 
> 
> Hi Thomas,
> 
> 
> 
> Thank you for your review and comments.
> 
> I made the following changes on the Github https://github.com/FredericFi/cdni-wg/blob/main/draft-ietf-cdni-delegation-acme.md
> 
> If no further remarks, I will post the draft in the next days.
> 
> 
> 
> Thanks!
> 
> Frederic
> 
> 
> 
>  
> > I just realised I had another comment that got lost in the translation
> > between my notes and the email... which is: the lifetime-adjust property
> > should be optional rather than mandatory, to mirror the STAR definitions
> > in Section 3.1.1 [1].
> 
> Done
>   
> > ## abstract
> > 
> > * why plural "metadata objects"?  Suggestion:
> > 
> > OLD
> > 
> > Specifically, this document defines CDNI Metadata interface objects to
> > enable delegation of X.509 certificates leveraging delegation schemes
> > defined in RFC9115.
> > 
> > NEW
> > 
> > Specifically, this document defines a CDNI Metadata interface object
> > to enable delegation of X.509 certificates leveraging delegation
> > schemes defined in RFC9115.
> > 
> > 
> 
> Done
> 
> > * expand FCI on first use:
> > 
> >  Section 2 presents delegation metadata for the FCI interface.
> 
> Done
> 
> 
> > * typo (extra “to”)
> > 
> >   When a uCDN delegates to a dCDN to deliver HTTPS traffic using DNS
> >   Redirection [RFC7975],
> > 
> >   When a uCDN delegates a dCDN to delivery of HTTPS traffic using DNS
> >   Redirection [RFC7975],
> > 
> > 
> 
> Done
> 
> > * typo (missing parentheses):
> > 
> > OLD
> > 
> >    The ACMEDelegationMethod applies to both ACME STAR delegation,
> >    which provides a delegation model based on short-term certificates
> >    with automatic renewal Section 2.3.2 of [RFC9115], and non-STAR
> >    delegation, which allows delegation between CDNs using long-term
> >    certificates Section 2.3.3 of [RFC9115].
> > 
> > NEW
> > 
> >    The ACMEDelegationMethod applies to both ACME STAR delegation,
> >    which provides a delegation model based on short-term certificates
> >    with automatic renewal (Section 2.3.2 of [RFC9115]), and non-STAR
> >    delegation, which allows delegation between CDNs using long-term
> >    certificates (Section 2.3.3 of [RFC9115]).
> > 
> 
> Done
> 
> > ## §3.1
> > 
> > * this seems to suggest that the consumer can tell STAR and non-STAR
> >   based on "delegation certificate validity", but it's not clear to me
> >   what that means.
> > 
> >    The ACMEDelegationMethod object allows a uCDN to both define STAR
> >    and non-STAR delegation depending on the delegation certificate
> >    validity.
> > 
> >   From the following examples (§3.1.1) I gather there's an implicit
> >   way to distinguish based on the presence/absence of the lifetime*
> >   properties.  Is that what was intended?  If so, it should be
> >   clarified.
>  
> Done
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni