Linda: It appears that John and I were composing responses at the same time. I hope my reply resolves the remaining open items. Russ > On Oct 25, 2023, at 4:54 PM, Russ Housley <housley@xxxxxxxxxxxx> wrote: > > Linda: > > Thanks for your review. > >> Reviewer: Linda Dunbar >> Review result: Has Nits >> >> I have reviewed this document as part of the Ops area directorate's ongoing >> effort to review all IETF documents being processed by the IESG. These >> comments were written primarily for the benefit of the Ops area directors. >> Document editors and WG chairs should treat these comments just like any other >> last-call comments. >> >> Summary: this document defines conventions for the use of KEM algorithms by the >> originator and recipients to encrypt and decrypt Cryptographic Message Syntax >> content. >> >> I think the document is written clear. However, I have some confusion in >> reading through the document. >> >> 1. Section 1 says that KEM algorithm is a "Store-and-forward mechanism for >> transporting random keying material to a recipient". Does it mean the >> intermediate nodes simply forward the packets in the same way as any other IP >> packets? Are there any encryption algorithms that are not Store-and-Forward? > > It means that it works in store-and-forward environments, like email. The originator and the recipient do not need to be online at the same time. RFC 5990 uses this same language, > >> 2. Is the "shared secret(ss)" only between the originator and the recipient? if >> one node needs to send KEM algorithm to multiple recipients, does it mean that >> the originator needs to keep multiple shared secret? > > Yes, the originator needs to compute a shared secret for each recipient. That shared secret is used to derive a pairwise key-encryption key (KEK), The KEK encrypts the content-encryption key (CEK) for that recipient. The same CEK is encrypted for all recipients. In this way, only one copy of the enrypted content is sent, but each recipient is able to use a different KEK to obtain the CEK. > >> 3. Section 1.3: it states that the version number is intended to avoid ASN.1 >> decode errors. Is there any reference on how ASN numbers are used for avoiding >> ASN.1 decoding error? > > The version number tells the ASN.1 syntax used by the originator. That way, the recipient can use the save ASN.1 structure as the originator or throw an error because the version is unknown. See Section 1.3 of RFC 5652. > >> 4. Section 2 states that "The originator randomly generates the content >> encryption key and all recipients obtain that key". How does originator >> distribute the "encryption key to all recipients"? is the distribution >> encrypted? > > My reply to item 2 covers this. > >> 5. Section 5 last paragraph: What does "accept salt" mean? > > As the text says, this section uses the terminology from HKDF specification [RFC5869]. Salt is an optional HKDF input. > >> Nits: Section 1 first paragraph: "cryptographers have be specifying..." -> >> cryptographers have been specifying... > > Thanks. I will correct. > > You can see the changes based on this review here: https://github.com/lamps-wg/cms-kemri/pull/6 > > Russ > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
