Found 2 records.

Status: Verified (2)

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

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.

Errata ID: 7963
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Russ Housley
Date Reported: 2024-05-29
Verifier Name: Deb Cooley
Date Verified: 2024-05-30

Section 4 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 } }

      HSS-LMS-HashSig-PublicKey ::= OCTET STRING

   Note that the id-alg-hss-lms-hashsig algorithm identifier is also
   referred to as id-alg-mts-hashsig.  This synonym is based on the
   terminology used in an early draft version of the document that
   became [HASHSIG].

   The public key value is an OCTET STRING.  Like the signature format,
   it is designed for easy parsing.  The value is the number of levels
   in the public key, L, followed by the LMS public key.

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 } }

      HSS-LMS-HashSig-PublicKey ::= OCTET STRING

   Note that the id-alg-hss-lms-hashsig algorithm identifier is also
   referred to as id-alg-mts-hashsig.  This synonym is based on the
   terminology used in an early draft version of the document that
   became [HASHSIG].

   When the public key appears outside a certificate, it is an 
   OCTET STRING.  Like the signature format, it is designed for easy
   parsing.  The value is the number of levels in the public key, L,
   followed by the LMS public key.

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.

Report New Errata