Hi CNDI chairs and authors.

I am performing a SecDir early review as requested by the CDNI chairs.
I will focus this review on the question you asked about transporting private keys as-per Section 4. I'm happy to stay on as SecDir reviewer for this draft and give it a more thorough security review when you are ready (TLS certificates are kinda my thing).

I applaud you for submitting this for early security review. I agree with your feeling that that this feels dangerous; you're setting up a way to bulk-transfer TLS certificate private keys (specifically RFC 9345 delegated_credentials) between CDN providers over a weakly-protected channel. If this goes wrong, it's gonna go catastrophically wrong. Like, all it would take is for these CDNI Metadata objects to be logged in transit, an unscrupulous person to have access to those logs, and now they have TLS certs and private keys for potentially thousands of domains. I think this needs more thought.

I would suggest to explore the following two solution spaces:

1) 
Section 4 mentions: "If not specified, it is assumed that the dCDN generated the public-private key pair for the delegated credential itself and provided the public key information with an out-of-band mechanism to the uCDN."
It would be worth exploring this deeper and actually specifying how this should work. Effectively that would mean that the uCDN acts as a Certification Authority for the dCDN. The IETF has many certificate enrollment protocols to choose from. This would be the strongest option since the dCDN could generate the private keys in their key management solution and the private keys never need to traverse any software layers at all.

2)
Leave the private key transport as it is, but encrypt it using a base64 envelope format such as PKCS8/PEM or JOSE/JWE. This would require the uCDN and dCDN to have pre-established encryption keys as part of establishing their relationship -- likely the dCDN generates an asymmetric key pair and shares the public key to the uCDN.
This at least obscures the private keys from passive attacks such as traffic logging, but it still requires the private keys to exist decrypted in software memory at some stage, so is not as strong as option 1.

I'm happy to work with you off-list.