| Linda:
I think that the part of the explanation that was not already there is added by the PR:
Russ On Oct 25, 2023, at 4:58 PM, Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> wrote:
Russ and John, Thank you very much for the detailed explanation. It would be great John can add his explanation to the document. Thank you, Linda -----Original Message----- From: Russ Housley <housley@xxxxxxxxxxxx> Sent: Wednesday, October 25, 2023 3:57 PM To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> Cc: ops-dir@xxxxxxxx; draft-ietf-lamps-cms-kemri.all@xxxxxxxx; Last Call <last-call@xxxxxxxx>; LAMPS <spasm@xxxxxxxx> Subject: Re: [lamps] Opsdir last call review of draft-ietf-lamps-cms-kemri-06 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://nam11.safelinks.protection.outlook.com/?url="">ub.com%2Flamps-wg%2Fcms-kemri%2Fpull%2F6&data="">0futurewei.com%7C7991cb6d9b894d9c2a8b08dbd59cf803%7C0fee8ff2a3b240189c
753a1d5591fedc%7C1%7C0%7C638338642401570470%7CUnknown%7CTWFpbGZsb3d8ey
JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GnpqfXlql%2FWBICZbCIXkz0glMUIUAIbkVz%2FeO0BLkeE%3D&reserved=0
Russ
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
