Thank you for the review, Magnus.
WG: these are the PRs to address the review:
https://github.com/lamps-wg/x509-shbs/pull/17
https://github.com/lamps-wg/x509-shbs/pull/18
Further comments below.
Reviewer: Magnus Nyström
Review result: Has Nits
Hi, I did not find any serious issues with this document but have the following
observations and questions:
a) The title is "Algorithm Identifiers for HSS and XMSS," however, the document
contains more than that - it contains usage recommendations and as such, I
think a title more similar to the title of RFC 8708 ("Use of the HSS/LMS
Hash-Based Signature Algorithm in [...]") would be better and more descriptive.
See
https://github.com/lamps-wg/x509-shbs/pull/17yes, see RFC7107b) There is an OID under the old "rsadsi" PKCS #9 OID tree used here (though not defined here). Did RSA (later EMC, later Dell, ...) transfer the ownership / maintenance of that OID tree to the IETF? I should know, since I was the editor of the RFC version of PKCS #9, but it has been too long and I have forgotten ... but just wanted to check such that there is no risk of duplicative assignments.
c) I don't know that there is a need to have the essentially duplicative sections for "Algorithm Identifiers" and "Signature Algorithms" as they specify the same OIDs. Or, alternatively, to be more strict, the "Algorithm Identifiers" section could (or should?) specify "true" ASN.1 Algorithm Identifiers (i.e., using the X.509 "ALGORITHM" class and, e.g., the common AlgorithmIdentifier type from PKCS #10 - see the ASN.1 module of RFC 2986.)
I'm not sure I fully understand the concern here. The "Signature Algorithms" section also has signature-specific information such as lack of digest and ANS.1 encoding of the signature.
As I understand it, the SIGNATURE-ALGORITHM ASN.1 type is preferred over the X.509 ALGORITHM type. The SIGNATURE-ALGORITHM for these algorithms are defined in the ASN.1 module.
I've created
https://github.com/lamps-wg/x509-shbs/pull/18 to (I think) address what I understand of your concerns.
d) I wonder, for completeness, if a Lamport signature scheme should be defined like this too?
Lamport is a one-time signature scheme, so it would not be particularly useful in X.509. HSS and XMSS(MT) build on Lamport to create N-time signature schemes.
Regards, Daniel
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
