CDNI Metadata for Delegated Credentials
draft-ietf-cdni-https-delegation-subcerts-12
Yes
Francesca Palombini
No Objection
Erik Kline
Jim Guichard
Mahesh Jethanandani
Note: This ballot was opened for revision 08 and is now closed.
Francesca Palombini
Yes
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Comment
(2024-07-22 for -09)
Sent
Gunter Van de Velde, RTG AD, comments for draft-ietf-cdni-https-delegation-subcerts-09 Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots. Please find for your convenience a few non-blocking review comments about this draft handling some textual enhancements. #DETAILED COMMENTS #================= ##classified as [minor] and [major] 74 Content delivery over HTTPS using one or more CDNs along the path 75 requires credential management. This specifically applies when an 76 entity delegates to another trusted entity delivery of content via 77 HTTPS. 79 This document defines the CDNI Metadata interface to setup HTTPS 80 delegation using delegated credentials (as defined by [RFC9345]) 81 between an upstream CDN (uCDN) and downstream CDN (dCDN). [minor] From a readability perspective, what about the following alternate textblob? " Content delivery over HTTPS utilizing one or more Content Delivery Networks (CDNs) along the delivery path necessitates the management of credentials. This requirement is particularly pertinent when an entity delegates the delivery of content via HTTPS to another trusted entity. This document specifies the CDNI Metadata interface for establishing HTTPS delegation through the use of delegated credentials, as defined in [RFC9345], between an upstream CDN (uCDN) and a downstream CDN (dCDN). " 101 in [RFC8008]. The FCI.Metadata object allows a dCDN to advertise its 102 capabilities and the Metadata interface (MI) objects supported by the 103 dCDN. Accordingly, to announce the support for delegated 104 credentials, the dCDN should announce the support of 105 MI.DelegatedCredentials as shown in the example below. [minor] From a readability perspective, what about the following alternate textblob: " The FCI.Metadata object enables a dCDN to communicate its capabilities and the Metadata Interface (MI) objects it supports. To indicate support for delegated credentials, the dCDN should announce the support for MI.DelegatedCredentials, as illustrated in the example below. " 124 This document also defines an object that announces to the delegating 125 entity how many delegated credentials the downstream supports such 126 that the delegating entity can provide the corresponding number of 127 delegated credentials. For that purpose we introduce the FCI object 128 FCI.DelegationCredentials. [minor] From a readability perspective, what about the following alternate textblob: " This document also defines an object that informs the delegating entity of the number of delegated credentials supported by the downstream entity, enabling the delegating entity to supply the appropriate number of delegated credentials. To this end, the FCI object, FCI.DelegationCredentials, is introduced. " Kind Regards, G/
Jim Guichard
No Objection
Mahesh Jethanandani
No Objection
Murray Kucherawy
(was Discuss)
No Objection
Comment
(2024-08-17 for -10)
Sent
Thanks for fixing up my DISCUSS regarding Section 6. The only part of my earlier comment remaining is this one: The NOT RECOMMENDED in Section 4 is a reference to the one in Section 7. I suggest using different language for the first one, e.g., "See Section 7 for constraints regarding ..." I understand that the SECDIR review suggested this be included, but I think it's safer to have the actual normative statement in only one place and just refer to it from elsewhere rather than restating it.
Orie Steele
No Objection
Comment
(2024-08-04 for -09)
Sent
# Orie Steele, ART AD, comments for draft-ietf-cdni-https-delegation-subcerts-09 CC @OR13 https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-cdni-https-delegation-subcerts-09.txt&submitcheck=True ## Comments ### key formats? ``` 153 Description: Base64-encoded (as defined in Section 4 of 154 [RFC4648]) public key of the dCDN to be used by the uCDN to 155 encrypt private keys. ``` Base64 encoding implies a binary public key format. Are there any details which should be added regarding the public keys? EC Point compression? CBOR / COSE Key / JWK ? Is there a risk of interoperability issues based on "double encoding" ? ``` 267 If the private-key property is used, the transported private key MUST 268 be encrypted using the PrivateKeyEncryptionKey specified in 269 FCI.DelegatedCredentials. The base64 envelope format for this 270 property MUST use JWE [RFC7516], whereas the private key is included 271 as JWE Ciphertext in the JWE. ``` Same question here for private key formats. You might consider adding some references to media types for MUST support and MAY support key formats. Especially given the requirement to use JWE for encryption, because there exists the `content type` parameter.
Paul Wouters
(was Discuss)
No Objection
Comment
(2024-08-16 for -10)
Sent
Thanks for addressing my concern. I have updated my ballot to "No Objection"
Roman Danyliw
No Objection
Comment
(2024-07-31 for -09)
Sent
Thank you to Mallory Knodel for the GENART review. ** Section 3.1. FCI.DelegatedCredentials. Per the PrivateKeyEncryptionKey that is Base64-encoded, how does one know what type if public key it is (e.g., RSA? ECC?) ** Section 6.1 and 6.2. What role does this text play in any IANA registry action? Could the role of this text be clarified?
Zaheduzzaman Sarker
No Objection
Comment
(2024-08-08 for -09)
Not sent
Thanks for working on this specification. I will support Murray's discuss.
Éric Vyncke
No Objection
Comment
(2024-07-09 for -09)
Sent
Thanks for the work done in this document. I have only one non-blocking COMMENT ## Section 3.2 The 2nd paragraph has a mix of `may` and BCP14 `MAY`. Is it on purpose ?