[lamps] Paul Wouters' Yes on draft-ietf-lamps-cmp-algorithms-14: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-lamps-cmp-algorithms-14: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-algorithms/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Overall the document looks fine, although I wish it had copied less content and
depended only on the references cited to avoid accidental errors. I think I
checked most of these and they seem fine, but it is possible authors/reviewers
up to now have made a mistake.

Old DISCUSS:
My only DISCUSS item is on recommending PBKDF2. It is kind of showing it age,
and we have a much better replacement with argon2 (RFC 9106). Is there a reason
why not to recommend some argon2 setting instead of PBKDF2 ?

Resolved with:
Mike Ounsworth wrote:
Soooooo .... you're gonna shake your head at this, but CMP only supports
id-PasswordBasedMac (RFC 4210 section 5.1.3.1), which is sorta PBKDF1 (and not
FIPS approved), and therefore a fully RCF4210-compliant CMP implementation will
fail a FIPS certification. So "modernizing" CMP to support real PBKDF2 was
actually a driving reason for this cmp-algorithms draft in the first place

Your suggestion to add Argon2 to CMP seems good to me, but A) is only useful
outside of FIPS-compliant domains (argon2 is not FIPS approved), and B) would
likely delay this draft many months, especially if this is the first use of
Argon2 in PKIX, in which case we'll have to define OIDs, ASN.1 structs, etc. So
based on that, I think I vote to let this document proceed without it. I would
support a followup draft that introduces Argon2 for PKIX.