Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
draft-ietf-lamps-cms-sphincs-plus-03

Network Working Group                                         R. Housley
Internet-Draft                                            Vigil Security
Intended status: Standards Track                              S. Fluhrer
Expires: 17 May 2024                                       Cisco Systems
                                                           P. Kampanakis
                                                     Amazon Web Services
                                                           B. Westerbaan
                                                              Cloudflare
                                                        14 November 2023

  Use of the SLH-DSA Signature Algorithm in the Cryptographic Message
                              Syntax (CMS)
                  draft-ietf-lamps-cms-sphincs-plus-03

Abstract

   SLH-DSA is a stateless hash-based signature scheme.  This document
   specifies the conventions for using the SLH-DSA signature algorithm
   with the Cryptographic Message Syntax (CMS).  In addition, the
   algorithm identifier and public key syntax are provided.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 17 May 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights

Housley, et al.            Expires 17 May 2024                  [Page 1]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  SLH-DSA Hash-based Signature Algorithm Overview . . . . . . .   3
   3.  SLH-DSA Public Key Identifier . . . . . . . . . . . . . . . .   4
   4.  Signed-data Conventions . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Appendix: ASN.1 Module . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   NOTICE: This document will be adjusted to match the final FIPS 205
   specification that is published by NIST.  Until that happens, just
   about everything in this document is likely to change.

   This document specifies the conventions for using the SLH-DSA hash-
   based signature algorithm [FIPS205-IPD] with the Cryptographic
   Message Syntax (CMS) [RFC5652] signed-data content type.

   SLH-DSA offers three security levels.  The parameters for each of the
   security levels were chosen to provide 128 bits of security, 192 bits
   of security, and 256 bits of security.  A separate algorithm
   identifier has been assigned for SLH-DSA at each of these security
   levels.

   SLH-DSA is a stateless hash-based signature algorithm.  Other hash-
   based signature algorithms are stateful, including HSS/LMS [RFC8554]
   and XMSS [RFC8391].  Without the need for state kept by the signer,
   SLH-DSA is much less fragile.

1.1.  ASN.1

   CMS values are generated using ASN.1 [X680], using the Basic Encoding
   Rules (BER) and the Distinguished Encoding Rules (DER) [X690].

Housley, et al.            Expires 17 May 2024                  [Page 2]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

1.2.  Motivation

   There have been recent advances in cryptanalysis and advances in the
   development of quantum computers.  Each of these advances pose a
   threat to widely deployed digital signature.

   If large-scale quantum computers are ever built, they will be able to
   break many of the public-key cryptosystems currently in use,
   including RSA, DSA, ECDSA, and EdDSA.  A post-quantum cryptosystem
   (PQC) is secure against quantum computers that have more than a
   trivial number of quantum bits (qu-bits).  It is open to conjecture
   when it will be feasible to build such quantum computers; however, it
   is prudent to use cryptographic algorithms that remain secure if a
   large-scale quantum computer is invented.  SLH-DSA is a PQC signature
   algorithm.

   One use of a PQC signature algoritm is the protection of software
   updates, perhaps using the format described in [RFC4108], to enable
   deployment of software that implements other new PQC algorithms for
   key management and confidentiality.

1.3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  SLH-DSA Hash-based Signature Algorithm Overview

   SLH-DSA is a hash-based signature scheme which consists of a few time
   signature construction, namely Forest of Random Subsets (FORS) and a
   hypertree.  FORS signs a message with a private key.  The
   corresponding FORS public keys are the leaves in k binary trees.  The
   roots of these trees are hashed together to form a FORS root.  SLH-
   DSA uses a one-time signature scheme called WOTS+. The FORS tree
   roots are signed by a WOTS+ one-time signature private key.  The
   corresponding WOTS+ public keys form the leaves in d-layers of Merkle
   subtrees in the SLH-DSA hypertree.  The bottom layer of that
   hypertree signs the FORS roots with WOTS+. The root of the bottom
   Merkle subtrees are then signed with WOTS+ and the corresponding
   WOTS+ public keys form the leaves of the next level up subtree.
   Subtree roots are consequently signed by their corresponding subtree
   layers until we reach the top subtree.  The top layer subtree forms
   the hypertree root which is trusted at the verifier.

Housley, et al.            Expires 17 May 2024                  [Page 3]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

   A SLH-DSA signature consists of the FORS signature, the WOTS+
   signature in each layer, and the path to the root of each subtree
   until the root of the hypertree is reached.

   A SLH-DSA signature is verified by verifying the FORS signature, the
   WOTS+ signatures and the path to the root of each subtree.  When
   reaching the root of the hypertree, the signature verifies only if it
   hashes to the pre-trusted root of the SLH-DSA hypertree.

   SLH-DSA is a stateless hash-based signature algorithm.  Stateful
   hash-based signature schemes require that the WOTS+ private key
   (generated by using a state index) is never reused or the scheme
   loses it security.  Although its security decreases, FORS which is
   used at the bottom of the SLH-DSA hypertree does not collapse if the
   same private key used to sign two or more different messages like in
   stateful hash-based signature schemes.  Without the need for state
   kept by the signer to ensure it is not reused, SLH-DSA is much less
   fragile.

   SLH-DSA was designed to sign up to 2^64 messages and offers three
   security levels.  The parameters of the SLH-DSA hypertree include the
   security parameter, the hash function, the tree height, the number of
   layers of subtrees, the Winternitz parameter of WOTS+, the number of
   FORS trees and leaves in each.  The parameters for each of the
   security levels were chosen to provide 128 bits of security, 192 bits
   of security, and 256 bits of security.

3.  SLH-DSA Public Key Identifier

   The AlgorithmIdentifier for a SLH-DSA public key MUST use one of the
   eight id-alg-slh-dsa object identifiers listed below, based on the
   security level used to generate the SLH-DSA hypertree, the small or
   fast version of the algorithm, and the use of SHA-256 [FIPS180] or
   SHAKE256 [FIPS202].  For example, id-alg-slh-dsa-256s-shake
   represents the 256-bit security level, the small version of the
   algorithm, and the use of SHAKE256.  The parameters field of the
   AlgorithmIdentifier for the SLH-DSA public key MUST be absent.

   When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo
   field of an X.509 certificate [RFC5280], the certificate key usage
   extension MAY contain digitalSignature, nonRepudiation, keyCertSign,
   and cRLSign; the certificate key usage extension MUST NOT contain
   other values.

Housley, et al.            Expires 17 May 2024                  [Page 4]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

      pk-slh-dsa-128s-shake PUBLIC-KEY ::= {
          IDENTIFIER id-alg-slh-dsa-128s-shake
          KEY SLH-DSA-PublicKey
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
          PRIVATE-KEY SLH-DSA-PrivateKey }

      pk-slh-dsa-128f-shake PUBLIC-KEY ::= {
          IDENTIFIER id-alg-slh-dsa-128f-shake
          KEY SLH-DSA-PublicKey
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
          PRIVATE-KEY SLH-DSA-PrivateKey }

      pk-slh-dsa-128s-sha2 PUBLIC-KEY ::= {
          IDENTIFIER id-alg-slh-dsa-128s-sha2
          KEY SLH-DSA-PublicKey
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
          PRIVATE-KEY SLH-DSA-PrivateKey }

      pk-slh-dsa-128f-sha2 PUBLIC-KEY ::= {
          IDENTIFIER id-alg-slh-dsa-128f-sha2
          KEY SLH-DSA-PublicKey
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
          PRIVATE-KEY SLH-DSA-PrivateKey }

      pk-slh-dsa-192s-shake PUBLIC-KEY ::= {
          IDENTIFIER id-alg-slh-dsa-192s-shake
          KEY SLH-DSA-PublicKey
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
          PRIVATE-KEY SLH-DSA-PrivateKey }

      pk-slh-dsa-192f-shake PUBLIC-KEY ::= {
          IDENTIFIER id-alg-slh-dsa-192f-shake
          KEY SLH-DSA-PublicKey
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
          PRIVATE-KEY SLH-DSA-PrivateKey }

Housley, et al.            Expires 17 May 2024                  [Page 5]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

      pk-slh-dsa-256s-shake PUBLIC-KEY ::= {
          IDENTIFIER id-alg-slh-dsa-256s-shake
          KEY SLH-DSA-PublicKey
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
          PRIVATE-KEY SLH-DSA-PrivateKey }

      pk-slh-dsa-256f-shake PUBLIC-KEY ::= {
          IDENTIFIER id-alg-slh-dsa-256f-shake
          KEY SLH-DSA-PublicKey
          PARAMS ARE absent
          CERT-KEY-USAGE
            { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
          PRIVATE-KEY SLH-DSA-PrivateKey }

      SLH-DSA-PublicKey ::= OCTET STRING

      SLH-DSA-PrivateKey ::= OCTET STRING

   NOTE: The values for these object identifiers will be assigned by
   NIST.  Once assigned, they will be added to a future revision of this
   document.

   The SLH-DSA public key value is an OCTET STRING.

   The SLA-DSA private key value is an OCTET STRING.

4.  Signed-data Conventions

   As specified in CMS [RFC5652], the digital signature is produced from
   the message digest and the signer's private key.  The signature is
   computed over different values depending on whether signed attributes
   are absent or present.

   When signed attributes are absent, the SLH-DSA signature is computed
   over the content.  When signed attributes are present, a hash is
   computed over the content using the same hash function that is used
   in the SLH-DSA tree, and then a message-digest attribute is
   constructed to contain the resulting hash value, and then the result
   of DER encoding the set of signed attributes, which MUST include a
   content-type attribute and a message-digest attribute, and then the
   SLH-DSA signature is computed over the DER-encoded output.  In
   summary:

Housley, et al.            Expires 17 May 2024                  [Page 6]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

      IF (signed attributes are absent)
      THEN SLH-DSA_Sign(content)
      ELSE message-digest attribute = Hash(content);
           SLH-DSA_Sign(DER(SignedAttributes))

   When using SLH-DSA, the fields in the SignerInfo are used as follows:

   digestAlgorithm:
      The digestAlgorithm MUST contain the one-way hash function used to
      in the SLH-DSA tree.  The algorithm identifiers for [FIPS180] and
      [FIPS202] are repeated below for convenience.

         mda-sha256 DIGEST-ALGORITHM ::= {
           IDENTIFIER id-sha256
           PARAMS TYPE NULL ARE preferredAbsent }

         mda-shake256 DIGEST-ALGORITHM ::= {
           IDENTIFIER id-shake256
           PARAMS TYPE NULL ARE preferredAbsent }

         hashalgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
           country(16) us(840) organization(1) gov(101) csor(3)
           nistAlgorithms(4) 2 }

         id-sha256 OBJECT IDENTIFIER ::= { hashalgs 1 }

         id-shake256 OBJECT IDENTIFIER ::= { hashAlgs 12 }

   signatureAlgorithm:
      The signatureAlgorithm MUST contain one of the the SLH-DSA
      algorithm identifiers, and the algorithm parameters field MUST be
      absent.  The algorithm identifier MUST be one of the following:
      id-alg-slh-dsa-128s-shake, id-alg-slh-dsa-128f-shake, id-alg-slh-
      dsa-128s-sha2, id-alg-slh-dsa-128f-sha2, id-alg-slh-dsa-192s-
      shake, id-alg-slh-dsa-192f-shake, id-alg-slh-dsa-256s-shake, or
      id-alg-slh-dsa-256f-shake.

   signature:
      The signature contains the signature value resulting from the SLH-
      DSA signing operation with the parameters associated with the
      selected signatureAlgorithm.  The SLH-DSA signing operation and
      the signature verification operation are specified in
      [FIPS205-IPD].

5.  Security Considerations

   Implementations MUST protect the private keys.  Compromise of the
   private keys may result in the ability to forge signatures.

Housley, et al.            Expires 17 May 2024                  [Page 7]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

   When generating an SLH-DSA key pair, an implementation MUST generate
   each key pair independently of all other key pairs in the SLH-DSA
   hypertree.

   A SLH-DSA tree MUST NOT be used for more than 2^64 signing
   operations.

   The generation of private keys relies on random numbers.  The use of
   inadequate pseudo-random number generators (PRNGs) to generate these
   values can result in little or no security.  An attacker may find it
   much easier to reproduce the PRNG environment that produced the keys,
   searching the resulting small set of possibilities, rather than brute
   force searching the whole key space.  The generation of quality
   random numbers is difficult, and [RFC4086] offers important guidance
   in this area.

   When computing signatures, the same hash function SHOULD be used to
   compute the message digest of the content and the signed attributes,
   if they are present.

   When computing signatures, implementations SHOULD include protections
   against fault injection attacks [CMP2018].  Protections against these
   attacks include signature verification prior to releasing the
   signature value to confirm that no error injected and generating the
   signature a few times to confirm that the same signature value is
   produced each time.

6.  IANA Considerations

   For the ASN.1 Module in the Appendix of this document, IANA is
   requested to assign an object identifier (OID) for the module
   identifier (TBD1) with a Description of "id-mod-slh-dsa-2023".  The
   OID for the module should be allocated in the "SMI Security for PKIX
   Module Identifier" registry (1.3.6.1.5.5.7.0).

7.  Acknowledgements

   Thanks to Mike Ounsworth for his careful review and constructive
   comments.

8.  References

8.1.  Normative References

Housley, et al.            Expires 17 May 2024                  [Page 8]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

   [FIPS205-IPD]
              National Institute of Standards and Technology (NIST),
              "Stateless Hash-Based Digital Signature Standard", FIPS
              PUB 205 (Initial Public Draft), 24 August 2023,
              <https://doi.org/10.6028/NIST.FIPS.205.ipd>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/rfc/rfc5280>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5652>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [X680]     ITU-T, "Information technology -- Abstract Syntax Notation
              One (ASN.1): Specification of basic notation", ITU-T
              Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
              <https://www.itu.int/rec/T-REC-X.680>.

   [X690]     ITU-T, "Information technology -- ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021,
              February 2021, <https://www.itu.int/rec/T-REC-X.690>.

8.2.  Informative References

   [CMP2018]  Castelnovi, L., A, Martinelli, and T. Prest, "Grafting
              Trees: A Fault Attack Against the SPHINCS Framework",
              Post-Quantum Cryptography pp. 165-184, PQCrypto 2018,
              Lecture Notes in Computer Science vol 10786, 2018,
              <https://link.springer.com/
              chapter/10.1007/978-3-319-79063-3_8>.

   [FIPS180]  National Institute of Standards and Technology (NIST),
              "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015.

Housley, et al.            Expires 17 May 2024                  [Page 9]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

   [FIPS202]  National Institute of Standards and Technology (NIST),
              "SHA-3 Standard: Permutation-Based Hash and Extendable-
              Output Functions", FIPS PUB 202, August 2015.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/rfc/rfc4086>.

   [RFC4108]  Housley, R., "Using Cryptographic Message Syntax (CMS) to
              Protect Firmware Packages", RFC 4108,
              DOI 10.17487/RFC4108, August 2005,
              <https://www.rfc-editor.org/rfc/rfc4108>.

   [RFC5911]  Hoffman, P. and J. Schaad, "New ASN.1 Modules for
              Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
              DOI 10.17487/RFC5911, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5911>.

   [RFC8391]  Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
              Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
              RFC 8391, DOI 10.17487/RFC8391, May 2018,
              <https://www.rfc-editor.org/rfc/rfc8391>.

   [RFC8554]  McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
              Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
              April 2019, <https://www.rfc-editor.org/rfc/rfc8554>.

Appendix A.  Appendix: ASN.1 Module

   This ASN.1 Module builds upon the conventions established in
   [RFC5911].

   <CODE STARTS>

   SLH-DSA-Module-2023
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       id-smime(16) id-mod(0) id-mod-slh-dsa-2022(TBD1) }

   DEFINITIONS IMPLICIT TAGS ::= BEGIN

   EXPORTS ALL;

   IMPORTS
     PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS
       FROM AlgorithmInformation-2009  -- in [RFC5911]
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-mod(0)

Housley, et al.            Expires 17 May 2024                 [Page 10]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

           id-mod-algorithmInformation-02(58) } ;

   --
   -- Object Identifiers
   --

   id-alg-slh-dsa-128s-shake OBJECT IDENTIFIER ::= { TBD }

   id-alg-slh-dsa-128f-shake OBJECT IDENTIFIER ::= { TBD }

   id-alg-slh-dsa-128s-sha2 OBJECT IDENTIFIER ::= { TBD }

   id-alg-slh-dsa-128f-sha2 OBJECT IDENTIFIER ::= { TBD }

   id-alg-slh-dsa-192s-shake OBJECT IDENTIFIER ::= { TBD }

   id-alg-slh-dsa-192f-shake OBJECT IDENTIFIER ::= { TBD }

   id-alg-slh-dsa-256s-shake OBJECT IDENTIFIER ::= { TBD }

   id-alg-slh-dsa-256f-shake OBJECT IDENTIFIER ::= { TBD }

   --
   -- Signature Algorithm, Public Key, and Private Key
   --

   sa-slh-dsa-128s-shake SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-alg-slh-dsa-128s-shake
       PARAMS ARE absent
       PUBLIC-KEYS { pk-slh-dsa-128s-shake }
       SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-128s-shake } }

   sa-slh-dsa-128f-shake SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-alg-slh-dsa-128f-shake
       PARAMS ARE absent
       PUBLIC-KEYS { pk-slh-dsa-128f-shake }
       SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-128f-shake } }

   sa-slh-dsa-128s-sha2 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-alg-slh-dsa-128s-sha2
       PARAMS ARE absent
       PUBLIC-KEYS { pk-slh-dsa-128s-sha2 }
       SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-128s-sha2 } }

   sa-slh-dsa-128f-sha2 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-alg-slh-dsa-128f-sha2
       PARAMS ARE absent

Housley, et al.            Expires 17 May 2024                 [Page 11]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

       PUBLIC-KEYS { pk-slh-dsa-128f-sha2 }
       SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-128f-sha2 } }

   sa-slh-dsa-192s-shake SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-alg-slh-dsa-192s-shake
       PARAMS ARE absent
       PUBLIC-KEYS { pk-slh-dsa-192s-shake }
       SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-192s-shake } }

   sa-slh-dsa-192f-shake SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-alg-slh-dsa-192f-shake
       PARAMS ARE absent
       PUBLIC-KEYS { pk-slh-dsa-192f-shake }
       SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-192f-shake } }

   sa-slh-dsa-256s-shake SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-alg-slh-dsa-256s-shake
       PARAMS ARE absent
       PUBLIC-KEYS { pk-slh-dsa-256s-shake }
       SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-256s-shake } }

   sa-slh-dsa-256f-shake SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-alg-slh-dsa-256f-shake
       PARAMS ARE absent
       PUBLIC-KEYS { pk-slh-dsa-256f-shake }
       SMIME-CAPS { IDENTIFIED BY id-alg-slh-dsa-256f-shake } }

   pk-slh-dsa-128s-shake PUBLIC-KEY ::= {
       IDENTIFIER id-alg-slh-dsa-128s-shake
       KEY SLH-DSA-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       PRIVATE-KEY SLH-DSA-PrivateKey }

   pk-slh-dsa-128f-shake PUBLIC-KEY ::= {
       IDENTIFIER id-alg-slh-dsa-128f-shake
       KEY SLH-DSA-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       PRIVATE-KEY SLH-DSA-PrivateKey }

   pk-slh-dsa-128s-sha2 PUBLIC-KEY ::= {
       IDENTIFIER id-alg-slh-dsa-128s-sha2
       KEY SLH-DSA-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE

Housley, et al.            Expires 17 May 2024                 [Page 12]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       PRIVATE-KEY SLH-DSA-PrivateKey }

   pk-slh-dsa-128f-sha2 PUBLIC-KEY ::= {
       IDENTIFIER id-alg-slh-dsa-128f-sha2
       KEY SLH-DSA-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       PRIVATE-KEY SLH-DSA-PrivateKey }

   pk-slh-dsa-192s-shake PUBLIC-KEY ::= {
       IDENTIFIER id-alg-slh-dsa-192s-shake
       KEY SLH-DSA-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       PRIVATE-KEY SLH-DSA-PrivateKey }

   pk-slh-dsa-192f-shake PUBLIC-KEY ::= {
       IDENTIFIER id-alg-slh-dsa-192f-shake
       KEY SLH-DSA-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       PRIVATE-KEY SLH-DSA-PrivateKey }

   pk-slh-dsa-256s-shake PUBLIC-KEY ::= {
       IDENTIFIER id-alg-slh-dsa-256s-shake
       KEY SLH-DSA-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       PRIVATE-KEY SLH-DSA-PrivateKey }

   pk-slh-dsa-256f-shake PUBLIC-KEY ::= {
       IDENTIFIER id-alg-slh-dsa-256f-shake
       KEY SLH-DSA-PublicKey
       PARAMS ARE absent
       CERT-KEY-USAGE
         { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
       PRIVATE-KEY SLH-DSA-PrivateKey }

   SLH-DSA-PublicKey ::= OCTET STRING

   SLH-DSA-PrivateKey ::= OCTET STRING

   --

Housley, et al.            Expires 17 May 2024                 [Page 13]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

   -- Expand the signature algorithm set used by CMS [RFC5911]
   --

   SignatureAlgorithmSet SIGNATURE-ALGORITHM ::=
       { sa-slh-dsa-128s-shake |
         sa-slh-dsa-128f-shake |
         sa-slh-dsa-128s-sha2 |
         sa-slh-dsa-128f-sha2 |
         sa-slh-dsa-192s-shake |
         sa-slh-dsa-192f-shake |
         sa-slh-dsa-256s-shake |
         sa-slh-dsa-256f-shake,
         ... }

   --
   -- Expand the S/MIME capabilities set used by CMS [RFC5911]
   --

   SMimeCaps SMIME-CAPS ::=
       { sa-slh-dsa-128s-shake.&smimeCaps |
         sa-slh-dsa-128f-shake.&smimeCaps |
         sa-slh-dsa-128s-sha2.&smimeCaps |
         sa-slh-dsa-128f-sha2.&smimeCaps |
         sa-slh-dsa-192s-shake.&smimeCaps |
         sa-slh-dsa-192f-shake.&smimeCaps |
         sa-slh-dsa-256s-shake.&smimeCaps |
         sa-slh-dsa-256f-shake.&smimeCaps,
         ... }

   END

   <CODE ENDS>

Authors' Addresses

   Russ Housley
   Vigil Security, LLC
   Email: housley@vigilsec.com

   Scott Fluhrer
   Cisco Systems
   Email: sfluhrer@cisco.com

   Panos Kampanakis
   Amazon Web Services
   Email: kpanos@amazon.com

Housley, et al.            Expires 17 May 2024                 [Page 14]
Internet-Draft     SLH-DSA Signature Algorithm in CMS      November 2023

   Bas Westerbaan
   Cloudflare
   Email: bas@westerbaan.name

Housley, et al.            Expires 17 May 2024                 [Page 15]