4. SLH-DSA Signatures

This section preserves the RFC text for X.509 SLH-DSA algorithm identifiers, including ASN.1, OIDs, AlgorithmIdentifier, id-slh-dsa-* and id-hash-slh-dsa-* names, DER examples, certificates, key usage, IANA registrations, and security requirements.

Original RFC Text

4.  SLH-DSA Signatures

   SLH-DSA is a digital signature scheme built upon hash functions.  The
   security of SLH-DSA relies on the security properties of the
   underlying hash functions, such as the presumed difficulty of finding
   preimages.

   Signatures can be placed in a number of different ASN.1 structures.
   The top-level structure for a certificate is given below as being
   illustrative of how signatures are frequently encoded with an
   algorithm identifier and a location for the signature.

     Certificate  ::=  SIGNED{ TBSCertificate }

     SIGNED{ToBeSigned} ::= SEQUENCE {
        toBeSigned           ToBeSigned,
        algorithmIdentifier  SEQUENCE {
            algorithm        SIGNATURE-ALGORITHM.
                               &id({SignatureAlgorithms}),
            parameters       SIGNATURE-ALGORITHM.
                               &Params({SignatureAlgorithms}
                                 {@algorithmIdentifier.algorithm})
                                   OPTIONAL
        },
        signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
                                 {SignatureAlgorithms}
                                 {@algorithmIdentifier.algorithm}))
     }

      |  NOTE: The above syntax is from [RFC5912] and is compatible with
      |  the 2021 ASN.1 syntax [X680].  See [RFC5280] for the 1988 ASN.1
      |  syntax.

   The algorithm identifiers used for signatures are the same as those
   used for public keys.  When used to identify signature algorithms,
   the parameters MUST be absent.

   The data to be signed is prepared for SLH-DSA.  Then, a private key
   operation is performed to generate the raw signature value.

   When signing data using the Pure SLH-DSA signature algorithm,
   Algorithm 22 (slh_sign) from Section 10.2.1 of [FIPS205] is used.
   When verifying Pure SLH-DSA signed data, Algorithm 24 (slh_verify)
   from Section 10.3 of [FIPS205] is used.  When signing data using the
   HashSLH-DSA signature algorithm, Algorithm 23 (hash_slh_sign) from
   Section 10.2.2 of [FIPS205] is used.  When verifying HashSLH-DSA
   signed data, Algorithm 25 (hash_slh_verify) from Section 10.3 of
   [FIPS205] is used.  All four of these algorithms create a message,
   M', from the message to be signed along with other data, and M' is
   operated on by internal SLH-DSA algorithms.  M' may be constructed
   outside the module that performs the internal SLH-DSA algorithms.

   In the case of HashSLH-DSA, there is a pre-hash component of M'
   referred to as PH_M.  PH_M may be computed in the signing/verifying
   module; in which case, the entire message to be signed is sent to the
   module.  Alternatively, PH_M may be computed in a different module.
   In this case, either PH_M is sent to the signing/verifying module,
   which creates M', or M' is created outside the signing/verifying
   module and is sent to the module.  HashSLH-DSA allows this
   implementation flexibility in order to reduce, and make consistent,
   the amount of data transferred to signing/verifying modules.  The
   hash algorithm or extendable-output function (XOF) used to generate
   the pre-hash when signing and verifying with HashSLH-DSA is specified
   after the "-with-" component of the signature algorithm name.  For
   example, when signing with id-hash-slh-dsa-sha2-128s-with-sha256,
   SHA-256 is used as the pre-hash algorithm.  When pre-hashing is
   performed using SHAKE128, the output length is 256 bits.  When pre-
   hashing is performed using SHAKE256, the output length is 512 bits.

   Section 9.2 of [FIPS205] defines an SLH-DSA signature as three
   elements: R, SIG_FORS, and SIG_HT.  The raw octet string encoding of
   an SLH-DSA signature is the concatenation of these three elements,
   i.e., R || SIG_FORS || SIG_HT.  The raw octet string representing the
   signature is encoded directly in the BIT STRING without adding any
   additional ASN.1 wrapping.  For example, in the Certificate
   structure, the raw signature value is encoded in the "signature" BIT
   STRING field.