Re: [lamps] AD Review of draft-ietf-lamps-cms-kemri-07

[Russ Housley <[e-mail]>]

Roman:

> Last October, I performed an AD review on -05 (https://mailarchive.ietf.org/arch/msg/spasm/DrkREuxsrIRWHRR4qj6yWxVufIQ/).  After IETF LC, new analysis of this document was reported (https://mailarchive.ietf.org/arch/msg/spasm/TTtMQlcpGRq_bThfJl-HnqqGLGI/) requiring WG deliberations.  After IETF 118, this document was sent back to the WG.  This document has gone through another WGLC and is back to the IESG with "publication requested."
> 
> Thank you to Falko Strenzke and Johannes Roth for reporting this attach against CMS and the WG's timely response.  This is a second AD review on -07.  Feedback is below.
> 
> ** Section 1
> 
>   In this environment, security depends on three things.  First, the
>   KEM algorithm must be secure against adaptive chosen ciphertext
>   attacks.  Second, the key-encryption algorithm must provide
>   confidentiality and integrity protection.  Third, the choices of the
>   KDF and the key-encryption algorithm need to provide the same level
>   of security as the KEM algorithm.
> 
> Should normative MUST be used to describe these three crucial properties of the environment?

I think this is saying where KEMRecipientInfo is appropriate to apply. Mostly, people that write RFCs that specify the conventions for a particular KEM will need to make sure they understand these requirements.  For example, rfc5990bis.  Likewise, the authors of the document that is written for ML-KEM will need to consider these too.

> ** Section 3.  Process question.
>     Note that this requirement expands the original purpose of the ukm
>     described in Section 10.2.6 of [RFC5652]; it is not limited to
>     being used with key agreement algorithms.
> 
>>> (per -05) Does this imply that this RFC should formally “update” RFC5652?
> 
>> Yes, I'll add that to the title page.
> 
> [Roman on -07] Thanks for adding this to the meta.  Can a sentence be added to the abstract to explicitly say that RFC5652 is being updated?

Yes, this should appear in the Abstract and the Introduction.

> ** Section 6.1.  
> 
>>> (per -05) Since SMIME-CAPS is being used in the formal definition of the KEY-ALGORITHM class, 
>>> RFC 5912 needs to be a normative reference.  RFC5912 is informational, but it already in the DOWNREF registry.
> 
>> I think you mean KEM-ALGORITHM.
> 
>> RFC 5911 and RFC 5912 are both in the DOWNREF registry, so I do not think any further action is needed here.
> 
> [Roman -07] My mistake, yes, KEM-ALGORITHM.  I was mixing two issues: commenting that something is in the DOWNREF registry and whether a reference should be informative.  From the ASN.1:
> 
> ==[ snip ]==
>     KEMAlgorithmInformation-2023
>       { iso(1) identified-organization(3) dod(6) internet(1)
>         security(5) mechanisms(5) pkix(7) id-mod(0)
>             id-mod-kemAlgorithmInformation-2023(TBD3) }
>     DEFINITIONS EXPLICIT TAGS ::=
>     BEGIN
>     -- EXPORTS ALL;
>     IMPORTS
>       ParamOptions, PUBLIC-KEY, SMIME-CAPS
> ==[ snip ]==
> 
> SMIME-CAPS and PUBLIC-KEY is being imported.  Those data structures are defined in RFC5912 which is currently informative.  Shouldn't RFC5912 be a normative reference?

Good catch.  Yes, RFC5911 and RFC5912 should be normative references.

Russ