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

Yes

Paul Wouters
Roman Danyliw

No Objection

Erik Kline
Jim Guichard
John Scudder
Murray Kucherawy
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke
(Robert Wilton)

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

Paul Wouters
Yes
Comment (2024-02-27 for -08) Sent 
Thanks for the document and the effort to get rid of SHA-1.

I noticed the lack of mentioning of Argon (RFC 9106). I know I have myself had to use a construct of PBKDF2(Argon(...)) to get the benefit of modern KDFs while being compliant to NIST. It was my understanding that Argon will be (or is already?) allowed by NIST. So I wonder if that might be worth mentioning anyway to use as a construct.

(I'm currently only finding the comments, eg https://csrc.nist.gov/csrc/media/Projects/crypto-publication-review-project/documents/initial-comments/sp800-132-initial-public-comments-2023.pdf but I vaguely remember this was in a further stage at this point)
Roman Danyliw
Yes
Erik Kline
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Murray Kucherawy
No Objection
Warren Kumari
No Objection
Comment (2024-02-28 for -08) Sent 
Thank you for this document. When I initially opened it to review, I was somewhat apprehensive - PKCS #12 and I are not friends, and this implied that I was going to endure it for ~17 pages...
and then I was pleasantly surprised to discover that 1: there is very little actual PKCS #12 involved, and 2: it's really only ~5 pages of text, and the rest is test vectors (which I'll happily admit I just ignored :-))
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2024-02-29 for -08) Sent 
# Éric Vyncke, INT AD, comments for draft-ietf-lamps-pkcs12-pbmac1-08

Thank you for the work put into this document. As indicated below, I wonder why it is an informational only document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Russ Housley for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Section 3, BCP14, and intended status

There should be no such BCP14 in an informational I-D and normative language does not seem relevant in my view. The 2 RFC obsoleted by this I-D do not rely on normative language.

OTOH, this kind of document should probably be standards track as it is key for interoperation. I urge the SEC AD to upgrade the status of this document to PS even if it requires another IETF Last Call.

## Section 5

A lot of "SHOULD" without any explanation about the case when this "SHOULD" can be bypassed.

# NITS (non-blocking / cosmetic)

## Section 2

Usually, I-Ds do not use a personal tone such as `we propose`.
Robert Wilton Former IESG member
No Objection
No Objection (for -08) Not sent