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

[Ballot comment]
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).

[Ballot comment]
        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 :)

[Ballot comment]
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?

[Ballot comment]
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."

[Ballot discuss]
Hi Alicja,

Thank you for the effort put into this draft.

Also, thanks to Victor Kuarsingh for the opsdir review.

My review focuses on the diff vs 9579. I trust the appendix was validated. The document is well-written. I have an easy-to-fix DISCUSS point and some very few comments:

# RFC 9579 is cited as Normative, while it shouldn't. Please move to info as that RFC will obsoleted. Thanks.

[Ballot comment]
# Abstract: nit

OLD: It obsoletes the RFC 9579.
NEW: It also obsoletes RFC 9579.

# Section 6: Consider citing an authoritative reference for UTF-8 encoding in the text:

CURRENT:
  As documented in Appendix B.1 of [RFC7292], the handling of password
  encoding in the underlying standards is underspecified.  However,
  unlike with Password Based Encryption Scheme 1 (PBES1) [RFC8018] when
  used in the context of PKCS #12 or the MAC algorithm described in
  [RFC7292] (which use BMPString with NULL-termination), all passwords
  used with PBMAC1 MUST be created from UTF-8 encoding  without a NULL
  terminator or Byte Order Mark (BOM).

# Section 9: In order to ease mapping with sections of 9579 and the bis, please consider moving this section to an appendix or as a sub-section of Section 1. Thanks.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lamps-rfc9579bis-05. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there is a single action which we must complete.

In the SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0) registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

the existing registration for

Decimal: 76
Description: id-pkcs12-pbmac1-2023

will have it reference changed from [RFC9579] to [ RFC-to-be ].

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-02-04):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-lamps-rfc9579bis@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, spasm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax) to Informational RFC


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: - 'Use of
Password-Based Message Authentication Code 1 (PBMAC1) in PKCS
  #12 Syntax'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-02-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies additions and amendments to RFCs 7292 and
  8018.  It obsoletes the RFC 9579.  It defines a way to use the
  Password-Based Message Authentication Code 1 (PBMAC1), defined in RFC
  8018, inside the PKCS #12 syntax.  The purpose of this specification
  is to permit the use of more modern Password-Based Key Derivation
  Functions (PBKDFs) and allow for regulatory compliance.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc9579bis/



No IPR declarations have been submitted directly on this I-D.

# Shepherd Write-up for draft-ietf-lamps-rfc9579bis-04

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is support in the LAMPS WG for this document.  It allows
  implementations of PKCS#12 that use PBMAC1 to avoid the obsolete
  SHA-1 hash function.

  This document changes the specified format of password passed to the
  key derivation function.  Previously it was a BMPString, now it is
  a UTF8String.  It should be noted that the test vectors in RFC 9579
  use UTF8String encoding.  This also resolves RFC Errata 7974.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  There was little controversy, and suggested improvements were readily
  accepted by the author.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No one has threatened an appeal or expressed any discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  There code is written and deployed.  The interoperable code implementing this
  Internet-Draft is currently shipping in Mozilla NSS, GnuTLS, and OpenSSL.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  No concerns about interaction with other technologies.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No special reviews are needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  This document does not include a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  The ASN.1 module compiles without errors.  The ASN.1 module is unchanged
  from RFC 9579.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No concerns were noticed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    As reflected in the Datatracker: Informational on the IETF Stream.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    The author has explicitly stated that she is unaware of any IPR
    that needs to be declared.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front
    page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    IDnits complains about the Abstract.  However, Abstract seems to say the
    things that are needed regarding updated and obsoleted RFCs.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No concerns.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    All normative references are published RFCs or ITU-T Recommendations.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    Yes, this document obsoletes RFC 9579.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    IANA is requested to refer to this document (instead of RFC 9579) in the
    registry entry for a previously assigned object identifier from the SMI
    Security for S/MIME Module Identifier registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    No new IANA registries are needed.

# Shepherd Write-up for draft-ietf-lamps-rfc9579bis-04

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is support in the LAMPS WG for this document.  It allows
  implementations of PKCS#12 that use PBMAC1 to avoid the obsolete
  SHA-1 hash function.

  This document changes the specified format of password passed to the
  key derivation function.  Previously it was a BMPString, now it is
  a UTF8String.  It should be noted that the test vectors in RFC 9579
  use UTF8String encoding.  This also resolves RFC Errata 7974.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  There was little controversy, and suggested improvements were readily
  accepted by the author.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No one has threatened an appeal or expressed any discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  There has been some code written.  It was used for the test vectors in
  the document.  As noted above, those test vectors use UTF8String encoding.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  No concerns about interaction with other technologies.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No special reviews are needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  This document does not include a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  The ASN.1 module compiles without errors.  The ASN.1 module is unchanged
  from RFC 9579.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No concerns were noticed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    As reflected in the Datatracker: Informational on the IETF Stream.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    The author has explicitly stated that she is unaware of any IPR
    that needs to be declared.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front
    page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    IDnits complains about the Abstract.  However, Abstract seems to say the
    things that are needed regarding updated and obsoleted RFCs.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No concerns.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    All normative references are published RFCs or ITU-T Recommendations.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    Yes, this document obsoletes RFC 9579.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    IANA is requested to refer to this document (instead of RFC 9579) in the
    registry entry for a previously assigned object identifier from the SMI
    Security for S/MIME Module Identifier registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    No new IANA registries are needed.

# Shepherd Write-up for draft-ietf-lamps-rfc9579bis-04

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is support in the LAMPS WG for this document.  It allows
  implementations of PKCS#12 that use PBMAC1 to avoid the obsolete
  SHA-1 hash function.

  This document changes the specified format of password passed to the
  key derivation function.  Previously it was a BMPString, now it is
  a UTF8String.  It should be noted that the test vectors in RFC 9579
  use UTF8String encoding.  This also resolves RFC Errata 7974.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  There was little controversy, and suggested improvements were readily
  accepted by the author.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No one has threatened an appeal or expressed any discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  There has been some code written.  It was used for the test vectors in
  the document.  As noted above, those test vectors use UTF8String encoding.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  No concerns about interaction with other technologies.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No special reviews are needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  This document does not include a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  The ASN.1 module compiles without errors.  The ASN.1 module is unchanged
  from RFC 9579.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No concerns were noticed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    As reflected in the Datatracker: Informational on the IETF Stream.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    The author has explicitly stated that she is unaware of any IPR
    that needs to be declared.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front
    page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    IDnits complains about the Abstract.  However, Abstract seems to say the
    things that are needed regarding updated and obsoleted RFCs.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No concerns.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    All normative references are published RFCs or ITU-T Recommendations.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    Yes, this document obsoletes RFC 9579.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    IANA is requested to refer to this document (instead of RFC 9579) in the
    registry entry for a previously assigned object identifier from the SMI
    Security for S/MIME Module Identifier registry.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    No new IANA registries are needed.