Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure
draft-ietf-lamps-pq-composite-sigs-19

[Ballot comment]
Hi Mike, all,

Thank you for taking care of my previous review [1]. The changes made in -15/-18 [2] are great.

As indicated in the thread [1], I let you decide whether further changes are needed especially for this point:

> Section 2 says the following:
>  This specification assumes a seed-based keygen for ML-DSA.
>
> Maybe I'm misreading this, but is this saying that only the seed mode is
> supported? If so, isn't that a deviating from 9881 where expandedKey is allowed?

Mike: You are not misreading that. There was extensive debate in the WG on this point and the WG was very clear not to download the {seed, expanded, both} mess into composites. It is not uncommon for one RFC to profile another one; IE to take only a subset of the features from the other RFC. So I think it's "profiling 9881" not "deviating from 9881". Also note that since Composite-ML-DSA is a distinct algorithm from ML-DSA with distinct object identifiers and distinct key encodings anyway, it's only a spiritual difference at best.

[Med] Thank you for confirming that I was not hallucinating :-) Great to see this is an informed decision from the WG. So, all is set for me ... except maybe that I would prefer if this is stated clearing in the document, but I leave that to you to decide.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/spasm/C1oyS0AOxpO8Z8CR5tv0VroErfw/

[2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-lamps-pq-composite-sigs-15&url2=draft-ietf-lamps-pq-composite-sigs-18&difftype=--html

[Ballot comment]
Thanks to Russ for the comprehensive shepherding, including the DOWNREF.  Thanks to Tim and Donald for the GENART and SEC review respectively.

thanks for the VERY complete draft; with very thorough citations.  In most of my reviews I try to check many (most?) of those citations, this broke me on doing that.

* I think it is in Med's comments, but I also noticed the broken reference:
>421   Given this design of Composite ML-DSA, it is possible to split the
>422   pre-hashing step out from the signature generation process -- see
>423   {#impl-cons-external-ph} for further discussion and sample
>424   algorithms.

* As mentioned in some other AD comments, the "stronger strong" is very hard to read, capitalization "stronger Strong Existential" is advised:
>201   Composite ML-DSA is applicable in PKIX-related applications that
>202   would otherwise use ML-DSA and where existential unforgeability (EUF-
>203   CMA) security is acceptable, instead of the stronger strong
>204   existential unforgeability (SUF-CMA) which Composite ML-DSA does not
>205   offer.

[Ballot comment]
Thank you for this work. This is an important step forward in our handling of PQ crypto.

Section 3.1.1: There are a lot of MAY-examples in this section, when the whole thing
is an overarching "MAY do whatever internally so long as the external is
consistent." Consider not using MAY for every single example.

----

Section 4 has:

>  example, a stand-alone RSA private key can be encoded in Chinese
>  Remainder Theorem form.  In order to obtain interoperability,

Consider an informative reference?

----

Section 6 has:

>  Labels are represented here as ASCII strings, but implementers MUST
>  convert them to byte strings using the obvious ASCII conversions

While they may be obvious, calling them so comes across a bit oddly. Maybe just say something like "Labels are represented here as ASCII strips, but are octet sequences when used in..."

----

Consider moving Section 6.2 to an appendix; it's not part of the core protocol, just design background.

----

In Section 9.1:

>  algorithm security or to provide migration flexibility.  Let's
>  quickly explore both.

It's typically advised to avoid first- or second-person language in
specifications. I'd just drop this final sentence, personally.

----

In Section 9.3:

>  designers are aware that some implementers may be forced to break
>  this rule due to operational constraints.  This section documents the
>  implications of doing so.

This statement makes me nervous. Maybe this section should explain why the MUST
exists, and not touch any implied "permission" to violate it?

----

In Section 9.4:

>  message which happens to start with this string.  The designers
>  accepted this trade-off.

I would remove this last sentence. You've explained the trade-off; it's up to the implementers to decide whether it's worth making, no?

----

Consider moving Section 10 to an appendix.

===NITS FOLLOW===

- In Appendix A, "maxima" is already the plural of "maximum" -- we don't need "maximas" (unless perhaps we're talking about multiple sets of maxima?)
- In Section 2.1, there's a broken cross-reference to {#impl-cons-external-ph}

[Ballot comment]
Thank you for this work. This is an important step forward in our handling of PQ crypto.

Section 3.1.1: There are a lot of MAY-examples in this section, when the whole thing
is an overarching "MAY do whatever internally so long as the external is
consistent." Consider not using MAY for every single example.

----

Section 4 has:

>  example, a stand-alone RSA private key can be encoded in Chinese
>  Remainder Theorem form.  In order to obtain interoperability,

Consider an informative reference?

----

Section 6 has:

>  Labels are represented here as ASCII strings, but implementers MUST
>  convert them to byte strings using the obvious ASCII conversions

While they may be obvious, calling them so comes across a bit oddly. Maybe just say something like "Labels are represented here as ASCII strips, but are octet sequences when used in..."

----

Consider moving Section 6.2 to an appendix; it's not part of the core protocol, just design background.

----

In Section 9.1:

>  algorithm security or to provide migration flexibility.  Let's
>  quickly explore both.

It's typically advised to avoid first- or second-person language in
specifications. I'd just drop this final sentence, personally.

----

In Section 9.3:

>  designers are aware that some implementers may be forced to break
>  this rule due to operational constraints.  This section documents the
>  implications of doing so.

This statement makes me nervous. Maybe this section should explain why the MUST
exists, and not touch any implied "permission" to violate it?

----

In Section 9.4:

>  message which happens to start with this string.  The designers
>  accepted this trade-off.

I would remove this last sentence. You've explained the trade-off; it's up to the implementers to decide whether it's worth making, no?

----

Consider moving Section 10 to an appendix.

[Ballot discuss]
Hi Mike, John, Massimiliano, Jan, and Scott,

Thank you for the effort put into this specification. The document reads well ... even for an OPS AD :-)

I trust that the test vectors, in particular, were checked by WG participants other than the authors.

Please find below some comments below. I also flagged some nits and other minor edits that I will send in a PR for authors convenience.

# ML-DSA is normative for composite ML-DSA

CURRENT:
  Composite ML-DSA is a Post-Quantum / Traditional hybrid signature
  scheme which combines ML-DSA as specified in [FIPS.204] and [RFC9881]

  …

  As this specification uses ML-DSA as a component of all composite
  algorithms, all security considerations from [RFC9881] apply.

Please move RFC9881 from Informative to Normative.

## As I’m there, I’d like to check one related part:

Section 2 says the following:
  This specification assumes a seed-based keygen for ML-DSA.

Maybe I’m misreading this, but is this saying that only the seed mode is supported? If so, isn’t that a deviating from 9881 where expandedKey is allowed?

# Terminology: I'm adding this as a DISCUSS point as I think this is important to ensure consistency among specs in this area

Section 2:
  This specification is consistent with the terminology defined in
  [RFC9794].  In addition, the following terminology is used throughout
  this specification:

I interpret this as the terms that follow are not listed in RFC9794 but are an addition. However, it is not clear to me the rationale followed here. For example,

## we do have this entry grabbed from RFC9794 with an explicit pointer to that RFC:

  *COMPOSITE CRYPTOGRAPHIC ELEMENT*: [RFC9794] defines composites as: A
  cryptographic element that incorporates multiple component
  cryptographic elements of the same type in a multi-algorithm scheme.

The citation does not match exactly the entry as defined in 9794:

      A cryptographic element that incorporates multiple component
      cryptographic elements of the same type for use in a multi-
      algorithm scheme, such that the resulting composite cryptographic
      element is exposed as a singular interface of the same type as the
      component cryptographic elements.

## … and this one which is already defined in RFC9794 but repeated here

  *POST-QUANTUM TRADITIONAL (PQ/T) HYBRID SCHEME*: A multi-algorithm
  scheme where at least one component algorithm is a post-quantum
  algorithm and at least one is a traditional algorithm.

## Unless there is a need to deviate from RFC9794, I would suggest to rely on the terms/definitions in RFC9794 (and make that RFC as normative) and only define here new terms not listed in RFC9794.

# Given the side-channel implication, any reason why this isn’t a MUST?

CURRENT:
  Note that in step 4 above, both component signature processes are
  invoked, and no indication is given about which one failed.  This
  SHOULD be done in a timing-invariant way to prevent side-channel
  attackers from learning which component algorithm failed.

[Ballot comment]
# Abstract: regional requirement, not an absolute one

OLD:
  These combinations are tailored to meet regulatory
  guidelines.

NEW:
  These combinations are tailored to meet regulatory
  Guidelines in certain regions. 

# Backward compatibility

## Usual

CURRENT:
  *APPLICATION BACKWARDS COMPATIBILITY*: The usual definition of
  backwards compatibility, meaning whether an upgraded and non-upgraded
  application can successfully establish communication.

### If this is usual definition, then do we need to have a dedicated entry for it here?

### I suggest

NEW:
  *APPLICATION BACKWARDS COMPATIBILITY*: A property indicating whether an upgraded and non-upgraded
  application can successfully establish communication.

## Section 10.2 has the following:

  The term "application backwards compatibility" is used here to mean
  that existing systems as they are deployed today can interoperate
  with the upgraded systems of the future. 

Why the definition is repeated here? is there any difference between the intent here and the relevant entry in Section 1.1?

Unless there is subtlety there, I suggest to delete that text as it is redundant with the terminology section. 

## I don’t parse the following:

CURRENT:
  *PROTOCOL BACKWARDS COMPATIBILITY*: A property whereby a new feature
  can be added to a protocol without requiring any changes to the
  protocol's specification and only minimal changes to its
  implementations (such as adding new identifiers). 

Adding a new feature is a change per se!

### Can we please update this definition to better reflect the intended property?

### Do we need this term at the first place? This is only mentioned once with self-contained context.

## Internal inconsistency

Section 1:
  Backwards compatibility in the sense of upgraded systems continuing
  to interoperate with legacy systems is not directly covered in this
  specification, but is the subject of Section 10.2.

I’m having troubles to digest the intent of this sentence as it conveys conflicting messages (at least for me).

## If the intent is to say that backward compatibility is not ensured then maybe reword to, e.g.:

NEW:
  Backwards compatibility in the sense of upgraded systems continuing
  to interoperate with legacy systems is not directly covered in this
  specification. Refer to Section 10.2 for more details.

# Notations

Can we please add "->" to the list of notations?

# Section 2.1: Broken reference

CURRENT:
  Given this design of Composite ML-DSA, it is possible to split the
  pre-hashing step out from the signature generation process -- see
  {#impl-cons-external-ph} for further discussion and sample
  algorithms.

# Section 2.1: HashML-DSA

CURRENT:
  Note that while the overall construction of Composite ML-DSA is
  similar to that of HashML-DSA, the ML-DSA component inside the
  composite is "pure" ML-DSA; implementing this specification does not
  require an implementation of HashML-DSA.

Shouldn’t this be more explicit that HashML-DSA is disallowed per the same rationale as in rfc9881#section-8.3?

# Section 3.1

CURRENT:
  Errors produced by the component KeyGen() routines MUST be forwarded
  on to the calling application.

I don’t understand the use of “forwarded” in this context? Isn’t the API call internal within a system?

Maybe s/forwarded on/communicated?

# Section 3.1.1: Modified process and implications

CURRENT:
  In cases where it is desirable to have a deterministic KeyGen of one
  or both component keys from a seed, this process MAY be modified to
  expose an interface of Composite-ML-DSA.KeyGen(seed) such that
  one component algorithm is generated from the seed and the other from
  random, or the input seed is cryptographically expanded to produce
  seeds for both components.  Implementation details and security
  analysis of such a modified key generation process is outside the
  scope of this document.

Shouldn’t this need be highlighted in the SEC or OPS cons section so that appropriate analysis in done before making use of a modified process?

# Section 4: Table 1

Can we please add a pointer to Section 4 of FIPS.204 to indicate the source of that table?

# Section 6: Obvious

CURRENT:
  Labels are represented here as ASCII strings, but implementers MUST
  convert them to byte strings using the obvious ASCII conversions
  prior to concatenating them with other byte values as described in
  Section 2.2.

do we need to keep “obvious” here? If it was, then why calling it out :-)

# Section 6: Key sizes

CURRENT:
  For all RSA key types and sizes, the exponent is RECOMMENDED to be
  65537.  Implementations MAY support only 65537 and reject other
  exponent values.  Legacy RSA implementations that use other values
  for the exponent MAY be used within a composite, but need to be
  careful when interoperating with other implementations.

Given the interoperability issues there, I suggest to add relevant operational considerations under the OPS Cons section to cover at least the following:

* Implems need to expose which sizes they support
* Implems need to offer a configuration knob to control the size.

# Section 10: Operational Considerations

## I suggest to rename “Implementation Considerations” to “Operational Considerations” as that section is more about operational guidance. This would be also consistent with the approach in 9881.

## Inherit ML-DSA Operational Considerations

There are important considerations that are inherited by the composite design. Can we please add a note to increase awareness about considerations listed in rfc9881#section-8?

## Hidden Operational Consideration

Section 1.3:
  Composite ML-DSA is NOT RECOMMENDED for use in
  applications where it is has not been shown that EUF-CMA is
  acceptable. 

This reco is IMO hidden in the introduction part. Given the importance of this reco for those who will deploy, I suggest we have this more visible as part of the OPS Considerations section.

Hope this helps.

Cheers,
Med

[Ballot comment]
Thanks to the authors and the working group for their work on this well written document. Thanks as well for the discussion on application backwards compatibility, and differentiating it from protocol backwards compatibility. This should be helpful to application developers.

I have a couple non-blocking COMMENTS to share.

In section 2.1, first paragraph, I believe the following sentence could be made more clear:

  "Also, "pure" (aka non-pre-hashed) modes lack support for digesting the message once and signing it with multiple different keys."

I had to read this a few times to understand what it is saying. Perhaps rephrase as:

  "Also, “pure” (i.e., non–pre-hashed) modes do not support hashing a message once and then using that same digest to sign with multiple different keys."

This same paragraph uses "not pre-hashed" and "non-pre-hashed" to mean the same thing. I believe this could be made more clear by using one form only and dropping the other.

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I would like to share some nits that came to attention during review.

1) Abstract: "Composite ML-DSA is applicable in applications that uses X.509 or PKIX data structures..." - "uses" should be "use"

2) Introduction: "but will remain strong in the interim, the only uncertainty is around the timing." - perhaps replace the "," with ";" ?

3) Introduction: "such as RSA, DSA and its elliptic curve variants" -> "such as RSA, DSA and their elliptic curve variants"

4) Introduction: "stronger strong" reads a bit odd - perhaps consider capitalizing : Existential Unforgeability (EUF-CMA), Strong Existential Unforgeability (SUF-CMA) ?

[Ballot comment]

# Éric Vyncke INT AD comments for draft-ietf-lamps-pq-composite-sigs-15
CC @evyncke

Thank you for the work put into this document. As the document is heavy on cryptography, I only had a high-level review.

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

Special thanks to  for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Section 1

I was wondering about the use of "composite" in the abstract rather than the expected "hybrid", but this section is a superb justification about the use of "composite". Thanks ! Should there be a reference to draft-ietf-pquip-pqt-hybrid-terminology ?

Wondering whether an IETF specification can assert statements like `In some situations it might be possible to add Post-Quantum, via a PQ/T Hybrid, to an already audited and compliant solution *without invalidating the existing certification*, whereas a full replacement of the traditional cryptography would almost certainly incur regulatory and compliance delays.` as the IETF does not certify anything...

### Section 1.1

Cosmetic, but the use of UPPERCASE terms for something that is not an acronym is not really nice to (my) eyes.

### Section 1.3

Who is the "we" in `we consider the two security properties` ? The authors ? The WG ? The IETF ? Please avoid ambiguities in a specification.

This could happen in other sections, but I won't mention it anymore.

### Section 8

Suggest to use a reference (e.g. https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml) in addition to the IANA registry names (also for other registries).

### Sections 10.1 & 11.1

As the IETF is global, the use of NIST and FIPS without qualifying the terms with USA is ambiguous. Please qualify these terms to ensure that this is the USA version.

Request for IETF Last Call review by GENART Completed: Ready with Nits. Reviewer: Tim Evens. Sent review to list. Submission of review completed at an earlier date.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lamps-pq-composite-sigs-14. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the SMI Security for PKIX Module Identifier registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

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

a single new registration will be made as follows:

Decimal: [ TBD-at-Registration ]
Description: id-mod-composite-signatures
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the SMI Security for PKIX Algorithms registry in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

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

18 existing registrations will have their references changed to [ RFC-to-be ] as follows:

Decimal Description Reference
--------------------------------
37 id-MLDSA44-RSA2048-PSS-SHA256 [ RFC-to-be ]
38 id-MLDSA44-RSA2048-PKCS15-SHA256 [ RFC-to-be ]
39 id-MLDSA44-Ed25519-SHA512 [ RFC-to-be ]
40 id-MLDSA44-ECDSA-P256-SHA256 [ RFC-to-be ]
41 id-MLDSA65-RSA3072-PSS-SHA512 [ RFC-to-be ]
42 id-MLDSA65-RSA3072-PKCS15-SHA512 [ RFC-to-be ]
43 id-MLDSA65-RSA4096-PSS-SHA512 [ RFC-to-be ]
44 id-MLDSA65-RSA4096-PKCS15-SHA512 [ RFC-to-be ]
45 id-MLDSA65-ECDSA-P256-SHA512 [ RFC-to-be ]
46 id-MLDSA65-ECDSA-P384-SHA512 [ RFC-to-be ]
47 id-MLDSA65-ECDSA-brainpoolP256r1-SHA512 [ RFC-to-be ]
48 id-MLDSA65-Ed25519-SHA512 [ RFC-to-be ]
49 id-MLDSA87-ECDSA-P384-SHA512 [ RFC-to-be ]
50 id-MLDSA87-ECDSA-brainpoolP384r1-SHA512 [ RFC-to-be ]
51 id-MLDSA87-Ed448-SHAKE256 [ RFC-to-be ]
52 id-MLDSA87-RSA3072-PSS-SHA512 [ RFC-to-be ]
53 id-MLDSA87-RSA4096-PSS-SHA512 [ RFC-to-be ]
54 id-MLDSA87-ECDSA-P521-SHA512 [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions 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 list of actions 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 2026-02-03):

From: The IESG
To: IETF-Announce
CC: debcooley1@gmail.com, draft-ietf-lamps-pq-composite-sigs@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, spasm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Composite ML-DSA for use in X.509 Public Key Infrastructure) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: - 'Composite
ML-DSA for use in X.509 Public Key Infrastructure'
  as Proposed Standard

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 2026-02-03. 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 defines combinations of US NIST ML-DSA in hybrid with
  traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519,
  and Ed448.  These combinations are tailored to meet regulatory
  guidelines.  Composite ML-DSA is applicable in applications that uses
  X.509 or PKIX data structures that accept ML-DSA, but where the
  operator wants extra protection against breaks or catastrophic bugs
  in ML-DSA, and where EUF-CMA-level security is acceptable.




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


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/4761/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5639: Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation (Informational - Independent Submission stream)

# Shepherd Write-up for draft-ietf-lamps-pq-composite-sigs-12

## 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.

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

  There was a lot of debate, and many people asked for fewer combinations, but
  in the end there were people that want each of the combinations that are
  specified..

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 otherwise expressed disagreemnt.

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)?

  Some code written, and a lot of time was spent at the hackathon to make sure
  that various implementation are interoperable.

## 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.

  ASN.1 is used.  Once a placeholder values are inserted for the module
  identifier and the algorithm identifiers that will be assigned by IANA,
  the ASN.1 module compiles without error.

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.

  ASN.1 is used.  Once a placeholder values are inserted for the module
  identifier and the algorithm identifiers that will be assigned by IANA,
  the ASN.1 module compiles without error.

## 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: Proposed Standard 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.

    One IPR disclosure exists: https://datatracker.ietf.org/ipr/4761/

    This IPR disclosure was highlighted during WG Last Call, and after some
    discussion about the language in the disclosure, the LAMPS WG was very
    comfortable moving forward.

    The authors have explicitly stated that they are unaware of any other 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 an obsolete reference to [RFC4210]; the RFC Editor
    should change this to [RFC9810].

    IDnits complains about ASN.1 tags; IDnits thinks the tags are references.

    IDnits complains about a missing reference to [X509ASN1], but it is
    referenced in a comment in the ASN.1 module.

    IDnits complains about an unused reference to [RFC5758] and [SEC1], but they
    are referenced in Table 5.

    IDnits complains about a downref to [RFC2986], [RFC5915], [RFC6090],
    [RFC6234], [RFC8017], [RFC8032], but all of these documents are already
    in the downref registry.

    IDnits complains about a downref to [RFC5639].  The IESG is asked to call
    out this downref in the IETF Last Call, and then add it to the downref
    registry.

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?

    One normative reference is not freely available, but it is a standard
    produced by the American National Standards Institute.

    Some informative references are behind a paywall.

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.

    Yes, there is a downref to [RFC5639].  The IESG is asked to call out
    this downref in the IETF Last Call, and then add it to the downref
    registry.

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 have already been published.

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.

    No.

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 assign two object identifiers (OIDs).  The
    first ones is for the ASN.1 module identifier.  The rest are for
    the composite signature algorithms define in this document.

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.

# Shepherd Write-up for draft-ietf-lamps-pq-composite-sigs-12

## 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.

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

  There was a lot of debate, and many people asked for fewer combinations, but
  in the end there were people that want each of the combinations that are
  specified..

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 otherwise expressed disagreemnt.

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)?

  Some code written, and a lot of time was spent at the hackathon to make sure
  that various implementation are interoperable.

## 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.

  ASN.1 is used.  Once a placeholder values are inserted for the module
  identifier and the algorithm identifiers that will be assigned by IANA,
  the ASN.1 module compiles without error.

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.

  ASN.1 is used.  Once a placeholder values are inserted for the module
  identifier and the algorithm identifiers that will be assigned by IANA,
  the ASN.1 module compiles without error.

## 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: Proposed Standard 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.

    One IPR disclosure exists: https://datatracker.ietf.org/ipr/4761/

    This IPR disclosure was highlighted during WG Last Call, and after some
    discussion about the language in the disclosure, the LAMPS WG was very
    comfortable moving forward.

    The authors have explicitly stated that they are unaware of any other 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 an obsolete reference to [RFC4210]; the RFC Editor
    should change this to [RFC9810].

    IDnits complains about ASN.1 tags; IDnits thinks the tags are references.

    IDnits complains about a missing reference to [X509ASN1], but it is
    referenced in a comment in the ASN.1 module.

    IDnits complains about an unused reference to [RFC5758] and [SEC1], but they
    are referenced in Table 5.

    IDnits complains about a downref to [RFC2986], [RFC5915], [RFC6090],
    [RFC6234], [RFC8017], [RFC8032], but all of these documents are already
    in the downref registry.

    IDnits complains about a downref to [RFC5639].  The IESG is asked to call
    out this downref in the IETF Last Call, and then add it to the downref
    registry.

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?

    One normative reference is not freely available, but it is a standard
    produced by the American National Standards Institute.

    Some informative references are behind a paywall.

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.

    Yes, there is a downref to [RFC5639].  The IESG is asked to call out
    this downref in the IETF Last Call, and then add it to the downref
    registry.

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 have already been published.

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.

    No.

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 assign two object identifiers (OIDs).  The
    first ones is for the ASN.1 module identifier.  The rest are for
    the composite signature algorithms define in this document.

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.