Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)

Note: This ballot was opened for revision 05 and is now closed.

Benjamin Kaduk Yes

Comment (2021-04-07 for -06)
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

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.

Erik Kline Yes

Comment (2021-03-31 for -05)
[ section 6 ]

* "offers 59 bits a entropy"


Roman Danyliw Yes

Alvaro Retana No Objection

Francesca Palombini No Objection

Comment (2021-04-05 for -05)
Thank you for the work on this document. I only have one typo and one very minor comment, feel free to take them or leave them.


1. -----

   *  HMAC-SHA1 [HMAC][SHS] is not boken yet, but there are much

FP: s/boken/broken

2. -----

   The algorithm identifier for HMAC-SHA256 is defined in [RFC4231]:

   The algorithm identifier for AES-GMAC [AES][GMAC] with a 128-bit key

FP: suggestion to replace "identifier" with "ASN.1 object identifier"

John Scudder No Objection

Comment (2021-04-07 for -06)
I don’t get why this is a collection of patches instead of a bis, but so be it. It’s clear and well-written, thanks.

Lars Eggert No Objection

Comment (2021-04-06 for -05)
"Copyright Notice", paragraph 1, comment:

Shouldn't this document use the pre5378Trust200902 boilerplate, since it quotes
from RFC4211? Or have the authors of RFC4211 given copyright to the Trust?

All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 1, paragraph 3, nit:
-    *  HMAC-SHA1 [HMAC][SHS] is not boken yet, but there are much
+    *  HMAC-SHA1 [HMAC][SHS] is not broken yet, but there are much
+                                     +

The following URLs in the document failed to return content:

Martin Duke No Objection

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Robert Wilton No Objection

Warren Kumari No Objection

Comment (2021-04-06 for -05)
No email
send info
"HMAC-SHA1 [HMAC][SHS] is not boken yet, but there are much stronger alternatives [RFC6194]."

Yup, it ain't borken yet, but it might be broken soon... I was somewhat conflicted as to if I should point this out or not -- I'd dearly love us to start referring to things as boken (or borken) as it has a nice tie to borked....

Zaheduzzaman Sarker No Objection

Éric Vyncke No Objection