Note: This ballot was opened for revision 05 and is now closed.
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.
[ section 6 ] * "offers 59 bits a entropy" s/a/of/
"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
"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....
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"
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.