Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax
draft-ietf-lamps-rfc9579bis-06

Yes

Deb Cooley

No Objection

Andy Newton
Erik Kline
Gorry Fairhurst
Gunter Van de Velde
Jim Guichard
Mohamed Boucadair
Paul Wouters
Roman Danyliw
Éric Vyncke

Note: This ballot was opened for revision 05 and is now closed.

Deb Cooley
Yes
Andy Newton
No Objection
Erik Kline
No Objection
Gorry Fairhurst
No Objection
Comment (2025-03-28 for -05) Sent 
I'm not a security expert, but I expected to see a line of text that explained why the following is a "SHOULD". i.e.: If it is relevent, could you explain what would happen if the parameters field was not the same size as the output size?

  "The length of the key generated by the used KDF MUST be encoded
   explicitly in the parameters field and SHOULD be the same size as the
   HMAC function output size."
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
Mohamed Boucadair
(was Discuss) No Objection
Comment (2025-04-25) Sent 
Hi Alicja,

Thank you for addressing all my DISCUSS/COMMENTs [1].

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/spasm/l1L_-GA-iDCEHc--1Owp4tRFoMU/
Paul Wouters
No Objection
Comment (2025-04-02 for -05) Sent 
        If the PBMAC1 algorithm is used, the iterations value MUST be
        ignored. For backwards compatibility, it SHOULD have a non-zero
        positive value.

Is there a reason why not to insist setting it to a single value, eg 1,
to avoid possible misuse of poor implementations?

Is there a reason Argon2 RFC 9106 is not mentioned in any of the examples?
(wasn't it on its way to become NIST approved as well to replace PBKDF2 ?)

RFC 9579 should indeed be informative, as Med raised.

NITS:

I find the way of BOLDing the RFC2119 keywords very distracting if used so
often in paragraphs. I know this is an artifact of some of the markdown
tools in use. Please consider not bolding them all :)
Roman Danyliw
No Objection
Comment (2025-03-31 for -05) Sent 
Thank you to Roni Even for the GENART review.

Abstract
   ... and allow for regulatory compliance.

Realizing that this text comes from RFC9579, does it need to be repeated here?  This assertion of supporting compliance is not mentioned again in the document.  It begs a few questions: (a) which regulations? and (b) why the abstract, a summary of the document, says something not later covered in the document?
Éric Vyncke
No Objection
Comment (2025-04-03 for -05) Sent 
I have only looked at the diff from RFC 9579 (published one year ago). While I have no objection, I wonder why using an erratum was not possible ? (the only explanation would be that the WG in 2024 really selected BMPStrings on purpose).