Skip to main content

Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
draft-ietf-lamps-crmf-update-algs-07

Yes

Roman Danyliw

No Objection

Murray Kucherawy
Zaheduzzaman Sarker
Éric Vyncke
(Alvaro Retana)
(Martin Duke)
(Martin Vigoureux)
(Robert Wilton)

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

Erik Kline
Yes
Comment (2021-03-31 for -05) Sent
[ section 6 ]

* "offers 59 bits a entropy"

  s/a/of/
Roman Danyliw
Yes
Francesca Palombini
No Objection
Comment (2021-04-05 for -05) Sent
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.

Francesca

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) Sent
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.
Murray Kucherawy
No Objection
Warren Kumari
No Objection
Comment (2021-04-06 for -05) Not sent
"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
Benjamin Kaduk Former IESG member
Yes
Yes (2021-04-07 for -06) Sent
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.
Alvaro Retana Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Lars Eggert Former IESG member
No Objection
No Objection (2021-04-06 for -05) Sent
"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:
 * http://www.ietf.org/internet-drafts/draft-ietf-lamps-cms-aes-gmac-alg-02.txt
Martin Duke Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (for -05) Not sent