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

[Ines Robles <[e-mail]>]

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 <[e-mail]> 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
>
>
>
>