Hi Russ, Thank you very much for addressing my comments promptly. I am ok with your proposals.
BR, Ines On Fri, Mar 26, 2021 at 9:27 PM Russ Housley <hous...@vigilsec.com> wrote: > Ines Robles: > > Thank you for the careful review and comments. > > > Nits/Comments: > > > > 1- Introduction: "however, these algorithms are no longer > > considered the best choices. " => It would be nice to add 1 or more > > sentences explaining why they are no longer the best choices > > I suggest: > > This document updates the cryptographic algorithm requirements for > the Password-Based Message Authentication Code (MAC) in the Internet > X.509 Public Key Infrastructure Certificate Request Message Format > (CRMF) [RFC4211]. The algorithms specified in [RFC4211] were > appropriate in 2005; however, these algorithms are no longer > considered the best choices: > > * HMAC-SHA1 [HMAC][SHS] is not boken yet, but there are much > stronger alternatives [RFC6194]. > > * DES-MAC [PKCS11] provides 56 bits of security, which is no longer > considered secure [WITHDRAW]. > > * Triple-DES-MAC [PKCS11] provides 112 bits of security, which is > now deprecated [TRANSIT]. > > This update specifies algorithms that are more appropriate today. > > With these references: > > [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security > Considerations for the SHA-0 and SHA-1 Message-Digest > Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, > <https://www.rfc-editor.org/info/rfc6194>. > > [TRANSIT] National Institute of Standards and Technology, > "Transitioning the use of cryptographic algorithms and key > lengths", NIST SP 800-131Ar2, March 2019. > > [WITHDRAW] National Institute of Standards and Technology, "NIST > Withdraws Outdated Data Encryption Standard", 2 June 2005. > > > 2- Page 3: "id-PasswordBasedMAC as presented in Section 4.4 of this > document" > > It should be perhaps be "id-PasswordBasedMAC as presented in Section 4.4 > of > > [RFC4211]" ? > > I was thinking of the NEW text appearing in the "updated" RFC 4211. Your > suggestion is more clear. > > > 3- If this document does not present privacy considerations, should it be > > explicitly mentioned in Section 6? > > I do not agree. A document that simply modernized the > mandatory-to-implement cryptographic algorithm in not the place to > introduce the privacy considerations for CRMF. > > > 4- Since the new updates include the use of PBMAC1, HMAC-SHA256, > AES-GMAC AES. > > Should Section 6 include considerations about them or point to place > where to > > find them? e.g. For information on security considerations for PBMAC1 see > > [rfc8018#section-8]. > > Good idea. I suggest: > > Please see [RFC8018] for security considerations related to PBMAC1. > > Please see [HMAC] and [SHS] for security considerations related to > HMAC-SHA256. > > Please see [AES] and [GMAC] for security considerations related to > AES-GMAC. > > Russ > > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
