Re: [Gen-art] Genart last call review of draft-ietf-lamps-crmf-update-algs-04

[Russ Housley <[e-mail]>]

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