Re: [lamps] WG Last Call for draft-housley-lamps-cms-kemri

> Please review the document and send your comments to the list by 14
> July 2023.

After having a look at core pieces of this draft earlier, this time I
went through it in detail
(except for section 6, which is on the ASN.1 module). Also Hendrik had a
look again.
We make use of this draft for adding KEM support to CMP in rfc4210bis.

This is consolidated feedback from both of us.
For most part, we find the text well written and clear.
We see room for improvement mostly regarding the description of details
on KDF use.

While it is clear that the 'ukm' field in the CMSORIforKEMOtherInfo is
optional,
it does not become clear to us from the text whether the KDF 'info'
parameter (of type CMSORIforKEMOtherInfo) is meant to be mandatory or
optional. We believe that it should be in general optional because there
are KDF algorithms that do not have such an extra parameter. (Of course,
in case the KDF chosen requires such a parameter, it must be provided.)

A related issue is some ambiguity within the last paragraph of Section
5.
It did not become clear to us how to provide the 'salt' parameter
supported/required by many KDF algorithms. 
Is it meant to be the same as the 'info' parameter (which in turn
contains the optional 'ukm' field, which may contain salt-like random
values)?
Or is it meant to be provided as a separate (more implicit) parameter
within the AlgorithmIdentifier for the KDF chosen?
To me, it looks like that the explicitly listed KDF input 'info' is
essentially the optional KDF 'salt' parameter,
while any "other inputs" to the KDF are considered implicit parameters
to be provided as part of the 'kdf' field (of type
KeyDerivationAlgorithmIdentifier) within the KEMRecipientInfo structure.

Below is a list of nits.

 David and Hendrik

Section 2:

each recipient recipient -> 
each recipient

A word seems missing or superfluous in:
"Thus, the content-encryption key is used to protect the in CMS
content."

Two occurrences of:
other data that is send in the clear -> 
other data that is sent in the clear

Section 7:

is used to with ->
is used with

On Tue, 2023-06-27 at 20:25 +0000, Tim Hollebeek wrote:
> Oops, of course I mean the LAMPS draft, not the Housley draft.
>  
> “Using Key Encapsulation Mechanism (KEM) Algorithms in the
> Cryptographic Message Syntax (CMS)” <draft-ietf-lamps-cms-kemri-01>
>  
> https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kemri/
>  
> -Tim
>  
> From: Spasm <spasm-bounces@ietf.org>On Behalf Of Tim Hollebeek
> Sent: Tuesday, June 27, 2023 12:04 PM
> To: SPASM <spasm@ietf.org>
> Subject: [lamps] WG Last Call for draft-housley-lamps-cms-kemri
>  
>  
> It appears that the discussion of the CMS kemri has settled down, and
> the active participants have implementations that seem to work
> together successfully.
>  
> Russ has asked for us to proceed to WG Last Call, and I agree it is
> ready for that discussion.  So this is the LAMPS WG Last Call for
> “Using Key Encapsulation Mechanism (KEM) Algorithms in the
> Cryptographic Message Syntax (CMS)” <draft-housley-lamps-cms-kemri-
> 02>.  Please review the document and send your comments to the list by
> 14 July 2023.
>  
> The datatracker page for the document is
> https://datatracker.ietf.org/doc/draft-housley-lamps-cms-kemri/
>  
> Thanks,
>  
> -Tim
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm