Skip to main content

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 ?