Skip to main content

8. Operational Considerations

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​

8.  Operational Considerations

   SLH-DSA uses the same OID to identify a public key and a signature
   algorithm.  The implication of this is that, despite being
   mathematically possible, an SLH-DSA key identified by a Pure SLH-DSA
   OID is not permitted to be used to generate or verify a signature
   identified by a HashSLH-DSA OID, and vice versa.

   Certification authority (CA) operators will need to decide in advance
   whether their CA certificates will use Pure SLH-DSA or HashSLH-DSA
   and assign the appropriate OID to the public and private keys when
   generating their certificate.  Some of the following considerations
   may affect this decision.

   *  When using an external signing module, such as a Hardware Security
      Module (HSM), the size of data that can be transferred to and
      processed by the signature module may be limited.  SLH-DSA
      performs two passes on the internal M' message, so it must be held
      in memory.  Using HashSLH-DSA reduces the size of M'.

   *  Large CRLs might also exceed the size limits of HSM signing
      operations when using Pure SLH-DSA.  One way to limit the size of
      CRLs is to make use of CRL Distribution Points and Issuing
      Distribution Points to create partitioned CRLs in accordance with
      Section 5.2.5 of [RFC5280].

   *  End Entity (EE) certificates with many subject alternative names
      (SANs) might also exceed the size limits of HSM signing
      operations.

   *  Potential verifiers' environments might need to be considered.
      The entire certificate or CRL needs to be held in memory during
      SLH-DSA signature verification; it cannot be streamed.  In
      particular, there is a randomizer (R) that is extracted from the
      SLH-DSA signature and fed to a digest function before M' is.
      Thus, to stream a message for SLH-DSA verification, the signature
      must come before the message.  This is not the case for
      certificates and CRLs.  Using HashSLH-DSA reduces the size of the
      M' being held in memory.

   An SLH-DSA private key has a very large (2^64) number of signatures
   it can safely generate (see Section 9).  If an operator might
   conceivably generate a number of signatures approaching this limit,
   they should mitigate potential harm by tracking the number of
   signatures generated and destroying the private key once an
   appropriate limit is reached or by setting the "Not After"
   (expiration) date of the certificate such that the limit couldn't
   possibly be surpassed given the rate of signing.
Last updated on