Hybrid signature spectrums
draft-ietf-pquip-hybrid-signature-spectrums-07

[Ballot comment]
Edited:  Thank you for addressing my discuss!

Thank you to Yaron Sheffer for their secdir reviews.  I do think the authors should consider his points, as there is valuable feedback in that review.  I also believe the other two reviews have valuable feedback as well.  I will refrain from duplicating their comments here.

Please define, or provide a reference for EUF-CMA and SUF-CMA.  At a minimum, spell out the acronyms.

[Ballot discuss]
** Section 4.  Figure 2 and subsequent introduces the concept of needing approval which is underspecified. Unclear is “who’s approval is needed”, “how approval is granted” and “who should seek it”?

I observe that similar feedback was provided in the unanswered SECDIR review.

[Ballot comment]
==[ Planned Abstain/Treat like a Comment ] ==
** Section 4.  Per the text in this section before reaching Figure 2:

-- How is the IETF in a position to interpret NIST guidance with statements such as:

o “This leaves some ambiguity as to whether only the algorithm must be approved and well    implemented, or if that implementation must go through an approval process as well.”

o “the former 1-out-of-n approved software module would suggest a straightforward path for FIPS-140 approvals based on the NIST guidelines”

-- Why is this section giving review and consideration to one nation’s conformance scheme (FIPS)? 

-- What is the generalizable advice here?

I cannot find a basis to take DISCUSS position based on the criteria outline by the IESG at https://datatracker.ietf.org/doc/statement-iesg-discuss-criteria-in-iesg-review-20140507// for the above feedback.  However, in my assessment, the above referenced text is not appropriate for publication in the IETF stream.  For this reason, I plan to abstain when by DISCUSS feedback is resolved.

I observe that similar feedback to the above was provided in the unanswered IETF Last Call SECDIR review.

==[ end ]==

Thank you to Ines Robles for the GENART review.  I recommend the WG review this feedback.  The specific points are not repeated here.

** An updated draft responding to the Last Call feedback from the OPSDIR, SECDIR and GENART reviews was promised on 9-May (https://mailarchive.ietf.org/arch/msg/last-call/7mhKVcCvThGZamDJr8hLF1gqAa0/).  This revision has not materialized.  Is this document actually “done”?

** idnit report:
  ** The document seems to lack an IANA Considerations section.  (See Section
    2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
    when there are no actions for IANA.)

Please add an IANA considerations section which says there are no actions.

** Abstract
  Discussion of this work is encouraged to happen on the IETF PQUIP
  mailing list pqc@ietf.org or on the GitHub repository which contains
  the draft: https://github.com/dconnolly/draft-ietf-pquip-hybrid-
  signature-spectrums

Is this text going to be removed prior to publication?  Is this document “done”?

** Section 1.2.1
  For example, the
  signature scheme ML-DSA (also known as CRYSTALS-Dilithium) that has
  been selected for standardization by NIST.

-- Isn’t the tense wrong here.  Isn’t ML-DSA is standardized in FIPS204?

-- Reference for ML-DSA, please

** Section 1.2.1
  Likewise, the signature scheme Falcon uses complex
  sampling during signature generation. 
  Furthermore, attacks against
  the next-generation multivariate schemes Rainbow and GeMSS might
  raise concerns for conservative adopters of other algorithms, which
  could hinder adoption.

References for Falcon, Rainbow and GeMSS, please.

** Section 1.2.2.  I had trouble following the “time motivation for hybrid signature schemes” as described in this section.  The narrative text makes the case for algorithm turn-over being challenging, primarily because it takes a long time and decisions need to be lived with for some time.  However, without combining this with the complexity argument, by my read, this text only motivates the need for adoption a post-quantum signature algorithm, but not necessary hybrid.

** Section 1.3.1.1.  “EUF-CMA” and “SUF-CMA” is used in this section but not defined, explained, expanded, or referenced.

** Section 4.
  As such, there is a scale of approval that
  developers may consider as to whether they are using at least one
  approved component algorithm (1-out-of-n approved software module),
  or whether the implementation of that component algorithm has gone
  through an approvals review (thus making an all approved software
  module).

Can the concept of “scale of approval” please be explained?

** Section 4.
  The 1-out-of-n combiner uses at least one approved algorithm
  implementation in a black-box way.

Can “black-box” be defined?

[Ballot discuss]
One simple and easy to fix Discuss:

Normative references listed as Informative:  RFC 4949, draft-ietf-pquip-pqt-hybrid-terminology, draft-ietf-tls-hybrid-design are all used in a normative fashion in this draft.  (As Adrian Farrel states in his Opsdir review:  you are relying on them for terminology. The implication is that I may need to read those documents in order to understand this one.)

[Ballot comment]
Thank you to Yaron Sheffer for their secdir reviews.  I do think the authors should consider his points, as there is valuable feedback in that review.  I also believe the other two reviews have valuable feedback as well.  I will refrain from duplicating their comments here.

Please define, or provide a reference for EUF-CMA and SUF-CMA.  At a minimum, spell out the acronyms.

[Ballot comment]
Hi Nina, Britta, Deirdre, and Flo,

Thank you for the effort put into this document. I enjoyed reading it.

Thanks to Adrian for the detailed OPSDIR review. I noted that the authors replied to my recent nudge about the review. I was actually waiting for the authors's follow-up before making my own review but ...

== Updated based on a clarification from Paul.

#  Manageability

  “I think I would have liked to see some commentary on the configurability
    of algorithms and keys because the increased variability of component
    algorithms in hybrid systems seems to imply a more dynamic configuration
    of security. And (presumably) we reach a point where the chief
    vulnerability is not the algorithm but the configuration. Similarly,
    management mechanisms used to inspect the operation of secure systems
    provide both a valuable tool to the user/operator and a significant way
    for an attacker to find out how the system is behaving.

    I can't say I'm an expert in any of this, but it was a surprise to find
    no mention of manageability or configuration in the document.”

Not sure if some words are needed to clarify why this is not a concern.

I won’t reiterate here the comments raised by Adrian, but please consider these.

# Please find below some minor comments:

## Internet Documents

CURRENT:
  We follow existing Internet documents on hybrid terminology

Not sure what is an “Internet document”. I guess you are simply referring to other I-Ds. You may simply say “This document makes use of the terms defined in XX, XX, and XX.” Or “This document adheres to the terminology defined in XX, XX, XX”.

## “We” constructs

The document, although informational, will reflects an IETF consensus. Please use “This document XX” rather than “We XXX”

## Simplify how terms are presented

Some of the terminology entries use “xx defines a TERM to be ..”. I would delete and simplify all these statements by simply having a term and its definition without such mention.

OLD:
  Term: we define “term” as DEFINITION

NEW:
  Term: DEFINITION

## “Next-generation ..” will be stale fast

I would avoid such use and go for “new” or other similar terms.

## Expand use acronyms: many are provided without expanding them.

Cheers,
Med

[Ballot comment]
Hi Nina, Britta, Deirdre, and Flo,

Thank you for the effort put into this document. I enjoyed reading it.

Thanks to Adrian for the detailed OPSDIR review. I noted that the authors replied to my recent nudge about the review. I was actually waiting for the authors's follow-up before making my own review but ...

== Updated based on a clarification from Paul.

#  Manageability

  “I think I would have liked to see some commentary on the configurability
    of algorithms and keys because the increased variability of component
    algorithms in hybrid systems seems to imply a more dynamic configuration
    of security. And (presumably) we reach a point where the chief
    vulnerability is not the algorithm but the configuration. Similarly,
    management mechanisms used to inspect the operation of secure systems
    provide both a valuable tool to the user/operator and a significant way
    for an attacker to find out how the system is behaving.

    I can't say I'm an expert in any of this, but it was a surprise to find
    no mention of manageability or configuration in the document.”

I won’t reiterate here the comments raised by Adrian, but please consider these.

# Please find below some minor comments:

## Internet Documents

CURRENT:
  We follow existing Internet documents on hybrid terminology

Not sure what is an “Internet document”. I guess you are simply referring to other I-Ds. You may simply say “This document makes use of the terms defined in XX, XX, and XX.” Or “This document adheres to the terminology defined in XX, XX, XX”.

## “We” constructs

The document, although informational, will reflects an IETF consensus. Please use “This document XX” rather than “We XXX”

## Simplify how terms are presented

Some of the terminology entries use “xx defines a TERM to be ..”. I would delete and simplify all these statements by simply having a term and its definition without such mention.

OLD:
  Term: we define “term” as DEFINITION

NEW:
  Term: DEFINITION

## “Next-generation ..” will be stale fast

I would avoid such use and go for “new” or other similar terms.

## Expand use acronyms: many are provided without expanding them.

Cheers,
Med

[Ballot discuss]
Hi Nina, Britta, Deirdre, and Flo,

Thank you for the effort put into this document. I enjoyed reading it.

Thanks to Adrian for the detailed OPSDIR review. I noted that the authors replied to my recent nudge about the review. I was actually waiting for the authors's follow-up before making my own review but ...

Till then, I’m inheriting a DISCUSS point from Adrian’s review.

# DISUCSS: Manageability

  “I think I would have liked to see some commentary on the configurability
    of algorithms and keys because the increased variability of component
    algorithms in hybrid systems seems to imply a more dynamic configuration
    of security. And (presumably) we reach a point where the chief
    vulnerability is not the algorithm but the configuration. Similarly,
    management mechanisms used to inspect the operation of secure systems
    provide both a valuable tool to the user/operator and a significant way
    for an attacker to find out how the system is behaving.

    I can't say I'm an expert in any of this, but it was a surprise to find
    no mention of manageability or configuration in the document.”

This is even surprising given that the WG charter focuses on “operational guidance”.

[Ballot comment]
# OPSDIR review comments

I won’t reiterate here the comments raised by Adrian, but please consider these.

Please find below some minors comments:

## Internet Documents

CURRENT:
  We follow existing Internet documents on hybrid terminology

Not sure what is an “Internet document”. I guess you are simply referring to other I-Ds. You may simply say “This document makes use of the terms defined in XX, XX, and XX.” Or “This document adheres to the terminology defined in XX, XX, XX”.

## “We” constructs

The document, although informational, will reflects an IETF consensus. Please use “This document XX” rather than “We XXX”

## Simplify how terms are presented

Some of the terminology entries use “xx defines a TERM to be ..”. I would delete and simplify all these statements by simply having a term and its definition without such mention.

OLD:
  Term: we define “term” as DEFINITION

NEW:
  Term: DEFINITION

## “Next-generation ..” will be stale fast

I would avoid such use and go for “new” or other similar terms.

## Expand use acronyms: many are provided without expanding them.

Cheers,
Med

[Ballot comment]
# Internet AD comments for draft-ietf-pquip-hybrid-signature-spectrums-06
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S1

* "are one reason for to consider" -> "are one reason to consider"

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pquip-hybrid-signature-spectrums-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

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-04-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pquip-hybrid-signature-spectrums@ietf.org, paul.hoffman@icann.org, paul.wouters@aiven.io, pqc@ietf.org, pquip-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Hybrid signature spectrums) to Informational RFC


The IESG has received a request from the Post-Quantum Use In Protocols WG
(pquip) to consider the following document: - 'Hybrid signature spectrums'
  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-04-07. 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 describes classification of design goals and security
  considerations for hybrid digital signature schemes, including proof
  composability, non-separability of the component signatures given a
  hybrid signature, backwards/forwards compatibility, hybrid
  generality, and simultaneous verification.

  Discussion of this work is encouraged to happen on the IETF PQUIP
  mailing list pqc@ietf.org or on the GitHub repository which contains
  the draft: https://github.com/dconnolly/draft-ietf-pquip-hybrid-
  signature-spectrums




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pquip-hybrid-signature-spectrums/



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

# Document Shepherd Write-Up for draft-ietf-pquip-hybrid-signature-spectrums

## 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 was broad agreement. One participant had some concerns that might not
  be met in the current draft, but they were not able to give specific text
  to alleviate their conerns; the points they were concerned with should not
  block the document.

  There were some late comments for the WG Last Call that the authors agreed
  with and fixed in the -06 draft.

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

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.

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)?
 
  This document describes design goals but not specific protocols.

## 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.
 
  The design goals covered here are likely to be of interest to any WG that
  is considering using hybrid digital signature mechanisms in a transition
  to post-quantum cryptography. It would be useful to hear from those WGs
  during IETF Last Call to see if the material here is helpful or needs more
  detail on particular hybrid signature schemes.

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.
 
  None were 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]?
 
  No YANG was used in the preparation of this document.

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.
 
  None were needed.

## 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?
 
  The document will be useful to many WGs who are making choices about hybrid
  signature schemes. It is a tad wordy, but that is needed because the concepts
  covered are pretty intricate. It is ready for IETF review.

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?
   
    This document should go through normal external reviews.

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?
   
    It is informational, which is correct for this document because the
    intention is to help other WGs make their own decisions.

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.
   
    Yes, and none of the authors responded with any applicable IPR.

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.
   
    Each author has been listed on all drafts.

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.)
   
    Nothing remaining other than warnings.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
    All references are informative, which is reasonable for a document such as this.

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

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.
   
    N/A

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?
   
    N/A

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.
   
    This does not update or obsolete any other document.

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]).
   
    There are no IANA considerations.

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.
   
    N/A.

# Document Shepherd Write-Up for draft-ietf-pquip-hybrid-signature-spectrums

## 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 was broad agreement. One participant had some concerns that might not
  be met in the current draft, but they were not able to give specific text
  to alleviate their conerns; the points they were concerned with should not
  block the document.

  There were some late comments for the WG Last Call that the authors agreed
  with and fixed in the -06 draft.

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

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.

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)?
 
  This document describes design goals but not specific protocols.

## 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.
 
  The design goals covered here are likely to be of interest to any WG that
  is considering using hybrid digital signature mechanisms in a transition
  to post-quantum cryptography. It would be useful to hear from those WGs
  during IETF Last Call to see if the material here is helpful or needs more
  detail on particular hybrid signature schemes.

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.
 
  None were 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]?
 
  No YANG was used in the preparation of this document.

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.
 
  None were needed.

## 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?
 
  The document will be useful to many WGs who are making choices about hybrid
  signature schemes. It is a tad wordy, but that is needed because the concepts
  covered are pretty intricate. It is ready for IETF review.

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?
   
    This document should go through normal external reviews.

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?
   
    It is informational, which is correct for this document because the
    intention is to help other WGs make their own decisions.

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.
   
    Yes, and none of the authors responded with any applicable IPR.

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.
   
    Each author has been listed on all drafts.

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.)
   
    Nothing remaining other than warnings.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
    All references are informative, which is reasonable for a document such as this.

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

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.
   
    N/A

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?
   
    N/A

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.
   
    This does not update or obsolete any other document.

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]).
   
    There are no IANA considerations.

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.
   
    N/A.

# Document Shepherd Write-Up for draft-ietf-pquip-hybrid-signature-spectrums

## 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 was broad agreement. One participant had some concerns that might not
  be met in the current draft, but they were not able to give specific text
  to alleviate their conerns; the points they were concerned with should not
  block the document.

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

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.

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)?
 
  This document describes design goals but not specific protocols.

## 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.
 
  The design goals covered here are likely to be of interest to any WG that
  is considering using hybrid digital signature mechanisms in a transition
  to post-quantum cryptography. It would be useful to hear from those WGs
  during IETF Last Call to see if the material here is helpful or needs more
  detail on particular hybrid signature schemes.

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.
 
  None were 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]?
 
  No YANG was used in the preparation of this document.

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.
 
  None were needed.

## 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?
 
  The document will be useful to many WGs who are making choices about hybrid
  signature schemes. It is a tad wordy, but that is needed because the concepts
  covered are pretty intricate. It is ready for IETF review.

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?
   
    This document should go through normal external reviews.

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?
   
    It is informational, which is correct for this document because the
    intention is to help other WGs make their own decisions.

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.
   
    I forgot to do this, and am doing so in parallel with the AD review.
    It is exceptionally unlikely that there are any IPR concerns.

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.
   
    Each author has been listed on all drafts.

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.)
   
    Nothing remaining other than warnings.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
   
    All references are informative, which is reasonable for a document such as this.

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

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.
   
    N/A

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?
   
    N/A

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.
   
    This does not update or obsolete any other document.

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]).
   
    There are no IANA considerations.

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.
   
    N/A.