RFC Errata
RFC 8708, "Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)", February 2020
Note: This RFC has been obsoleted by RFC 9708
Source of RFC: lamps (sec)See Also: RFC 8708 w/ inline errata
Errata ID: 7960
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Russ Housley
Date Reported: 2024-05-28
Verifier Name: Deb Cooley
Date Verified: 2024-05-28
Section Appendix A says:
pk-HSS-LMS-HashSig PUBLIC-KEY ::= { IDENTIFIER id-alg-hss-lms-hashsig KEY HSS-LMS-HashSig-PublicKey PARAMS ARE absent CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
It should say:
pk-HSS-LMS-HashSig PUBLIC-KEY ::= { IDENTIFIER id-alg-hss-lms-hashsig -- KEY no ASN.1 wrapping -- PARAMS ARE absent CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
Notes:
At the time RFC 8708 was published, we did not think anyone would put an HSS/LMS public key in a certificate. We thought the public key would always be distributed by some other means. We now know that some people plan to put an HSS/LMS public key in a certificate. This part of the ASN.1 module does not come into play when using HSS/LMS in the CMS, but we want it to be consistent with the yet-to-be-published document that describes the conventions for an HSS/LMS public key in a certificate. IETF Hackathon experience shows that no ASN.1 wrapping for the public key is the way forward.