Document: draft-ietf-pquip-hbs-state Title: Hash-based Signatures: State and Backup Management Reviewer: Peter Yee Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-pquip-hbs-state-03 Reviewer: Peter Yee Review Date: 2026-02-14 IETF LC End Date: 2026-02-24 IESG Telechat date: 2026-02-19 Summary: This information Internet-Draft provides useful guidance for safe operation of hash-based signature algorithms, which have unique requirements compared to their stateless brethren. I’m not particularly familiar with HBS, so some of my comments may be offered out of ignorance. [Ready with issues.] Major issues: None Minor issues: Page 7, section 2.4, “key export” definition: this is noted as yielding “(partial) private key and state material”. This may be my lack of understanding, but I wasn’t sure why it was only partial. Perhaps an explanation of the parenthetical “partial” would help. Is this supposed to be in cases where signing is partitioned between multiple devices? If so, then for generic definitions as given in section 2.4, I might change “partial” to “potentially partial” since export and import might simply be used for backup of a single device. I can also see an argument that single device backup and restore could be seen as key transfer, but that wasn’t my take. Page 7, section 2.4, 1st paragraph after definitions: could you give a sentence explaining why “generally” is the case here? I can make some guesses, but without explanation, this sentence seems like a bit of a throwaway. Page 9, 1st paragraph, 1st sentence: Please consider explaining how such a prevention mechanism works in the face of things like distributed/partitioned signature generation. Do all of the devices need to be communicating amongst themselves in order to be able to throw a ‘signatures nearing exhaustion’ warning? Would the average user be so tightly in the loop of how signatures are generated for the warning to be actionable? If using centrally managed private key generation (and distribution/partition), the user might have no need for such a warning nor have any ability to effect private key regeneration. Page 11, section 5, title: I’ll wryly point out that some of these potential solutions seem to make HBS even more complicated and tricky to employ. Not a great selling job for the alleged benefits of HBS! Page 12, section 5.2, 1st paragraph, 2nd sentence: if this section is described as multi-trees, why couch this in terms of one or more subordinate devices? One subordinate device wouldn’t seem to buy you much as it is possibly less performant than a non-tree setup, requires two devices, and doubles the signature size. With two or more subordinate devices, I can see some advantage, although the drawbacks listed in the 2nd paragraph are not to be dismissed either. NIST SP 800-208 doesn’t seem to discuss the topic in terms of only one subordinate device, so I would suggest considering making it two or more in the draft. (My two bits, of course. I make no claims of great insights.) If you do make this change, then of course the third sentence can be changed to remove the parentheses around the “s” after “device”, and the verb can be changed from “is(are)” to just “are”. Nits/editorial comments: General: Append a comma after “i.e.” and “e.g.” throughout the draft. Five of ten uses of “i.e.” did not have a comma as was also the case with a few of the uses of “e.g.”. Specific: Page 3, section 1, 1st paragraph, 1st sentence: append a comma after XMSS. Page 4, 1st paragraph, last sentence: insert “in” before “Section 6”. Page 4, 4th bullet item: change “can not” to “cannot”. Page 5, section 2.1, “private key” and “state” definitions: append a colon after each term. At least in the text rendering version, the term and its definition are only separated by two spaces, which doesn’t really give much visual offset. Page 6, section 2.2, 2nd paragraph: change “mechanisms, which aim” to “mechanisms that aim to”. Then delete the leading “to” in each of the bullet items. Page 6, 1st paragraph after the bullet items, 1st sentence: delete the comma after “HBS”. Page 6, section 2.3, 3rd paragraph: change “protocols, which aim” to “protocols that aim to” and delete the leading the leading “to” from the first two bullet items that immediately follow. (The third one already has the “to” elided for some reason.) Page 7, section 2.4, key export/import/transfer definitions: append a colon after each term to make it stand out more clearly from its definition. As above, the text form only has two spaces separating the term and its definition. Page 8, 1st full paragraph, 3rd sentence: change “one finds them self” to “one finds oneself”. Page 10, 1st paragraph after the bullet items, 2nd sentence: append a comma after “write”. Page 10, last paragraph, 1st sentence: append a comma after “correct behavior”. Page 11, section 5.1, title: change “SP-800-208” to “SP 800-208”, as NIST does, at least when not using the NIST document number in a reference. For a reference, it might be better to use “SP.800-208” to match the form used in the document’s DOI. I will note that RFC 9858 used “[NIST_SP_800-208]” for its references to the same document. RFC 9802 used “[SP800208]”, so maybe the inconsistency is of no consequence. Page 12, section 5.2, 1st paragraph, 1st sentence: change “hyper-tree based” to “hyper-tree-based”. Page 12, section 5.2, 2nd paragraph, 5th sentence: change “top” and “level” with a hyphen. Page 15, section 5.6, 1st paragraph, 1st sentence: change “creating a” to “creating an”. Page 15, section 5.6, 2nd paragraph, 3rd sentence: change “more risky” to “riskier”. Page 15, section 5.6, 2nd paragraph 3rd sentence: append “approach” after “This”. Page 15, section 5.7, 1st paragraph, 2nd sentence: bracket “for example” in commas. Page 15, section 5.7, 1st paragraph, 3rd sentence: change “to-be signed” to “to-be-signed”. Page 15, section 5.7, 2nd paragraph, 1st sentence: append a comma after “simple”. Page 17, 1st paragraph after the bullet items, 1st sentence: change “can not” to “cannot”. Page 19, 1st paragraph, 2nd sentence: move “already” to before “initiated”. Also consider if “instantiated” or “initialized” would be more appropriate verbs than “initiated”. Page 19, 2nd bullet item: what does “zero-indexed” mean in the context of set, which is naturally unordered? Page 19, 5th bullet item: append a comma after “OTS key index”. Insert “that” before “the hash of the seed includes”. Page 20, 1st paragraph: append commas after “where” and “time”. Append a colon after “both”. Page 20, 1st bullet item: append a comma after “messages”. Page 20, 4th bullet item: change “decribed” to “described”. Page 20, last paragraph: change (in three places) “backed up” to “backed-up”. Page 23, Acknowledgements, 3rd paragraph: change “this” to “that”. _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
