Use of Password Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax
draft-ietf-lamps-pkcs12-pbmac1-09
Yes
Roman Danyliw
No Objection
Erik Kline
Jim Guichard
(John Scudder)
(Murray Kucherawy)
(Robert Wilton)
(Zaheduzzaman Sarker)
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
É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`.
John Scudder Former IESG member
No Objection
No Objection
(for -08)
Not sent
Murray Kucherawy Former IESG member
No Objection
No Objection
(for -08)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(for -08)
Not sent
Warren Kumari Former IESG member
No Objection
No Objection
(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 Former IESG member
No Objection
No Objection
(for -08)
Not sent