Re: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-09.txt

[[e-mail]]

Hi Kevin,

>  wrt the comment on section 1, you are adding an entry to an existing registry; you are not proposing a new registry.  I still don't think that last sentence is correct.
Done

>  wrt section 3, I still don't think the section is necessary.  There's no need to explain how FCI works.  (Note: The example is also not correct, "delegation-methods" should be "metadata".)
I would think, on the contrary it's worth explaining how this interface should be used to advertise for the supported methods. Moreover, the second draft on subcerts delegation is also concerned by this. To me, we should keep it in the draft.
Corrected the "metadata".

>  wrt the example in section 4, I don't think you need the HostMatch example, and the ACMEStarDelegationMethod example is still missing the "generic-metadata-type" field, which is critical.
Done

>  wrt the security considerations, it would be helpful to explain what is critical about the contents of the ACMEStarDelegationMethod metadata, and why it should be protected.
I clarified a bit, but the objects referred in the metadata are related to the Acme-Star draft. The security question is mostly tackled in RFC9115 section 7.

Thank you,

Regards,
Frédéric



De : Kevin Ma <[e-mail]>
Envoyé : mardi 2 août 2022 07:41
À : FIEAU Frédéric INNOV/NET <[e-mail]>
Cc : [e-mail]
Objet : Re: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-09.txt

Hi Frederic,

  Thanks for the quick turnaround.

  wrt the comment on section 1, you are adding an entry to an existing registry; you are not proposing a new registry.  I still don't think that last sentence is correct.

  wrt section 3, I still don't think the section is necessary.  There's no need to explain how FCI works.  (Note: The example is also not correct, "delegation-methods" should be "metadata".)

  wrt the example in section 4, I don't think you need the HostMatch example, and the ACMEStarDelegationMethod example is still missing the "generic-metadata-type" field, which is critical.

  wrt the security considerations, it would be helpful to explain what is critical about the contents of the ACMEStarDelegationMethod metadata, and why it should be protected.

thanx.

--  Kevin J. Ma


On Mon, Aug 1, 2022 at 10:35 AM <[e-mail]<mailto:[e-mail]>> wrote:
Hi Kevin,

Just posted the last version taking into account your comments.

Section 1. and 3
We removed FCI.SupportedDelegationMethods,
There is still the MI.AcmeSTarDelegationMEthod object to register. So the IANA section is not empty.

Section 4.1
Removed the explanations of section 4.1 and moved the example at the bottom of section 4.

Section 6.
We added a recommendation  to protect the critical parts of the objects.

Nits taken into account.


Regards,
Frederic

De : Kevin Ma <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 29 juillet 2022 15:47
À : FIEAU Frédéric INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : [e-mail]<mailto:[e-mail]>
Objet : Re: [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-09.txt

Hi Frederic,

  Some comments on the updated draft below.

thanx!

--  Kevin J. Ma

section 1:
  remove "Furthermore, it includes a proposal of IANA registry to enable adding of delegation methods."  There is no longer a new registry?

section 3:
  I don't see any need for a new FCI object.  RFC8008 already has an FCI.Metadata object, and MI.AcmeStarDelegationMethod can just be advertised through that existing object?

section 4.1:
  This section seems to mostly just explain how the Metadata interface works?  I don't think it is necessary.  I would just remove this section.
  The final example of what a serialized MI.AcmeStarDelegationMethod generic metadata object looks like should be in a section 4.2.1 (including the generic-metadata-type) and referenced from IANA section 5.1

section 6:
  If the ACME delegation objects were divulged, what would be the impact?  Yes, they should be protected by the proper/mandated encryption and authentication on the Metadata interface, but I think it is best to document what is at stake (if anything)

nits:
- section 1:
  "holder of a X.509" -> "a holder of ane X.509"
  "on-demand a X.509" -> "on-demand an X.509" (multiple places)
  "use of certificate authority" -> "use of the certificate authority"
  "an upstream CDN (uCDN) and a downstream CDN (dCDN)" -> "a uCDN and a dCDN"
  "based on mechanism specified" -> "based on the mechanism specified"
- section 4.1:
  "CDNI Delegation metadata" -> "ACMEStarDelegationMethod metadata" ?
  "an HostMatch object" -> "a HostMatch object" (multiple places)
  "The existence of delegation method in the CDNI metadata Object" -> "The existence of ACMEStarDelegationMethod in the CDNI metadata"
  "set of Host" -> "set of Hosts"
- section 4.2:
  "(i.e. dCDN)" -> "(i.e., the dCDN)"
  "end-user client, a short-term" -> "end-user client a short-term"
- section 5.1:
  "see Section 5" -> "see Section 4.2.1"


On Sat, Jul 9, 2022 at 9:55 AM Kevin Ma <[e-mail]<mailto:[e-mail]>> wrote:
Hi Frederic,

  (As Chair) Thanks for the updated draft.  If we think this is pretty close to final, I will start my pre-shepherd review.  I encourage everyone to please take a look, as we would like to try and finish up this work by IETF 115.

  I fully support updating the name of the draft to deconflict it from the subcerts draft.

thanx!

--  Kevin J. Ma


On Fri, Jul 8, 2022 at 1:22 PM <[e-mail]<mailto:[e-mail]>> wrote:
Hi all

I've submitted the -09 version of draft-ietf-cdni-interfaces-https-delegation-09. Changes are mainly on the abstract and introduction.
Also I would suggest to change the title to : "CDNI metadata for HTTPS delegation using Short-Term Automatically Renewed Certificates".

Feel free to comment.

Thank you,
Regards,
Frederic



Orange Restricted

-----Message d'origine-----
De : CDNi <[e-mail]<mailto:[e-mail]>> De la part de [e-mail]<mailto:[e-mail]>
Envoyé : vendredi 8 juillet 2022 17:31
À : [e-mail]<mailto:[e-mail]>
Cc : [e-mail]<mailto:[e-mail]>
Objet : [CDNi] I-D Action: draft-ietf-cdni-interfaces-https-delegation-09.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Content Delivery Networks Interconnection WG of the IETF.

        Title           : CDNI extensions for HTTPS delegation
        Authors         : Frederic Fieau
                          Emile Stephan
                          Sanjay Mishra
  Filename        : draft-ietf-cdni-interfaces-https-delegation-09.txt
  Pages           : 9
  Date            : 2022-07-08

Abstract:
   This document defines a new Footprint and Capabilities metadata
   objects to support HTTPS delegation between two or more
   interconnected CDNs.  Specifically, this document outlines CDNI
   Metadata interface objects for delegation method as published in the
   ACME-STAR document [RFC9115].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-interfaces-https-delegation/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-cdni-interfaces-https-delegation-09.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-interfaces-https-delegation-09


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
CDNi mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cdni

_________________________________________________________________________________________________________________________

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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cdni


Orange Restricted


Orange Restricted

_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.