Subject: [lamps] Benjamin Kaduk's Yes on draft-ietf-lamps-crmf-update-algs-06: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 07 Apr 2021 13:57:41 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lamps-crmf-update-algs-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-crmf-update-algs/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Where is the use of ECC with CRMF specified?  RFC 4211 itself only
covers RSA, (FF)DH, and DSA as the listed private-key options that have
a PrivateKeyInfo structure defined.

Other than that I only have nits and a request to reclassify a
reference.

Section 3

      algId identifies the algorithm used to compute the MAC value.  All
      implementations MUST support id-PasswordBasedMAC as presented in
      Section 4.4 of [RFC4211].  Implementations MAY also support PBMAC1
      presented in Section 7.1 of [RFC8018].

nit: s/PBMAC1 presented/PBMAC1 as presented/

Section 4.4

      mac identifies the algorithm and associated parameters of the MAC
      function to be used.  All implementations MUST support HMAC-SHA256
      [HMAC].  All implementations SHOULD support AES-GMAC AES [GMAC]
      with a 128 bit key.

nit: s/ AES / /
nit: s/128 bit/128-bit/

   When this object identifier is used in the ASN.1 algorithm
   identifier, the parameters SHOULD be present.  When present, the
   parameters MUST contain a type of NULL.

nit: I suggest starting the sentence with "Also per [RFC4231],".

Section 6

   function.  In 2010, researchers showed that about half of the real-
   world passwords can be broken with less than 150 million trials,

nit: s/the real-world passwords/the real-world passwords in a leaked
corpus/ (or similar)

Section 8.2

I tihnk draft-ietf-lamps-cms-aes-gmac-alg needs to be a normative
reference, since we SHOULD support AES128-GMAC.

---

From: Russ Housley <[email-masked]>
Date: Wed, 7 Apr 2021 18:16:52 -0400

Ben:

Thanks for the careful review.

I think the information you seek is in RFC 5915.

> nit: s/PBMAC1 presented/PBMAC1 as presented/

Fixed.

>      [HMAC].  All implementations SHOULD support AES-GMAC AES [GMAC]

This should be:

      All implementations SHOULD support AES-GMAC [AES][GMAC]
      with a 128-bit key.

> nit: I suggest starting the sentence with "Also per [RFC4231],".

I suggest:

   When this object identifier is used in the ASN.1 algorithm
   identifier, the parameters SHOULD be present.  When present, the
   parameters MUST contain a type of NULL as specified in [RFC4231].

> nit: s/the real-world passwords/the real-world passwords in a leaked

Sure.  That is an improvement.

> reference, since we SHOULD support AES128-GMAC.

Okay.  I'll make that change too.

Russ