LAMPS WG J. Massimo Internet-Draft P. Kampanakis Intended status: Standards Track AWS Expires: 19 July 2025 S. Turner sn3rd B. E. Westerbaan Cloudflare 15 January 2025 Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML- DSA draft-ietf-lamps-dilithium-certificates-latest Abstract Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://lamps- wg.github.io/dilithium-certificates/#go.draft-ietf-lamps-dilithium- certificates.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium- certificates/. Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (mailto:spasm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at https://www.ietf.org/mailman/listinfo/spasm/. Source for this draft and an issue tracker can be found at https://github.com/lamps-wg/dilithium-certificates. 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 19 July 2025. Copyright Notice Copyright (c) 2025 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 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 1.1. Requirements Language 2. Identifiers 3. ML-DSA Signatures in PKIX 4. ML-DSA Public Keys in PKIX 5. Key Usage Bits 6. Private Key Format 7. IANA Considerations 8. Security Considerations 8.1. Rationale for disallowing HashML-DSA 9. References 9.1. Normative References 9.2. Informative References Appendix A. ASN.1 Module Appendix B. Security Strengths Appendix C. Examples C.1. Example Private Key C.2. Example Public Key C.3. Example Certificate Appendix D. Pre-hashing (ExternalMu-ML-DSA) Acknowledgments Authors' Addresses 1. Introduction The Module-Lattice-Based Digital Signature Algorithm (ML-DSA) is a quantum-resistant digital signature scheme standardized by the US National Institute of Standards and Technology (NIST) PQC project [NIST-PQC] in [FIPS204]. This document specifies the use of the ML- DSA in Public Key Infrastructure X.509 (PKIX) certificates and Certificate Revocation Lists (CRLs) at three security levels: ML-DSA- 44, ML-DSA-65, and ML-DSA-87. [FIPS204] defines two variants of ML-DSA: a pure and a prehash variant. Only the former is specified in this document. See Section 8.1 for the rationale. The pure variant of ML-DSA supports the typical prehash flow, see Appendix D. In short: one cryptographic module can compute the hash _mu_ on line 6 of algorithm 7 of [FIPS204] and pass it to a second module to finish the signature. The first module only needs access to the full message and the public key, whereas the second module only needs access to hash _mu_ and the private key. Prior to standardisation, ML-DSA was known as Dilithium. ML-DSA and Dilithium are not compatible. 1.1. Requirements Language 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. Identifiers The AlgorithmIdentifier type is defined in [RFC5912] as follows: AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= SEQUENCE { algorithm ALGORITHM-TYPE.id({AlgorithmSet}), parameters ALGORITHM-TYPE. Params({AlgorithmSet}{@algorithm}) OPTIONAL } | 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 fields in AlgorithmIdentifier have the following meanings: * algorithm identifies the cryptographic algorithm with an object identifier. * parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field. The OIDs are: id-ml-dsa-44 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-ml-dsa-44(17) } id-ml-dsa-65 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-ml-dsa-65(18) } id-ml-dsa-87 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) sigAlgs(3) id-ml-dsa-87(19) } The contents of the parameters component for each algorithm MUST be absent. The ctx value used in the ML-DSA signing and verification [FIPS204] of ML-DSA signatures defined in this specification (X.509 certificates, CRLs) is the empty string. 3. ML-DSA Signatures in PKIX ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with- aborts framework [Fiat-Shamir]. The security is based upon the hardness of lattice problems over module lattices [Dilithium]. ML- DSA provides three parameter sets for the NIST PQC security categories 2, 3 and 5. Signatures are used in a number of different ASN.1 structures. As shown in the ASN.1 representation from [RFC5280] below, in an X.509 certificate, a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual 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})) } Signatures are also used in the CRL list ASN.1 representation from [RFC5280] below. In a X.509 CRL, a signature is encoded with an algorithm identifier in the signatureAlgorithm attribute and a signatureValue attribute that contains the actual signature. CertificateList ::= SIGNED{ TBSCertList } The identifiers defined in Section 2 can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate/CertificateList and the signature field in the sequence TBSCertificate/TBSCertList in certificates and CRLs, respectively, [RFC5280]. The parameters of these signature algorithms MUST be absent, as explained in Section 2. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-ml-dsa-*. The signatureValue field contains the corresponding ML-DSA signature computed upon the ASN.1 DER encoded tbsCertificate/tbsCertList [RFC5280]. Conforming Certification Authority (CA) implementations MUST specify the algorithms explicitly by using the OIDs specified in Section 2 when encoding ML-DSA signatures in certificates and CRLs. Conforming client implementations that process certificates and CRLs using ML- DSA MUST recognize the corresponding OIDs. Encoding rules for ML-DSA signature values are specified Section 2. 4. ML-DSA Public Keys in PKIX In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax: SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE { algorithm AlgorithmIdentifier {PUBLIC-KEY, {IOSet}}, subjectPublicKey BIT STRING } | 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 fields in SubjectPublicKeyInfo have the following meaning: * algorithm is the algorithm identifier and parameters for the public key (see above). * subjectPublicKey contains the byte stream of the public key. [I-D.ietf-lamps-cms-ml-dsa] defines the following public key identifiers for ML-DSA: pk-ml-dsa-44 PUBLIC-KEY ::= { IDENTIFIER id-ml-dsa-44 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-ml-dsa-65 PUBLIC-KEY ::= { IDENTIFIER id-ml-dsa-65 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-ml-dsa-87 PUBLIC-KEY ::= { IDENTIFIER id-ml-dsa-87 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } ML-DSA-PublicKey ::= OCTET STRING (SIZE (1312 | 1952 | 2592)) ML-DSA-PrivateKey ::= OCTET STRING (SIZE (32)) An ML-DSA public key is encoded in an X.509 certificate's SubjectPublicKeyInfo type as described in Section 3 of [I-D.ietf-lamps-cms-ml-dsa]. Section 3 of [I-D.ietf-lamps-cms-ml-dsa] also defines the ML-DSA- Public and ML-DSA-PrivateKey for when the ML-DSA pubic key appears outside of a SubjectPublicKeyInfo type and for when the ML-DSA private key appears outside of an Asymmetric Key Package [RFC5958], respectively. Appendix C contains example ML-DSA public keys encoded using the textual encoding defined in [RFC7468]. 5. Key Usage Bits The intended application for the key is indicated in the keyUsage certificate extension; see Section 4.2.1.3 of [RFC5280]. If the keyUsage extension is present in a certificate that indicates id-ml- dsa-* in the SubjectPublicKeyInfo, then the at least one of following MUST be present: digitalSignature; or nonRepudiation; or keyCertSign; or cRLSign. If the keyUsage extension is present in a certificate that indicates id-ml-dsa-* in the SubjectPublicKeyInfo, then the following MUST NOT be present: keyEncipherment; or dataEncipherment; or keyAgreement; or encipherOnly; or decipherOnly. Requirements about the keyUsage extension bits defined in [RFC5280] still apply. 6. Private Key Format An ML-DSA private key is encoded by storing its 32-octet seed in the privateKey field as follows. [FIPS204] specifies two formats for an ML-DSA private key: a 32-octet seed (xi) and an (expanded) private key. The expanded private key (and public key) is computed from the seed using ML- DSA.KeyGen_internal(xi) (algorithm 6). "Asymmetric Key Packages" [RFC5958] describes how to encode a private key in a structure that both identifies what algorithm the private key is for and allows for the public key and additional attributes about the key to be included as well. For illustration, the ASN.1 structure OneAsymmetricKey is replicated below. OneAsymmetricKey ::= SEQUENCE { version Version, privateKeyAlgorithm SEQUENCE { algorithm PUBLIC-KEY.&id({PublicKeySet}), parameters PUBLIC-KEY.&Params({PublicKeySet} {@privateKeyAlgorithm.algorithm}) OPTIONAL} privateKey OCTET STRING (CONTAINING PUBLIC-KEY.&PrivateKey({PublicKeySet} {@privateKeyAlgorithm.algorithm})), attributes [0] Attributes OPTIONAL, ..., [[2: publicKey [1] BIT STRING (CONTAINING PUBLIC-KEY.&Params({PublicKeySet} {@privateKeyAlgorithm.algorithm}) OPTIONAL, ... } | NOTE: The above syntax is from [RFC5958] and is compatible with | the 2021 ASN.1 syntax [X680]. When used in a OneAsymmetricKey type, the privateKey OCTET STRING contains the raw octet string encoding of the 32-octet seed. The publicKey field SHOULD be omitted because the public key can be computed as noted earlier in this section. Appendix C contains example ML-DSA private keys encoded using the textual encoding defined in [RFC7468]. 7. IANA Considerations For the ASN.1 module in Appendix A, IANA is requested to assign an object identifier (OID) for the module identifier (TBD1) with a Description of "id-mod-x509-ml-dsa-2024". 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). 8. Security Considerations The Security Considerations section of [RFC5280] applies to this specification as well. The digital signature scheme defined within this document are modeled under strongly existentially unforgeable under chosen message attack (SUF-CMA). For the purpose of estimating security strength, it has been assumed that the attacker has access to signatures for no more than 2^{64} chosen messages. ML-DSA offers both deterministic and randomized signing. By default ML-DSA signatures are non-deterministic. The private random seed (rho') for the signature is pseudorandomly derived from the signer’s private key, the message, and a 256-bit string, rnd - where rnd should be generated by an approved RBG. In the deterministic version, rng is instead a 256-bit constant string. The source of randomness in the randomized mode has been "hedged" against sources of poor entropy, by including the signers private key and message into the derivation. The primary purpose of rnd is to facilitate countermeasures to side-channel attacks and fault attacks on deterministic signatures. In the design of ML-DSA, care has been taken to make side-channel resilience easier to achieve. For instance, ML-DSA does not depend on Gaussian sampling. Implementations must still take great care not to leak information via various side channels. While deliberate design decisions such as these can help to deliver a greater ease of secure implementation - particularly against side-channel attacks - it does not necessarily provide resistance to more powerful attacks such as differential power analysis. Some amount of side-channel leakage has been demonstrated in parts of the signing algorithm (specifically the bit-unpacking function), from which a demonstration of key recovery has been made over a large sample of signatures. Masking countermeasures exist for ML-DSA, but come with a performance overhead. A fundamental security property also associated with digital signatures is non-repudiation. Non-repudiation refers to the assurance that the owner of a signature key pair that was capable of generating an existing signature corresponding to certain data cannot convincingly deny having signed the data. The digital signature scheme ML-DSA possess three security properties beyond unforgeability, that are associated with non-repudiation. These are exclusive ownership, message-bound signatures, and non-resignability. These properties are based tightly on the assumed collision resistance of the hash function used (in this case SHAKE-256). Exclusive ownership is a property in which a signature sigma uniquely determines the public key and message for which it is valid. Message-bound signatures is the property that a valid signature uniquely determines the message for which it is valid, but not necessarily the public key. Non-resignability is the property in which one cannot produce a valid signature under another key given a signature sigma for some unknown message m. These properties are not provided by classical signature schemes such as DSA or ECDSA, and have led to a variety of attacks such as Duplicate-Signature Key Selection (DSKS) attacks , and attacks on the protocols for secure routing. A full discussion of these properties in ML-DSA can be found at [CDFFJ21]. These properties are dependent, in part, on unambiguous public key serialization. It for this reason the public key structure defined in Section 4 is intentionally encoded as a single OCTET STRING. 8.1. Rationale for disallowing HashML-DSA The HashML-DSA mode defined in Section 5.4 of [FIPS204] MUST NOT be used; in other words, public keys identified by id-hash-ml-dsa-44- with-sha512, id-hash-ml-dsa-65-with-sha512, and id-hash-ml-dsa-87- with-sha512 MUST NOT be in X.509 certificates used for CRLs, OCSP, certificate issuance and related PKIX protocols (e.g. TLS). The use of HashML-DSA public keys within end entity certificates is not prohibited, but conventions for doing so are outside the scope of this document. This restriction is for both implementation and security reasons. The implementation reason for disallowing HashML-DSA stems from the fact that ML-DSA and HashML-DSA are incompatible algorithms that require different Verify() routines. This forwards to the protocol the complexity of informing the client whether to use ML-DSA.Verify() or HashML-DSA.Verify() along with the hash algorithm to use. Additionally, since the same OIDs are used to identify the ML-DSA public keys and ML-DSA signature algorithms, an implementation would need to commit a given public key to be either of type ML-DSA or HashML-DSA at the time of certificate creation. This is anticipated to cause operational issues in contexts where the operator does not know at key generation time whether the key will need to produce pure or pre-hashed signatures. ExternalMu-ML-DSA avoids all of these operational concerns by virtue of having keys and signatures that are indistinguishable from ML-DSA (i.e., ML-DSA and ExternalMu-ML-DSA are mathematically equivalent algorithms). The difference between ML-DSA and ExternalMu-ML-DSA is merely an internal implementation detail of the signer and has no impact on the verifier or network protocol. The security reason for disallowing HashML-DSA is that the design of the ML-DSA algorithm provides enhanced resistance against signature collision attacks, compared with conventional RSA or ECDSA signature algorithms. Specifically, ML-DSA binds the hash of the public key tr to the message to-be-signed prior to hashing, as described in line 6 of Algorithm 7 of [FIPS204]. In practice, this provides binding to the indended verification public key, preventing some attacks that would otherwise allow a signature to be successfully verified against a non-intended public key. Also, this unlikely, theoretical binding means that in the unlikely discovery of a collision attack against SHA-3, an attacker would have to perform a public-key-specific collision search in order to find message pairs such that H(tr || m1) = H(tr || m2) since a direct hash collision H(m1) = H(m2) will not suffice. HashML-DSA removes both of these enhanced security properties. 9. References 9.1. Normative References [FIPS204] National Institute of Standards and Technology (NIST), "Module-Lattice-based Digital Signature Standard", FIPS PUB 204, August 2023, . [I-D.ietf-lamps-cms-ml-dsa] S, B., R, A., and D. Van Geest, "Use of the ML-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", Work in Progress, Internet-Draft, draft-ietf- lamps-cms-ml-dsa-01, 22 November 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [X690] ITU-T, "Information Technology -- Abstract Syntax Notation One (ASN.1): 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, . 9.2. Informative References [CDFFJ21] Cremers, C., Düzlü, S., Fiedler, R., Fischlin, M., and C. Janson, "BUFFing signature schemes beyond unforgeability and the case of post-quantum signatures", In Proceedings of the 42nd IEEE Symposium on Security and Privacy , 2021, . [Dilithium] Bai, S., Ducas, L., Lepoint, T., Lyubashevsky, V., Schwabe, P., Seiler, G., and D. Stehlé, "CRYSTALS- Dilithium Algorithm Specifications and Supporting Documentation", 2021, . [Fiat-Shamir] Lyubashevsky, V., "Fiat-Shamir with aborts: Applications to lattice and factoring-based signatures", International Conference on the Theory and Application of Cryptology and Information Security , 2009, . [NIST-PQC] National Institute of Standards and Technology (NIST), "Post-Quantum Cryptography Project", 20 December 2016, . [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, . Appendix A. ASN.1 Module This appendix includes the ASN.1 module [X680] for the ML-DSA. Note that as per [RFC5280], certificates use the Distinguished Encoding Rules; see [X690]. This module imports objects from [RFC5912] and [I-D.ietf-lamps-cms-ml-dsa]. | RFC EDITOR: Please replace TBD2 with the value assigned by IANA | during the publication of [I-D.ietf-lamps-cms-ml-dsa]. Also | please replace [I-D.ietf-lamps-cms-ml-dsa] in the module with a | reference to the published RFC. X509-ML-DSA-2024 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-x509-ml-dsa-2024(TBD1) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL; IMPORTS PUBLIC-KEY, SIGNATURE-ALGORITHM FROM AlgorithmInformation-2009 -- From [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } sa-ml-dsa-44, sa-ml-dsa-65, sa-ml-dsa-87, pk-ml-dsa-44, pk-ml-dsa-65, pk-ml-dsa-87, ML-DSA-PublicKey, ML-DSA-PrivateKey FROM ML-DSA-Module-2024 -- From [I-D.ietf-lamps-cms-ml-dsa] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0) id-mod-ml-dsa-2024(TBD2) } ; -- -- Expand SignatureAlgorithms from RFC 5912 -- SignatureAlgorithms SIGNATURE-ALGORITHM ::= { sa-ml-dsa-44 | sa-ml-dsa-65 | sa-ml-dsa-87, ... } -- -- Expand SignatureAlgorithms from RFC 5912 -- PublicKeys PUBLIC-KEY ::= { pk-ml-dsa-44 | pk-ml-dsa-65 | pk-ml-dsa-87, ... } END Appendix B. Security Strengths Instead of defining the strength of a quantum algorithm in a traditional manner using the imprecise notion of bits of security, NIST has instead elected to define security levels by picking a reference scheme, which NIST expects to offer notable levels of resistance to both quantum and classical attack. To wit, an algorithm that achieves NIST PQC security level 1 must require computational resources to break the relevant security property, which are greater than those required for a brute-force key search on AES-128. Levels 3 and 5 use AES-192 and AES-256 as reference respectively. Levels 2 and 4 use collision search for SHA-256 and SHA-384 as reference. The parameter sets defined for NIST security levels 2, 3 and 5 are listed in the Figure 1, along with the resulting signature size, public key, and private key sizes in bytes. Note that these are the sizes of the plain private and public keys; and not the sizes of the resultant OneAsymmetricKey and SubjectPublicKeyInfo objects in which they are wrapped. |=======+=======+=====+========+========+========| | Level | (k,l) | eta | Sig. | Public | Private| | | | | (B) | Key(B) | Key(B) | |=======+=======+=====+========+========+========| | 2 | (4,4) | 2 | 2420 | 1312 | 32 | | 3 | (6,5) | 4 | 3309 | 1952 | 32 | | 5 | (8,7) | 2 | 4627 | 2592 | 32 | |=======+=======+=====+========+========+========| Figure 1: ML-DSA Parameters Appendix C. Examples This appendix contains examples of ML-DSA public keys, private keys and certificates. C.1. Example Private Key The following is an example of a ML-DSA-44 private key with hex seed 000102…1e1f: -----BEGIN PRIVATE KEY----- MDICAQAwCwYJYIZIAWUDBAMRBCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRob HB0eHw== -----END PRIVATE KEY----- SEQUENCE { INTEGER { 0 } SEQUENCE { OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 } } OCTET_STRING { `000102030405060708090a0b0c0d0e0f10111213141516 1718191a1b1c1d1e1f` } } The following is an example of a ML-DSA-65 private key with hex seed 000102…1e1f: -----BEGIN PRIVATE KEY----- MDICAQAwCwYJYIZIAWUDBAMSBCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRob HB0eHw== -----END PRIVATE KEY----- SEQUENCE { INTEGER { 0 } SEQUENCE { OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 } } OCTET_STRING { `000102030405060708090a0b0c0d0e0f10111213141516 1718191a1b1c1d1e1f` } } The following is an example of a ML-DSA-87 private key with hex seed 000102…1e1f: -----BEGIN PRIVATE KEY----- MDICAQAwCwYJYIZIAWUDBAMTBCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRob HB0eHw== -----END PRIVATE KEY----- SEQUENCE { INTEGER { 0 } SEQUENCE { OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 } } OCTET_STRING { `000102030405060708090a0b0c0d0e0f10111213141516 1718191a1b1c1d1e1f` } } NOTE: The private key is the seed and all three examples keys use the same seed; therefore, the private above are the same except for the OID used to represent the ML-DSA algorithm's security strength. C.2. Example Public Key The following is the ML-DSA-44 public key corresponding to the private key in the previous section. -----BEGIN PUBLIC KEY----- MIIFMjALBglghkgBZQMEAxEDggUhANeytHJUquDbReeTDUqY0sl9jxOX0Xidr6Fw JLMW6b7JT8mUbULxm3mnQTu6oz5xSctC7VEVaTrAQfrLmIretf4OHYYxGEmVtZLD l9IpTi4U+QqkFLo4JomaxD9MzKy8JumoMrlRGNXLQzy++WYLABOOCBf2HnYsonTD atVU6yKqwRYuSrAay6HjjE79j4C2WzM9D3LlXf5xzpweu5iJ58VhBsD9c4A6Kuz+ r97XqjyyztpU0SvYzTanjPl1lDtHq9JeiArEUuV0LtHo0agq+oblkMdYwVrk0oQN kryhpQkPQElll/yn2LlRPxob2m6VCqqY3kZ1B9Sk9aTwWZIWWCw1cvYu2okFqzWB ZwxKAnd6M+DKcpX9j0/20aCjp2g9ZfX19/xg2gI+gmxfkhRMAvfRuhB1mHVT6pNn /NdtmQt/qZzUWv24g21D5Fn1GH3wWEeXCaAepoNZNfpwRgmQzT3BukAbqUurHd5B rGerMxncrKBgSNTE7vJ+4TqcF9BTj0MPLWQtwkFWYN54h32NirxyUjl4wELkKF9D GYRsRBJiQpdoRMEOVWuiFbWnGeWdDGsqltOYWQcf3MLN51JKe+2uVOhbMY6FTo/i svPt+slxkSgnCq/R5QRMOk/a/Z/zH5B4S46ORZYUSg2vWGUR09mWK56pWvGXtOX8 YPKx7RXeOlvvX4m9x52RBR2bKBbnT6VFMe/cHL501EiFf0drzVjyHAtlOzt2pOB2 plWaMCcYVVzGP3SFmqurkl8COGHKjND3utsocfZ9VTJtdFETWtRfShumkRj7ssij DuyTku8/l3Bmya3VxxDMZHsVFNIX2VjHAXw+kP0gwE5nS5BIbpNwoxoAHTL0c5ee SQZ0nn5Hf6C3RQj4pfI3gxK4PCW9OIygsP/3R4uvQrcWZ+2qyXxGsSlkPlhuWwVa DCEZRtTzbmdb7Vhg+gQqMV2YJhZNapI3w1pfv0lUkKW9TfJIuVxKrneEtgVnMWas QkW1tLCCoJ6TI+YvIHjFt2eDRG3v1zatOjcC1JsImESQCmGDM5e8RBmzDXqXoLOH wZEUdMTUG1PjKpd6y28Op122W7OeWecB52lX3vby1EVZwxp3EitSBOO1whnxaIsU 7QvAuAGz5ugtzUPpwOn0F0TNmBW9G8iCDYuxI/BPrNGxtoXdWisbjbvz7ZM2cPCV oYC08ZLQixC4+rvfzCskUY4y7qCl4MkEyoRHgAg/OwzS0Li2r2e8NVuUlAJdx7Cn j6gOOi2/61EyiFHWB4GY6Uk2Ua54fsAlH5Irow6fUd9iptcnhM890gU5MXbfoySl Er2Ulwo23TSlFKhnkfDrNvAUWwmrZGUbSgMTsplhGiocSIkWJ1mHaKMRQGC6RENI bfUVIqHOiLMJhcIW+ObtF43VZ7MEoNTK+6iCooNC8XqaomrljbYwCD0sNY/fVmw/ XWKkKFZ7yeqM6VyqDzVHSwv6jzOaJQq0388gg76O77wQVeGP4VNw7ssmBWbYP/Br IRquxDyim1TM0A+IFaJGXvC0ZRXMfkHzEk8J7/9zkwmrWLKaFFmgC85QOOk4yWeP cusOTuX9quZtn4Vz/Jf8QrSVn0v4th14Qz6GsDNdbpGRxNi/SHs5BcEIz9asJLDO t9y3z1H4TQ7Wh7lerrHFM8BvDZcCPZKnCCWDe1m6bLfU5WsKh8IDhiro8xW6WSXo 7e+meTaaIgJ2YVHxapZfn4Hs52zAcLVYaeTbl4TPBcgwsyQsgxI= -----END PUBLIC KEY----- SEQUENCE { SEQUENCE { OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 } } BIT_STRING { `00` `d7b2b47254aae0db45e7930d4a98d2c97d8f1397d17 89dafa17024b316e9bec94fc9946d42f19b79a7413bbaa33e7149cb42ed51156 93ac041facb988adeb5fe0e1d8631184995b592c397d2294e2e14f90aa414ba3 826899ac43f4cccacbc26e9a832b95118d5cb433cbef9660b00138e0817f61e7 62ca274c36ad554eb22aac1162e4ab01acba1e38c4efd8f80b65b333d0f72e55 dfe71ce9c1ebb9889e7c56106c0fd73803a2aecfeafded7aa3cb2ceda54d12bd 8cd36a78cf975943b47abd25e880ac452e5742ed1e8d1a82afa86e590c758c15 ae4d2840d92bca1a5090f40496597fca7d8b9513f1a1bda6e950aaa98de46750 7d4a4f5a4f0599216582c3572f62eda8905ab3581670c4a02777a33e0ca7295f d8f4ff6d1a0a3a7683d65f5f5f7fc60da023e826c5f92144c02f7d1ba1075987 553ea9367fcd76d990b7fa99cd45afdb8836d43e459f5187df058479709a01ea 6835935fa70460990cd3dc1ba401ba94bab1dde41ac67ab3319dcaca06048d4c 4eef27ee13a9c17d0538f430f2d642dc2415660de78877d8d8abc72523978c04 2e4285f4319846c44126242976844c10e556ba215b5a719e59d0c6b2a96d3985 9071fdcc2cde7524a7bedae54e85b318e854e8fe2b2f3edfac9719128270aafd 1e5044c3a4fdafd9ff31f90784b8e8e4596144a0daf586511d3d9962b9ea95af 197b4e5fc60f2b1ed15de3a5bef5f89bdc79d91051d9b2816e74fa54531efdc1 cbe74d448857f476bcd58f21c0b653b3b76a4e076a6559a302718555cc63f748 59aabab925f023861ca8cd0f7badb2871f67d55326d7451135ad45f4a1ba6911 8fbb2c8a30eec9392ef3f977066c9add5c710cc647b1514d217d958c7017c3e9 0fd20c04e674b90486e9370a31a001d32f473979e4906749e7e477fa0b74508f 8a5f2378312b83c25bd388ca0b0fff7478baf42b71667edaac97c46b129643e5 86e5b055a0c211946d4f36e675bed5860fa042a315d9826164d6a9237c35a5fb f495490a5bd4df248b95c4aae7784b605673166ac4245b5b4b082a09e9323e62 f2078c5b76783446defd736ad3a3702d49b089844900a61833397bc4419b30d7 a97a0b387c1911474c4d41b53e32a977acb6f0ea75db65bb39e59e701e76957d ef6f2d44559c31a77122b5204e3b5c219f1688b14ed0bc0b801b3e6e82dcd43e 9c0e9f41744cd9815bd1bc8820d8bb123f04facd1b1b685dd5a2b1b8dbbf3ed9 33670f095a180b4f192d08b10b8fabbdfcc2b24518e32eea0a5e0c904ca84478 0083f3b0cd2d0b8b6af67bc355b9494025dc7b0a78fa80e3a2dbfeb51328851d 6078198e9493651ae787ec0251f922ba30e9f51df62a6d72784cf3dd20539317 6dfa324a512bd94970a36dd34a514a86791f0eb36f0145b09ab64651b4a0313b 299611a2a1c48891627598768a3114060ba4443486df51522a1ce88b30985c21 6f8e6ed178dd567b304a0d4cafba882a28342f17a9aa26ae58db630083d2c358 fdf566c3f5d62a428567bc9ea8ce95caa0f35474b0bfa8f339a250ab4dfcf208 3be8eefbc1055e18fe15370eecb260566d83ff06b211aaec43ca29b54ccd00f8 815a2465ef0b46515cc7e41f3124f09efff739309ab58b29a1459a00bce5038e 938c9678f72eb0e4ee5fdaae66d9f8573fc97fc42b4959f4bf8b61d78433e86b 0335d6e9191c4d8bf487b3905c108cfd6ac24b0ceb7dcb7cf51f84d0ed687b95 eaeb1c533c06f0d97023d92a70825837b59ba6cb7d4e56b0a87c203862ae8f31 5ba5925e8edefa679369a2202766151f16a965f9f81ece76cc070b55869e4db9 784cf05c830b3242c8312` } } The following is the ML-DSA-65 public key corresponding to the private key in the previous section. -----BEGIN PUBLIC KEY----- MIIHsjALBglghkgBZQMEAxIDggehAEhoPZGXjjHrPd24sEc0gtK4il9iWUn9j1il YeaWvUwn0Fs427Lt8B5mTv2Bvh6ok2iM5oqi1RxZWPi7xutOie5n0sAyCVTVchLK xyKf8dbq8DkovVFRH42I2EdzbH3icw1ZeOVBBxMWCXiGdxG/VTmgv8TDUMK+Vyuv DuLi+xbM/qCAKNmaxJrrt1k33c4RHNq2L/886ouiIz0eVvvFxaHnJt5j+t0q8Bax GRd/o9lxotkncXP85VtndFrwt8IdWX2+uT5qMvNBxJpai+noJQiNHyqkUVXWyK4V Nn5OsAO4/feFEHGUlzn5//CQI+r0UQTSqEpFkG7tRnGkTcKNJ5h7tV32np6FYfYa gKcmmVA4Zf7Zt+5yqOF6GcQIFE9LKa/vcDHDpthXFhC0LJ9CEkWojxl+FoErAxFZ tluWh+Wz6TTFIlrpinm6c9Kzmdc1EO/60Z5TuEUPC6j84QEv2Y0mCnSqqhP64kmg BrHDT1uguILyY3giL7NvIoPCQ/D/618btBSgpw1V49QKVrbLyIrh8Dt7KILZje6i jhRcne39jq8c7y7ZSosFD4lk9G0eoNDCpD4N2mGCrb9PbtF1tnQiV4Wb8i86QX7P H52JMXteU51YevFrnhMT4EUU/6ZLqLP/K4Mh+IEcs/sCLI9kTnCkuAovv+5gSrtz eQkeqObFx038AoNma0DAeThwAoIEoTa/XalWjreY00kDi9sMEeA0ReeEfLUGnHXP KKxgHHeZ2VghDdvLIm5Rr++fHeR7Bzhz1tP5dFa+3ghQgudKKYss1I9LMJMVXzZs j6YBxq+FjfoywISRsqKYh/kDNZSaXW7apnmIKjqV1r9tlwoiH0udPYy/OEr4GqyV 4rMpTgR4msg3J6XcBFWflq9B2KBTUW/u7rxSdG62qygZ4JEIcQ2DXwEfpjBlhyrT NNXN/7KyMQUH6S/Jk64xfal/TzCc2vD2ftmdkCFVdgg4SflTskbX/ts/22dnmFCl rUBOZBR/t89Pau3dBa+0uDSWjR/ogBSWDc5dlCI2Um4SpHjWnl++aXAxCzCMBoRQ GM/HsqtDChOmsax7sCzMuz2RGsLxEGhhP74Cm/3OAs9c04lQ7XLIOUTt+8dWFa+H +GTAUfPFVFbFQShjpAwG0dq1Yr3/BXG408ORe70wCIC7pemYI5uV+pG31kFtTzmL OtvNMJg+01krTZ731CNv0A9Q2YqlOiNaxBcnIPd9lhcmcpgM/o/3pacCeD7cK6Mb IlkBWhEvx/RoqcL5RkA5AC0w72eLTLeYvBFiFr96mnwYugO3tY/QdRXTEVBJ02FL 56B+dEMAdQ3x0sWHUziQWer8PXhczdMcB2SL7cA6XDuK1G0GTVnBPVc3Ryn8TilT YuKlGRIEUwQovBUir6KP9f4WVeMEylvIwnrQ4MajndTfKJVsFLOMyTaCzv5AK71e gtKcRk5E6103tI/FaN/gzG6OFrrqBeUTVZDxkpTnPoNnsCFtu4FQMLneVZE/CAOc QjUcWeVRXdWvjgiaFeYl6Pbe5jk4bEZJfXomMoh3TeWBp96WKbQbRCQUH5ePuDMS CO/ew8bg3jm8VwY/Pc1sRwNzwIiR6inLx8xtZIO4iJCDrOhqp7UbHCz+birRjZfO NvvFbqQvrpfmp6wRSGRHjDZt8eux57EakJhQT9WXW98fSdxwACtjwXOanSY/utQH P2qfbCuK9LTDMqEDoM/6Xe6y0GLKPCFf02ACa+fFFk9KRCTvdJSIBNZvRkh3Msgg LHlUeGR7TqcdYnwIYCTMo1SkHwh3s48Zs3dK0glcjaU7Bp4hx2ri0gB+FnGe1ACA 0zT32lLp9aWZBDnK8IOpW4M/Aq0QoIwabQ8mDAByhb1KL0dwOlrvRlKH0lOxisIl FDFiEP9WaBSxD4eik9bxmdPDlZmQ0MEmi09Q1fn877vyN70MKLgBgtZll0HxTxC/ uyG7oSq2IKojlvVsBoa06pAXmQIkIWsv6K12xKkUju+ahqNjWmqne8Hc+2+6Wad9 /am3Uw3AyoZIyNlzc44Burjwi0kF6EqkZBvWAkEM2XUgJl8vIx8rNeFesvoE0r2U 1ad6uvHg4WEBCpkAh/W0bqmIsrwFEv2g+pI9rdbEXFMB0JSDZzJltasuEPS6Ug9r utVkpcPV4nvbCA99IOEylqMYGVTDnGSclD6+F99cH3quCo/hJsR3WFpdTWSKDQCL avXozTG+aakpbU8/0l7YbyIeS5P2X1kplnUzYkuSNXUMMHB1ULWFNtEJpxMcWlu+ SlcVVnwSU0rsdmB2Huu5+uKJHHdFibgOVmrVV93vc2cZa3In6phw7wnd/seda5MZ poebUgXXa/erpazzOvtZ0X/FTmg4PWvloI6bZtpT3N4Ai7KUuFgr0TLNzEmVn9vC HlJyGIDIrQNSx58DpDu9hMTN/cbFKQBeHnzZo0mnFoo1Vpul3qgYlo1akUZr1uZO IL9iQXGYr8ToHCjdd+1AKCMjmLUvvehryE9HW5AWcQziqrwRoGtNuskB7BbPNlyj 8tU4E5SKaToPk+ecRspdWm3KPSjKUK0YvRP8pVBZ3ZsYX3n5xHGWpOgbIQS8RgoF HgLy6ERP -----END PUBLIC KEY----- SEQUENCE { SEQUENCE { OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.18 } } BIT_STRING { `00` `48683d91978e31eb3dddb8b0473482d2b88a5f62594 9fd8f58a561e696bd4c27d05b38dbb2edf01e664efd81be1ea893688ce68aa2d 51c5958f8bbc6eb4e89ee67d2c0320954d57212cac7229ff1d6eaf03928bd515 11f8d88d847736c7de2730d5978e5410713160978867711bf5539a0bfc4c350c 2be572baf0ee2e2fb16ccfea08028d99ac49aebb75937ddce111cdab62fff3ce a8ba2233d1e56fbc5c5a1e726de63fadd2af016b119177fa3d971a2d9277173f ce55b67745af0b7c21d597dbeb93e6a32f341c49a5a8be9e825088d1f2aa4515 5d6c8ae15367e4eb003b8fdf7851071949739f9fff09023eaf45104d2a84a459 06eed4671a44dc28d27987bb55df69e9e8561f61a80a72699503865fed9b7ee7 2a8e17a19c408144f4b29afef7031c3a6d8571610b42c9f421245a88f197e168 12b031159b65b9687e5b3e934c5225ae98a79ba73d2b399d73510effad19e53b 8450f0ba8fce1012fd98d260a74aaaa13fae249a006b1c34f5ba0b882f263782 22fb36f2283c243f0ffeb5f1bb414a0a70d55e3d40a56b6cbc88ae1f03b7b288 2d98deea28e145c9dedfd8eaf1cef2ed94a8b050f8964f46d1ea0d0c2a43e0dd a6182adbf4f6ed175b6742257859bf22f3a417ecf1f9d89317b5e539d587af16 b9e1313e04514ffa64ba8b3ff2b8321f8811cb3fb022c8f644e70a4b80a2fbfe e604abb7379091ea8e6c5c74dfc0283666b40c0793870028204a136bf5da9568 eb798d349038bdb0c11e03445e7847cb5069c75cf28ac601c7799d958210ddbc b226e51afef9f1de47b073873d6d3f97456bede085082e74a298b2cd48f4b309 3155f366c8fa601c6af858dfa32c08491b2a29887f90335949a5d6edaa679882 a3a95d6bf6d970a221f4b9d3d8cbf384af81aac95e2b3294e04789ac83727a5d c04559f96af41d8a053516feeeebc52746eb6ab2819e09108710d835f011fa63 065872ad334d5cdffb2b2310507e92fc993ae317da97f4f309cdaf0f67ed99d9 0215576083849f953b246d7fedb3fdb67679850a5ad404e64147fb7cf4f6aedd d05afb4b834968d1fe88014960dce5d942236526e12a478d69e5fbe6970310b3 08c06845018cfc7b2ab430a13a6b1ac7bb02cccbb3d911ac2f11068613fbe029 bfdce02cf5cd38950ed72c83944edfbc75615af87f864c051f3c55456c541286 3a40c06d1dab562bdff0571b8d3c3917bbd300880bba5e998239b95fa91b7d64 16d4f398b3adbcd30983ed3592b4d9ef7d4236fd00f50d98aa53a235ac417272 0f77d96172672980cfe8ff7a5a702783edc2ba31b2259015a112fc7f468a9c2f 9464039002d30ef678b4cb798bc116216bf7a9a7c18ba03b7b58fd07515d3115 049d3614be7a07e744300750df1d2c58753389059eafc3d785ccdd31c07648be dc03a5c3b8ad46d064d59c13d57374729fc4e295362e2a5191204530428bc152 2afa28ff5fe1655e304ca5bc8c27ad0e0c6a39dd4df28956c14b38cc93682cef e402bbd5e82d29c464e44eb5d37b48fc568dfe0cc6e8e16baea05e5135590f19 294e73e8367b0216dbb815030b9de55913f08039c42351c59e5515dd5af8e089 a15e625e8f6dee639386c46497d7a263288774de581a7de9629b41b4424141f9 78fb8331208efdec3c6e0de39bc57063f3dcd6c470373c08891ea29cbc7cc6d6 483b8889083ace86aa7b51b1c2cfe6e2ad18d97ce36fbc56ea42fae97e6a7ac1 14864478c366df1ebb1e7b11a9098504fd5975bdf1f49dc70002b63c1739a9d2 63fbad4073f6a9f6c2b8af4b4c332a103a0cffa5deeb2d062ca3c215fd360026 be7c5164f4a4424ef74948804d66f46487732c8202c795478647b4ea71d627c0 86024cca354a41f0877b38f19b3774ad2095c8da53b069e21c76ae2d2007e167 19ed40080d334f7da52e9f5a5990439caf083a95b833f02ad10a08c1a6d0f260 c007285bd4a2f47703a5aef465287d253b18ac22514316210ff566814b10f87a 293d6f199d3c3959990d0c1268b4f50d5f9fcefbbf237bd0c28b80182d665974 1f14f10bfbb21bba12ab620aa2396f56c0686b4ea9017990224216b2fe8ad76c 4a9148eef9a86a3635a6aa77bc1dcfb6fba59a77dfda9b7530dc0ca8648c8d97 3738e01bab8f08b4905e84aa4641bd602410cd97520265f2f231f2b35e15eb2f a04d2bd94d5a77abaf1e0e161010a990087f5b46ea988b2bc0512fda0fa923da dd6c45c5301d09483673265b5ab2e10f4ba520f6bbad564a5c3d5e27bdb080f7 d20e13296a3181954c39c649c943ebe17df5c1f7aae0a8fe126c477585a5d4d6 48a0d008b6af5e8cd31be69a9296d4f3fd25ed86f221e4b93f65f59299675336 24b9235750c30707550b58536d109a7131c5a5bbe4a5715567c12534aec76607 61eebb9fae2891c774589b80e566ad557ddef7367196b7227ea9870ef09ddfec 79d6b9319a6879b5205d76bf7aba5acf33afb59d17fc54e68383d6be5a08e9b6 6da53dcde008bb294b8582bd132cdcc49959fdbc21e52721880c8ad0352c79f0 3a43bbd84c4cdfdc6c529005e1e7cd9a349a7168a35569ba5dea818968d5a914 66bd6e64e20bf62417198afc4e81c28dd77ed4028232398b52fbde86bc84f475 b9016710ce2aabc11a06b4dbac901ec16cf365ca3f2d53813948a693a0f93e79 c46ca5d5a6dca3d28ca50ad18bd13fca55059dd9b185f79f9c47196a4e81b210 4bc460a051e02f2e8444f` } } The following is the ML-DSA-87 public key corresponding to the private key in the previous section. -----BEGIN PUBLIC KEY----- MIIKMjALBglghkgBZQMEAxMDggohAJeSvOwvJDBoaoL8zzwvX/Zl53HXq0G5AljP p+kOyXEkpzsyO5uiGrZNdnxDP1pSHv/hj4bkahiJUsRGfgSLcp5/xNEV5+SNoYlt X+EZsQ3N3vYssweVQHS0IzblKDbeYdqUH4036misgQb6vhkHBnmvYAhTcSD3B5O4 6pzA5ue3tMmlx0IcYPJEUboekz2xou4Wx5VZ8hs9G4MFhQqkKvuxPx9NW59INfnY ffzrFi0O9Kf9xMuhdDzRyHu0ln2hbMh2S2Vp347lvcv/6aTgV0jm/fIlr55O63dz ti6Phfm1a1SJRVUYRPvYmAakrDab7S0lYQD2iKatXgpwmCbcREnpHiPFUG5kI2Hv WjE3EvebxLMYaGHKhaS6sX5/lD0bijM6o6584WtEDWAY+eBNr1clx/GpP60aWie2 eJW9JJqpFoXeIK8yyLfiaMf5aHfQyFABE1pPCo8bgmT6br5aNJ2K7K0aFimczy/Z x7hbrOLO06oSdrph7njtflyltnzdRYqTVAMOaru6v1agojFv7J26g7UdQv0xZ/Hg +QhV1cZlCbIQJl3B5U7ES0O6fPmu8Ri0TYCRLOdRZqZlHhFs6+SSKacGLAmTH3Gr 0ik/dvfvwyFbqXgAA35Y5HC9u7Q8GwQ56vecVNk7RKrJ7+n74VGHTPsqZMvuKMxM D+d3Xl2HDxwC5bLjxQBMmV8kybd5y3U6J30Ocf1CXra8LKVs4SnbUfcHQPMeY5dr UMcxLpeX14xbGsJKX6NHzJFuCoP1w7Z1zTC4Hj+hC5NETgc5dXHM6Yso2lHbkFa8 coxbCxGB4vvTh7THmrGl/v7ONxZ693LdrRTrTDmC2lpZ0OnrFz7GMVCRFwAno6te 9qoSnLhYVye5NYooUB1xOnLz8dsxcUKG+bZAgBOvBgRddVkvwLfdR8c+2cdbEenX xp98rfwygKkGLFJzxDvhw0+HRIhkzqe1yX1tMvWb1fJThGU7tcT6pFvqi4lAKEPm Rba5Jp4r2YjdrLAzMo/7BgRQ998IAFPmlpslHodezsMs/FkoQNaatpp14Gs3nFNd lSZrCC9PCckxYrM7DZ9zB6TqqlIQRDf+1m+O4+q71F1nslqBM/SWRotSuv/b+tk+ 7xqYGLXkLscieIo9jTUp/Hd9K6VwgB364B7IgwKDfB+54DVXJ2Re4QRsP5Ffaugt rU+2sDVqRlGP/INBVcO0/m2vpsyKXM9TxzoISdjUT33PcnVOcOG337RHu070nRpx j2Fxu84gCVDgzpJhBrFRo+hx1c5JcxvWZQqbDKly2hxfE21Egg6mODwI87OEzyM4 54nFE/YYzFaUpvDO4QRRHh7XxfI6Hr/YoNuEJFUyQBVtv2IoMbDGQ9HFUbbz96mN KbhcLeBaZfphXu4WSVvZBzdnIRW1PpHF2QAozz8ak5U6FT3lO0QITpzP9rc2aTkm 2u/rstd6pa1om5LzFoZmnfFtFxXMWPeiz7ct0aUekvglmTp0Aivn6etgVGVEVwlN FJKPICFeeyIqxWtRrb7I2L22mDl5p+OiG0S10VGMqX0LUZX1HtaiQ1DIl0fh7epR tEjj6RRwVM6SeHPJDbOU2GiI4H3/F3WT1veeFSMCIErrA74jhq8+JAeL0CixaJ9e FHyfRSyM6wLsWcydtjoDV2zur+mCOQI4l9oCNmMKU8Def0NaGYaXkvqzbnueY1dg 8JBp5kMucAA1rCoCh5//Ch4b7FIgRxk9lOtd8e/VPuoRRMp4lAhS9eyXJ5BLNm7e T14tMx+tX8KC6ixH6SMUJ3HD3XWoc1dIfe+Z5fGOnZ7WI8F10CiIxR+CwHqA1UcW s8PCvb4unwqbuq6+tNUpNodkBvXADo5LvQpewFeX5iB8WrbIjxpohCG9BaEU9Nfe KsJB+g6L7f9H92Ldy+qpEAT40x6FCVyBBUmUrTgm40S6lgQIEPwLKtHeSM+t4ALG LlpJoHMas4NEvBY23xa/YH1WhV5W1oQAPHGOS62eWgmZefzd7rHEp3ds03o0F8sO GE4p75vA6HR1umY74J4Aq1Yut8D3Fl+WmptCQUGYzPG/8qLI1omkFOznZiknZlaJ 6U25YeuuxWFcvBp4lcaFGslhQy/xEY1GB9Mu+dxzLVEzO+S00OMN3qeE7Ki+R+dB vpwZYx3EcKUu9NwTpPNjP9Q014fBcJd7QX31mOHQ3eUGu3HW8LwX7HDjsDzcGWXL Npk/YzsEcuUNCSOsbGb98dPmRZzBIfD1+U0J6dvPXWkOIyM4OKC6y3xjjRsmUKQw jNFxtoVRJtHaZypu2FqNeMKG+1b0qz0hSXUoBFxjJiyKQq8vmALFO3u4vijnj+C1 zkX7t6GvGjsoqNlLeJDjyILjm8mOnwrXYCW/DdLwApjnFBoiaz187kFPYE0eC6VN EdX+WLzOpq13rS6MHKrPMkWQFLe5EAGx76itFypSP7jjZbV3Ehv5/Yiixgwh6CHX tqy0elqZXkDKztXCI7j+beXhjp0uWJOu/rt6rn/xoUYmDi8RDpOVKCE6ACWjjsea q8hhsl68UJpGdMEyqqy34BRvFO/RHPyvTKpPd1pxbOMl4KQ1pNNJ1yC88TdFCvxF BG/Bofg6nTKXd6cITkqtrnEizpcAWTBSjrPH9/ESmzcoh6NxFVo7ogGiXL8dy2Tn ze4JLDFB+1VQ/j0N2C6HDleLK0ZQCBgRO49laXc8Z3OFtppCt33Lp6z/2V/URS4j qqHTfh2iFR6mWNQKNZayesn4Ep3GzwZDdyYktZ9PRhIw30ccomCHw5QtXGaH32CC g1k1o/h8t2Kww7HQ3aSmUzllvvG3uCkuJUwBTQkP7YV8RMGDnGlMCmTj+tkKEfU0 citu4VdPLhSdVddE3kiHAk4IURQxwGJ1DhbHSrnzJC8ts/+xKo1hB/qiKdb2NzsH 8205MrO9sEwZ3WTq3X+Tw8Vkw1ihyB3PHJwx5bBlaPl1RMF9wVaYxcs4mDqa/EJ4 P6p3OlLJ2CYGkL6eMVaqW8FQneo/aVh2lc1v8XK6g+am2KfWu+u7zaNnJzGYP4m8 WDHcN8PzxcVvrMaX88sgvV2629cC5UhErC9iaQH+FZ25Pf1Hc9j+c1YrhGwfyFbR gCdihA68cteYi951y8pw0xnTLODMAlO7KtRVcj7gx/RzbObmZlxayjKkgcU4Obwl kWewE9BCM5Xuuaqu4yBhSafVUNZ/xf3+SopcNdJRC2ZDeauPcoVaKvR6vOKmMgSO r4nly0qI3rxTpZUQOszk8c/xis/wev4etXFqoeQLYxNMOjrpV5+of1Fb4JPC0p22 1rZck2YeAGNrWScE0JPMZxbCNC6xhT1IyFxjrIooVEYse3fn470erFvKKP+qALXT SfilR62HW5aowrKRDJMBMJo/kTilaTER9Vs8AJypR8Od/ILZjrHKpKnL6IX3hvqG 5VvgYiIvi6kKl0BzMmsxISrs4KNKYA== -----END PUBLIC KEY----- SEQUENCE { SEQUENCE { OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.19 } } BIT_STRING { `00` `9792bcec2f2430686a82fccf3c2f5ff665e771d7ab4 1b90258cfa7e90ec97124a73b323b9ba21ab64d767c433f5a521effe18f86e46 a188952c4467e048b729e7fc4d115e7e48da1896d5fe119b10dcddef62cb3079 54074b42336e52836de61da941f8d37ea68ac8106fabe19070679af600853712 0f70793b8ea9cc0e6e7b7b4c9a5c7421c60f24451ba1e933db1a2ee16c79559f 21b3d1b8305850aa42afbb13f1f4d5b9f4835f9d87dfceb162d0ef4a7fdc4cba 1743cd1c87bb4967da16cc8764b6569df8ee5bdcbffe9a4e05748e6fdf225af9 e4eeb7773b62e8f85f9b56b548945551844fbd89806a4ac369bed2d256100f68 8a6ad5e0a709826dc4449e91e23c5506e642361ef5a313712f79bc4b3186861c a85a4bab17e7f943d1b8a333aa3ae7ce16b440d6018f9e04daf5725c7f1a93fa d1a5a27b67895bd249aa91685de20af32c8b7e268c7f96877d0c85001135a4f0 a8f1b8264fa6ebe5a349d8aecad1a16299ccf2fd9c7b85bace2ced3aa1276ba6 1ee78ed7e5ca5b67cdd458a9354030e6abbbabf56a0a2316fec9dba83b51d42f d3167f1e0f90855d5c66509b210265dc1e54ec44b43ba7cf9aef118b44d80912 ce75166a6651e116cebe49229a7062c09931f71abd2293f76f7efc3215ba9780 0037e58e470bdbbb43c1b0439eaf79c54d93b44aac9efe9fbe151874cfb2a64c bee28cc4c0fe7775e5d870f1c02e5b2e3c5004c995f24c9b779cb753a277d0e7 1fd425eb6bc2ca56ce129db51f70740f31e63976b50c7312e9797d78c5b1ac24 a5fa347cc916e0a83f5c3b675cd30b81e3fa10b93444e07397571cce98b28da5 1db9056bc728c5b0b1181e2fbd387b4c79ab1a5fefece37167af772ddad14eb4 c3982da5a59d0e9eb173ec6315091170027a3ab5ef6aa129cb8585727b9358a2 8501d713a72f3f1db31714286f9b6408013af06045d75592fc0b7dd47c73ed9c 75b11e9d7c69f7cadfc3280a9062c5273c43be1c34f87448864cea7b5c97d6d3 2f59bd5f25384653bb5c4faa45bea8b89402843e645b6b9269e2bd988ddacb03 3328ffb060450f7df080053e6969b251e875ecec32cfc592840d69ab69a75e06 b379c535d95266b082f4f09c93162b33b0d9f7307a4eaaa52104437fed66f8ee 3eabbd45d67b25a8133f496468b52baffdbfad93eef1a9818b5e42ec722788a3 d8d3529fc777d2ba570801dfae01ec88302837c1fb9e0355727645ee1046c3f9 15f6ae82dad4fb6b0356a46518ffc834155c3b4fe6dafa6cc8a5ccf53c73a084 9d8d44f7dcf72754e70e1b7dfb447bb4ef49d1a718f6171bbce200950e0ce926 106b151a3e871d5ce49731bd6650a9b0ca972da1c5f136d44820ea6383c08f3b 384cf2338e789c513f618cc5694a6f0cee104511e1ed7c5f23a1ebfd8a0db842 4553240156dbf622831b0c643d1c551b6f3f7a98d29b85c2de05a65fa615eee1 6495bd90737672115b53e91c5d90028cf3f1a93953a153de53b44084e9ccff6b 736693926daefebb2d77aa5ad689b92f31686669df16d1715cc58f7a2cfb72dd 1a51e92f825993a74022be7e9eb6054654457094d14928f20215e7b222ac56b5 1adbec8d8bdb6983979a7e3a21b44b5d1518ca97d0b5195f51ed6a24350c8974 7e1edea51b448e3e9147054ce927873c90db394d86888e07dff177593d6f79e1 52302204aeb03be2386af3e24078bd028b1689f5e147c9f452c8ceb02ec59cc9 db63a03576ceeafe98239023897da0236630a53c0de7f435a19869792fab36e7 b9e635760f09069e6432e700035ac2a02879fff0a1e1bec522047193d94eb5df 1efd53eea1144ca78940852f5ec9727904b366ede4f5e2d331fad5fc282ea2c4 7e923142771c3dd75a87357487def99e5f18e9d9ed623c175d02888c51f82c07 a80d54716b3c3c2bdbe2e9f0a9bbaaebeb4d52936876406f5c00e8e4bbd0a5ec 05797e6207c5ab6c88f1a688421bd05a114f4d7de2ac241fa0e8bedff47f762d dcbeaa91004f8d31e85095c81054994ad3826e344ba96040810fc0b2ad1de48c fade002c62e5a49a0731ab38344bc1636df16bf607d56855e56d684003c718e4 bad9e5a099979fcddeeb1c4a7776cd37a3417cb0e184e29ef9bc0e87475ba663 be09e00ab562eb7c0f7165f969a9b42414198ccf1bff2a2c8d689a414ece7662 927665689e94db961ebaec5615cbc1a7895c6851ac961432ff1118d4607d32ef 9dc732d51333be4b4d0e30ddea784eca8be47e741be9c19631dc470a52ef4dc1 3a4f3633fd434d787c170977b417df598e1d0dde506bb71d6f0bc17ec70e3b03 cdc1965cb36993f633b0472e50d0923ac6c66fdf1d3e6459cc121f0f5f94d09e 9dbcf5d690e23233838a0bacb7c638d1b2650a4308cd171b6855126d1da672a6 ed85a8d78c286fb56f4ab3d21497528045c63262c8a42af2f9802c53b7bb8be2 8e78fe0b5ce45fbb7a1af1a3b28a8d94b7890e3c882e39bc98e9f0ad76025bf0 dd2f00298e7141a226b3d7cee414f604d1e0ba54d11d5fe58bccea6ad77ad2e8 c1caacf32459014b7b91001b1efa8ad172a523fb8e365b577121bf9fd88a2c60 c21e821d7b6acb47a5a995e40caced5c223b8fe6de5e18e9d2e5893aefebb7aa e7ff1a146260e2f110e939528213a0025a38ec79aabc861b25ebc509a4674c13 2aaacb7e0146f14efd11cfcaf4caa4f775a716ce325e0a435a4d349d720bcf13 7450afc45046fc1a1f83a9d329777a7084e4aadae7122ce97005930528eb3c7f 7f1129b372887a371155a3ba201a25cbf1dcb64e7cdee092c3141fb5550fe3d0 dd82e870e578b2b46500818113b8f6569773c677385b69a42b77dcba7acffd95 fd4452e23aaa1d37e1da2151ea658d40a3596b27ac9f8129dc6cf0643772624b 59f4f461230df471ca26087c3942d5c6687df6082835935a3f87cb762b0c3b1d 0dda4a6533965bef1b7b8292e254c014d090fed857c44c1839c694c0a64e3fad 90a11f534722b6ee1574f2e149d55d744de4887024e08511431c062750e16c74 ab9f3242f2db3ffb12a8d6107faa229d6f6373b07f36d3932b3bdb04c19dd64e add7f93c3c564c358a1c81dcf1c9c31e5b06568f97544c17dc15698c5cb38983 a9afc42783faa773a52c9d8260690be9e3156aa5bc1509dea3f69587695cd6ff 172ba83e6a6d8a7d6bbebbbcda3672731983f89bc5831dc37c3f3c5c56facc69 7f3cb20bd5dbadbd702e54844ac2f626901fe159db93dfd4773d8fe73562b846 c1fc856d1802762840ebc72d7988bde75cbca70d319d32ce0cc0253bb2ad4557 23ee0c7f4736ce6e6665c5aca32a481c53839bc259167b013d0423395eeb9aaa ee3206149a7d550d67fc5fdfe4a8a5c35d2510b664379ab8f72855a2af47abce 2a632048eaf89e5cb4a88debc53a595103acce4f1cff18acff07afe1eb5716aa 1e40b63134c3a3ae9579fa87f515be093c2d29db6d6b65c93661e00636b59270 4d093cc6716c2342eb1853d48c85c63ac8a2854462c7b77e7e3bd1eac5bca28f faa00b5d349f8a547ad875b96a8c2b2910c9301309a3f9138a5693111f55b3c0 09ca947c39dfc82d98eb1caa4a9cbe885f786fa86e55be062222f8ba90a97407 3326b31212aece0a34a60` } } C.3. Example Certificate The following is a self-signed certificate for the ML-DSA-44 public key in the previous section. -----BEGIN CERTIFICATE----- MIIPlDCCBgqgAwIBAgIUFZ/+byL9XMQsUk32/V4o0N44804wCwYJYIZIAWUDBAMR MCIxDTALBgNVBAoTBElFVEYxETAPBgNVBAMTCExBTVBTIFdHMB4XDTIwMDIwMzA0 MzIxMFoXDTQwMDEyOTA0MzIxMFowIjENMAsGA1UEChMESUVURjERMA8GA1UEAxMI TEFNUFMgV0cwggUyMAsGCWCGSAFlAwQDEQOCBSEA17K0clSq4NtF55MNSpjSyX2P E5fReJ2voXAksxbpvslPyZRtQvGbeadBO7qjPnFJy0LtURVpOsBB+suYit61/g4d hjEYSZW1ksOX0ilOLhT5CqQUujgmiZrEP0zMrLwm6agyuVEY1ctDPL75ZgsAE44I F/YediyidMNq1VTrIqrBFi5KsBrLoeOMTv2PgLZbMz0PcuVd/nHOnB67mInnxWEG wP1zgDoq7P6v3teqPLLO2lTRK9jNNqeM+XWUO0er0l6ICsRS5XQu0ejRqCr6huWQ x1jBWuTShA2SvKGlCQ9ASWWX/KfYuVE/GhvabpUKqpjeRnUH1KT1pPBZkhZYLDVy 9i7aiQWrNYFnDEoCd3oz4Mpylf2PT/bRoKOnaD1l9fX3/GDaAj6CbF+SFEwC99G6 EHWYdVPqk2f8122ZC3+pnNRa/biDbUPkWfUYffBYR5cJoB6mg1k1+nBGCZDNPcG6 QBupS6sd3kGsZ6szGdysoGBI1MTu8n7hOpwX0FOPQw8tZC3CQVZg3niHfY2KvHJS OXjAQuQoX0MZhGxEEmJCl2hEwQ5Va6IVtacZ5Z0MayqW05hZBx/cws3nUkp77a5U 6FsxjoVOj+Ky8+36yXGRKCcKr9HlBEw6T9r9n/MfkHhLjo5FlhRKDa9YZRHT2ZYr nqla8Ze05fxg8rHtFd46W+9fib3HnZEFHZsoFudPpUUx79wcvnTUSIV/R2vNWPIc C2U7O3ak4HamVZowJxhVXMY/dIWaq6uSXwI4YcqM0Pe62yhx9n1VMm10URNa1F9K G6aRGPuyyKMO7JOS7z+XcGbJrdXHEMxkexUU0hfZWMcBfD6Q/SDATmdLkEhuk3Cj GgAdMvRzl55JBnSefkd/oLdFCPil8jeDErg8Jb04jKCw//dHi69CtxZn7arJfEax KWQ+WG5bBVoMIRlG1PNuZ1vtWGD6BCoxXZgmFk1qkjfDWl+/SVSQpb1N8ki5XEqu d4S2BWcxZqxCRbW0sIKgnpMj5i8geMW3Z4NEbe/XNq06NwLUmwiYRJAKYYMzl7xE GbMNepegs4fBkRR0xNQbU+Mql3rLbw6nXbZbs55Z5wHnaVfe9vLURVnDGncSK1IE 47XCGfFoixTtC8C4AbPm6C3NQ+nA6fQXRM2YFb0byIINi7Ej8E+s0bG2hd1aKxuN u/PtkzZw8JWhgLTxktCLELj6u9/MKyRRjjLuoKXgyQTKhEeACD87DNLQuLavZ7w1 W5SUAl3HsKePqA46Lb/rUTKIUdYHgZjpSTZRrnh+wCUfkiujDp9R32Km1yeEzz3S BTkxdt+jJKUSvZSXCjbdNKUUqGeR8Os28BRbCatkZRtKAxOymWEaKhxIiRYnWYdo oxFAYLpEQ0ht9RUioc6IswmFwhb45u0XjdVnswSg1Mr7qIKig0LxepqiauWNtjAI PSw1j99WbD9dYqQoVnvJ6ozpXKoPNUdLC/qPM5olCrTfzyCDvo7vvBBV4Y/hU3Du yyYFZtg/8GshGq7EPKKbVMzQD4gVokZe8LRlFcx+QfMSTwnv/3OTCatYspoUWaAL zlA46TjJZ49y6w5O5f2q5m2fhXP8l/xCtJWfS/i2HXhDPoawM11ukZHE2L9IezkF wQjP1qwksM633LfPUfhNDtaHuV6uscUzwG8NlwI9kqcIJYN7Wbpst9TlawqHwgOG KujzFbpZJejt76Z5NpoiAnZhUfFqll+fgeznbMBwtVhp5NuXhM8FyDCzJCyDEqNC MEAwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFDKa B7H6u0j1KjCfEaGJj4SOIyL/MAsGCWCGSAFlAwQDEQOCCXUAZ6iVH8MI4S9oZ2Ef 3CVL9Ly1FPf18v3rcvqOGgMAYWd7hM0nVZfYMVQZWWaxQWcMsOiBE0YNl4oaejiV wRykGZV3XAnWTd60e8h8TovxyTJ/xK/Vw3hlU+F9YpsPJxQnZUgUMrXnzNC6YeUc rT3Y+Vk4wjXr7O6vixauM2bzAMU1jse+nrI6HqGj2lhoZwTwSD+Wim5LH4lnCgE0 s2oY1scn3JsCexJ5R5OkjHq2bt9XrBgRORTADQoRtlplL0d3Eze/dDZm/Klby9OR Ia4HUL7FWtWoy86Y5TiuUjlH1pKZdjMPyj/JXAHRQDtJ5cuoGBL0NlDdATEJNCee zQfMqzTCyjCn091QkuFjDhQjzJ+sQ6G02w49lw8Kpm1ASuh7BLTPcuz7Z+rLpNjN jmW67rR6+hHMK474mSKIZnuO3vVKnidntjLhSYc1soxvYPCLWWnl4m3XyjlrnlzD 4Soec2I2AjKNZKCO9KKa81cRzIcNJjc7sbnrLv/hKXNUTESn4s3yAyRPU7N6bVIy N9ifBvb1U07WMRPI8A7/f9zVCaLYx87ym9P7GGpMjDYrPUQpOaKQdu4ycWuPrlEA 2BoHIVzbHHm9373BT1LjcxjR5SbbhNFg+42hwG284VlVzcLW/XiipaWN8jnONmxt kLMui9R/wf0TCehilMDDtRznfm37b2ci5o9MP/LrTDRpMVBudDuwIZmLgPQ/bj08 n+VHd8D2WADpR/kEMpDhSwG2P44mwwE4CUKGbHS0qQLOSRwMlQVEzwxpOOrLMusw JmzoLE0KNsUR6o/3xAlUmjqCZMqYPYxtXgNfJEJDp3V1iqyZK1iES3EQ0/h8m7oZ 3YqNKrEpTgVV7EmVpUjcVszjWgXcSKynVVsWQd3j0Zf83zXRLwmq8+anJ3XNGCSa IecO2sZxDbaiHhwFYRkt0BGRM2QM//IPMYeXhRa/1svmbOEHGxJG9LqTffkBs+01 Bp7r3/9lRZ+5t3eukpinpJrCT0AgeV3l3ujbzyCiQbboFDaPS4+kKvi+iS2eHjiu S/WkfP1Go5jksxhkceJFNPsTmGCyXGPy2/haU9hkiMg9/wmuIKm/gxRfIBh/DoIr 1HWZjTuWcBGWTu2NuXeAVO/MbMtpB0u6mWYktHQcVxA2LenU+N5LEPbbHp+AmPQC RZPqBziTyx/nuVnFD+/EAbPKzeqMKhcTW6nfkKt/Md4zmi1vhWxx7c+wDlo9cyAf vsS0p5uXKK1wzaC4mBIVdPYNlZtAjBCK8asKpH3/NyYJ8xhsBjxXLLiQifKiGOpA LLBy/LyJWmo4R4zkAtUILD4FcsIyLMIJlsqWjaNdey7bwGI75hZQkBIF8QJxFVtT n4HQBtuNe2ek7e72d+bayceJvlUAFXTu6oeX9/UuS7AhuY4giNzI1pNOgNwWXRxx REmwvPrzJatZZ7cwfsKTezSSQlv2O4q70+2X2h0VtUg/pkz3GknE07S3ggDR9Qkg bywQS/42luPIADbbAKXhHaBaX/TaD/uZVn+BOZ5sqWmxEbbHtvzlSea02J1Fk4Hq kWbpuzByCJ25SuDRr+Xyn84ZDnetumQ0lBkc2ro+rZKXw8YGMyt0aX8ZwJxL4qNB /WFFEproVsOru8G7iwXgt4QP8WRBSp2kTlQUbNTF3gxOTsslkUErTnvcRQ0GpK06 DRQG8wbjgewpHyw7O8Sfi34EjAzic0gwtIp501/MWmKpRUgAow9LPreiaLq2TBIQ DXEhUb9fEhY77QKeir8cpue3sShqcz9TLa5REJGqsP/8/URk7lZjiI+YWbRLp2U2 D//0NPEq8fxrzNtacZRxSdx2id/yTWumtj5swjFA4yk0tunadltDMgEYuKgR+Jw9 G3/yFTDnepHK41V6x8eE/4JjUAvIJWADDWxudO7oF/wsY0AnUuWe9DkW09g8IWhk NukDTdpsl08hCLF06qH3MSHJrdUAzs2GGLMCvtrXK2L3k70PcLqMXhbPSr7d1RGW gW0BlRfR4l+2LJ952SMv3xzuxgT43aX3FFVBxXk7nFrhWJWIpJpuYXRhTqASkzoZ KzsIRyW0ZbsaIsy0tgzzyhQvdoOoJn+2sKjcCzpfY6tgRD9sfucOm1sGet/cM5YP iJYei2qKMeYcvACWiI8GNGY37OzhlikbleO4xXnfJwEOYx66NjTHZqkz1/TiCBGU a7h+l/fnut6VfkxS1yZ2r5Gsdx7DUfNkEeKyzIMnYRA3zw3047lHqH714rV5VbE3 yYEQWvdtYlHMFM2z9DDta59RRATOemm7AA1fYsfodrV/QPJi5qPmvpHtCvfItbdL Fg88Zh1zV5nV+0doUTXFVR9poJRE9fASlfU5qCJ9Jx5ISfvIkGz1fmfqXhUN9fE7 C0Evl7IYQLguTXFznRvsXvnliwR9Ut/g85JtXUiku4F2ThCBMHBDbov6p128kP+2 7LBgShM4IG80clxon8sWh6y0RLUz1MTamEYZKCXAPZzJoWhbzdNns/QTsjNP8wlu vBRtdkb6w4Vrm6GO2BXY6pQUBPcoDuymAhfAF9TxRn860OQeMcT/NRsU9Z/8nRnz 3KbAuMTYsQ6qbjuLTDwfF9B4b4YUDQR22z8wlzCNLzgwFlGSI12xhf3ejRlwjGZJ J/11Up4pEegRS/c+Li2OUvQr9Jxi8XGIdEJZY1T8oVpzDJf3C29gpARWSDAXrFn0 lgZHnqFyebeC1uDW8r/wGtYmI2EC53+FlOF5AFcH+3LzObZzerqwror4UMOA+B5c QMU5vDv1LFcWLzvJHMXJfCHL5nVSukXCMawr+DbeKjrkseG0UX0gpUbQy0vHIH1K 2geD2xyl3TJ8jCaKOxb/Hu+KfkvtOCsh07TA+cnTV1WHR77svUcMErzHXWOFm8+U omIXALO1EiDbpu38gERRLkC84eMhRBQjKcdmlcBFsmilt3cfIofypuhMRiIFjIke 00y2GEdQVsZGA/LX1HILqD4dEFDDQI2LPvCG5qe28HTfWspzsqK94IRESzm+Vmdp IjNzkTyrPI06yMvxaHGajwUtLWCReJOG/uXhswbX7EviVYyqCR4vzDLDVXAulxo/ OsHaQhMX8xYOLXontx7SNCBlu/EEBww5QklKUldgd5igr7bDxsvZ6vHy/wcNIzY3 RUdidnuDkpSm1hIoLz4/SW2Tm6C2u9La5evu7xAfIy1ul8LE3/P0AAAAAAAAAAAA AAAAABcmOEM= -----END CERTIFICATE----- SEQUENCE { SEQUENCE { [0] { INTEGER { 2 } } INTEGER { `159ffe6f22fd5cc42c524df6fd5e28d0de38f34e` } SEQUENCE { OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 } } SEQUENCE { SET { SEQUENCE { # organizationName OBJECT_IDENTIFIER { 2.5.4.10 } PrintableString { "IETF" } } } SET { SEQUENCE { # commonName OBJECT_IDENTIFIER { 2.5.4.3 } PrintableString { "LAMPS WG" } } } } SEQUENCE { UTCTime { "200203043210Z" } UTCTime { "400129043210Z" } } SEQUENCE { SET { SEQUENCE { # organizationName OBJECT_IDENTIFIER { 2.5.4.10 } PrintableString { "IETF" } } } SET { SEQUENCE { # commonName OBJECT_IDENTIFIER { 2.5.4.3 } PrintableString { "LAMPS WG" } } } } SEQUENCE { SEQUENCE { OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 } } BIT_STRING { `00` `d7b2b47254aae0db45e7930d4a98d2c97d8f139 7d1789dafa17024b316e9bec94fc9946d42f19b79a7413bbaa33e7149cb42ed5 115693ac041facb988adeb5fe0e1d8631184995b592c397d2294e2e14f90aa41 4ba3826899ac43f4cccacbc26e9a832b95118d5cb433cbef9660b00138e0817f 61e762ca274c36ad554eb22aac1162e4ab01acba1e38c4efd8f80b65b333d0f7 2e55dfe71ce9c1ebb9889e7c56106c0fd73803a2aecfeafded7aa3cb2ceda54d 12bd8cd36a78cf975943b47abd25e880ac452e5742ed1e8d1a82afa86e590c75 8c15ae4d2840d92bca1a5090f40496597fca7d8b9513f1a1bda6e950aaa98de4 67507d4a4f5a4f0599216582c3572f62eda8905ab3581670c4a02777a33e0ca7 295fd8f4ff6d1a0a3a7683d65f5f5f7fc60da023e826c5f92144c02f7d1ba107 5987553ea9367fcd76d990b7fa99cd45afdb8836d43e459f5187df058479709a 01ea6835935fa70460990cd3dc1ba401ba94bab1dde41ac67ab3319dcaca0604 8d4c4eef27ee13a9c17d0538f430f2d642dc2415660de78877d8d8abc7252397 8c042e4285f4319846c44126242976844c10e556ba215b5a719e59d0c6b2a96d 39859071fdcc2cde7524a7bedae54e85b318e854e8fe2b2f3edfac9719128270 aafd1e5044c3a4fdafd9ff31f90784b8e8e4596144a0daf586511d3d9962b9ea 95af197b4e5fc60f2b1ed15de3a5bef5f89bdc79d91051d9b2816e74fa54531e fdc1cbe74d448857f476bcd58f21c0b653b3b76a4e076a6559a302718555cc63 f74859aabab925f023861ca8cd0f7badb2871f67d55326d7451135ad45f4a1ba 69118fbb2c8a30eec9392ef3f977066c9add5c710cc647b1514d217d958c7017 c3e90fd20c04e674b90486e9370a31a001d32f473979e4906749e7e477fa0b74 508f8a5f2378312b83c25bd388ca0b0fff7478baf42b71667edaac97c46b1296 43e586e5b055a0c211946d4f36e675bed5860fa042a315d9826164d6a9237c35 a5fbf495490a5bd4df248b95c4aae7784b605673166ac4245b5b4b082a09e932 3e62f2078c5b76783446defd736ad3a3702d49b089844900a61833397bc4419b 30d7a97a0b387c1911474c4d41b53e32a977acb6f0ea75db65bb39e59e701e76 957def6f2d44559c31a77122b5204e3b5c219f1688b14ed0bc0b801b3e6e82dc d43e9c0e9f41744cd9815bd1bc8820d8bb123f04facd1b1b685dd5a2b1b8dbbf 3ed933670f095a180b4f192d08b10b8fabbdfcc2b24518e32eea0a5e0c904ca8 44780083f3b0cd2d0b8b6af67bc355b9494025dc7b0a78fa80e3a2dbfeb51328 851d6078198e9493651ae787ec0251f922ba30e9f51df62a6d72784cf3dd2053 93176dfa324a512bd94970a36dd34a514a86791f0eb36f0145b09ab64651b4a0 313b299611a2a1c48891627598768a3114060ba4443486df51522a1ce88b3098 5c216f8e6ed178dd567b304a0d4cafba882a28342f17a9aa26ae58db630083d2 c358fdf566c3f5d62a428567bc9ea8ce95caa0f35474b0bfa8f339a250ab4dfc f2083be8eefbc1055e18fe15370eecb260566d83ff06b211aaec43ca29b54ccd 00f8815a2465ef0b46515cc7e41f3124f09efff739309ab58b29a1459a00bce5 038e938c9678f72eb0e4ee5fdaae66d9f8573fc97fc42b4959f4bf8b61d78433 e86b0335d6e9191c4d8bf487b3905c108cfd6ac24b0ceb7dcb7cf51f84d0ed68 7b95eaeb1c533c06f0d97023d92a70825837b59ba6cb7d4e56b0a87c203862ae 8f315ba5925e8edefa679369a2202766151f16a965f9f81ece76cc070b55869e 4db9784cf05c830b3242c8312` } } [3] { SEQUENCE { SEQUENCE { # keyUsage OBJECT_IDENTIFIER { 2.5.29.15 } BOOLEAN { TRUE } OCTET_STRING { BIT_STRING { b`1000011` } } } SEQUENCE { # basicConstraints OBJECT_IDENTIFIER { 2.5.29.19 } BOOLEAN { TRUE } OCTET_STRING { SEQUENCE { BOOLEAN { TRUE } } } } SEQUENCE { # subjectKeyIdentifier OBJECT_IDENTIFIER { 2.5.29.14 } OCTET_STRING { OCTET_STRING { `329a07b1fabb48f52a309f11a1898f848e23 22ff` } } } } } } SEQUENCE { OBJECT_IDENTIFIER { 2.16.840.1.101.3.4.3.17 } } BIT_STRING { `00` `67a8951fc308e12f6867611fdc254bf4bcb514f7f5f 2fdeb72fa8e1a030061677b84cd275597d83154195966b141670cb0e88113460 d978a1a7a3895c11ca41995775c09d64ddeb47bc87c4e8bf1c9327fc4afd5c37 86553e17d629b0f27142765481432b5e7ccd0ba61e51cad3dd8f95938c235ebe ceeaf8b16ae3366f300c5358ec7be9eb23a1ea1a3da58686704f0483f968a6e4 b1f89670a0134b36a18d6c727dc9b027b12794793a48c7ab66edf57ac1811391 4c00d0a11b65a652f47771337bf743666fca95bcbd39121ae0750bec55ad5a8c bce98e538ae523947d6929976330fca3fc95c01d1403b49e5cba81812f43650d d01310934279ecd07ccab34c2ca30a7d3dd5092e1630e1423cc9fac43a1b4db0 e3d970f0aa66d404ae87b04b4cf72ecfb67eacba4d8cd8e65baeeb47afa11cc2 b8ef8992288667b8edef54a9e2767b632e1498735b28c6f60f08b5969e5e26dd 7ca396b9e5cc3e12a1e73623602328d64a08ef4a29af35711cc870d26373bb1b 9eb2effe12973544c44a7e2cdf203244f53b37a6d523237d89f06f6f5534ed63 113c8f00eff7fdcd509a2d8c7cef29bd3fb186a4c8c362b3d442939a29076ee3 2716b8fae5100d81a07215cdb1c79bddfbdc14f52e37318d1e526db84d160fb8 da1c06dbce15955cdc2d6fd78a2a5a58df239ce366c6d90b32e8bd47fc1fd130 9e86294c0c3b51ce77e6dfb6f6722e68f4c3ff2eb4c346931506e743bb021998 b80f43f6e3d3c9fe54777c0f65800e947f9043290e14b01b63f8e26c30138094 2866c74b4a902ce491c0c950544cf0c6938eacb32eb30266ce82c4d0a36c511e a8ff7c409549a3a8264ca983d8c6d5e035f244243a775758aac992b58844b711 0d3f87c9bba19dd8a8d2ab1294e0555ec4995a548dc56cce35a05dc48aca7555 b1641dde3d197fcdf35d12f09aaf3e6a72775cd18249a21e70edac6710db6a21 e1c0561192dd0119133640cfff20f3187978516bfd6cbe66ce1071b1246f4ba9 37df901b3ed35069eebdfff65459fb9b777ae9298a7a49ac24f4020795de5dee 8dbcf20a241b6e814368f4b8fa42af8be892d9e1e38ae4bf5a47cfd46a398e4b 3186471e24534fb139860b25c63f2dbf85a53d86488c83dff09ae20a9bf83145 f20187f0e822bd475998d3b967011964eed8db9778054efcc6ccb69074bba996 624b4741c5710362de9d4f8de4b10f6db1e9f8098f4024593ea073893cb1fe7b 959c50fefc401b3cacdea8c2a17135ba9df90ab7f31de339a2d6f856c71edcfb 00e5a3d73201fbec4b4a79b9728ad70cda0b898121574f60d959b408c108af1a b0aa47dff372609f3186c063c572cb89089f2a218ea402cb072fcbc895a6a384 78ce402d5082c3e0572c2322cc20996ca968da35d7b2edbc0623be6165090120 5f10271155b539f81d006db8d7b67a4edeef677e6dac9c789be55001574eeea8 797f7f52e4bb021b98e2088dcc8d6934e80dc165d1c714449b0bcfaf325ab596 7b7307ec2937b3492425bf63b8abbd3ed97da1d15b5483fa64cf71a49c4d3b4b 78200d1f509206f2c104bfe3696e3c80036db00a5e11da05a5ff4da0ffb99567 f81399e6ca969b111b6c7b6fce549e6b4d89d459381ea9166e9bb3072089db94 ae0d1afe5f29fce190e77adba643494191cdaba3ead9297c3c606332b74697f1 9c09c4be2a341fd6145129ae856c3abbbc1bb8b05e0b7840ff164414a9da44e5 4146cd4c5de0c4e4ecb2591412b4e7bdc450d06a4ad3a0d1406f306e381ec291 f2c3b3bc49f8b7e048c0ce2734830b48a79d35fcc5a62a9454800a30f4b3eb7a 268bab64c12100d712151bf5f12163bed029e8abf1ca6e7b7b1286a733f532da e511091aab0fffcfd4464ee5663888f9859b44ba765360ffff434f12af1fc6bc cdb5a71947149dc7689dff24d6ba6b63e6cc23140e32934b6e9da765b4332011 8b8a811f89c3d1b7ff21530e77a91cae3557ac7c784ff8263500bc82560030d6 c6e74eee817fc2c63402752e59ef43916d3d83c21686436e9034dda6c974f210 8b174eaa1f73121c9add500cecd8618b302bedad72b62f793bd0f70ba8c5e16c f4abeddd51196816d019517d1e25fb62c9f79d9232fdf1ceec604f8dda5f7145 541c5793b9c5ae1589588a49a6e6174614ea012933a192b3b084725b465bb1a2 2ccb4b60cf3ca142f7683a8267fb6b0a8dc0b3a5f63ab60443f6c7ee70e9b5b0 67adfdc33960f88961e8b6a8a31e61cbc0096888f06346637ecece196291b95e 3b8c579df27010e631eba3634c766a933d7f4e20811946bb87e97f7e7bade957 e4c52d72676af91ac771ec351f36411e2b2cc8327611037cf0df4e3b947a87ef 5e2b57955b137c981105af76d6251cc14cdb3f430ed6b9f514404ce7a69bb000 d5f62c7e876b57f40f262e6a3e6be91ed0af7c8b5b74b160f3c661d735799d5f b47685135c5551f69a09444f5f01295f539a8227d271e4849fbc8906cf57e67e a5e150df5f13b0b412f97b21840b82e4d71739d1bec5ef9e58b047d52dfe0f39 26d5d48a4bb81764e10813070436e8bfaa75dbc90ffb6ecb0604a1338206f347 25c689fcb1687acb444b533d4c4da9846192825c03d9cc9a1685bcdd367b3f41 3b2334ff3096ebc146d7646fac3856b9ba18ed815d8ea941404f7280eeca6021 7c017d4f1467f3ad0e41e31c4ff351b14f59ffc9d19f3dca6c0b8c4d8b10eaa6 e3b8b4c3c1f17d0786f86140d0476db3f3097308d2f3830165192235db185fdd e8d19708c664927fd75529e2911e8114bf73e2e2d8e52f42bf49c62f17188744 2596354fca15a730c97f70b6f60a40456483017ac59f49606479ea17279b782d 6e0d6f2bff01ad626236102e77f8594e179005707fb72f339b6737abab0ae8af 850c380f81e5c40c539bc3bf52c57162f3bc91cc5c97c21cbe67552ba45c231a c2bf836de2a3ae4b1e1b4517d20a546d0cb4bc7207d4ada0783db1ca5dd327c8 c268a3b16ff1eef8a7e4bed382b21d3b4c0f9c9d357558747beecbd470c12bcc 75d63859bcf94a2621700b3b51220dba6edfc8044512e40bce1e32144142329c 76695c045b268a5b7771f2287f2a6e84c4622058c891ed34cb618475056c6460 3f2d7d4720ba83e1d1050c3408d8b3ef086e6a7b6f074df5aca73b2a2bde0844 44b39be566769223373913cab3c8d3ac8cbf168719a8f052d2d6091789386fee 5e1b306d7ec4be2558caa091e2fcc32c355702e971a3f3ac1da421317f3160e2 d7a27b71ed2342065bbf104070c3942494a5257607798a0afb6c3c6cbd9eaf1f 2ff070d233637454762767b839294a6d612282f3e3f496d939ba0b6bbd2dae5e beeef101f232d6e97c2c4dff3f40000000000000000000000000017263843` } } Appendix D. Pre-hashing (ExternalMu-ML-DSA) Some applications require pre-hashing, where the signature generation process can be separated into a pre-hash step and a core signature step in order to ease operational requirements around large or inconsistently-sized payloads. Pre-hashing can be performed at the protocol layer, but not all protocols support it. Examples in [RFC5280] are certificates and CRLs; these do not include message digesting before signing. This can make signing large CRLs or a high volume of certificates with large public keys challenging. As mentioned in the introduction, pure ML-DSA signing itself supports a pre-hashing flow by splitting the operation over two modules. In this section, we make this "ExternalMu-ML-DSA" more explicit. There are two steps. First an ExternalMu-ML-DSA.Prehash() followed by ExternalMu-ML-DSA.Sign(). Together these are functionally equivalent to ML-DSA.Sign() from [FIPS204] in that used in sequence they create exactly the same signatures as regular pure ML-DSA, which can be verified by the unmodified ML-DSA.Verify(). An ML-DSA key and certificate can be used with either ML-DSA or ExternalMu-ML-DSA interchangeably. Note that ExternalMu-ML-DSA describes a different signature API from ML-DSA and therefore might require explicit support from hardware or software cryptographic modules. Note that the signing mode defined here is different from HashML-DSA defined in Section 5.4 of [FIPS204]. This specification uses exclusively ExternalMu-ML-DSA for pre-hashed use cases. See Section 8.1 for additional discussion of why HashML-DSA is disallowed in PKIX. All functions and notation used in Figure 2 and Figure 3 are defined in [FIPS204]. External operations: ExternalMu-ML-DSA.Prehash(pk, M, ctx): if |ctx| > 255 then return error # return an error indication if the context string is # too long end if M' = BytesToBits(IntegerToBytes(0, 1) ∥ IntegerToBytes(|ctx|, 1) || ctx) || M mu = H(BytesToBits(H(pk, 64)) || M', 64) return mu Figure 2: External steps of ExternalMu-ML-DSA Internal operations: ExternalMu-ML-DSA.Sign(sk, mu): if |mu| != 512 then return error # return an error indication if the input mu is not # 64 bytes (512 bits). end if rnd = rand(32) # for the optional deterministic variant, # set rnd to all zeroes if rnd = NULL then return error # return an error indication if random bit # generation failed end if sigma = ExternalMu-ML-DSA.Sign_internal(sk, mu, rnd) return sigma ExternalMu-ML-DSA.Sign_internal(sk, mu, rnd): # mu is passed as argument instead of M' ... identical to FIPS 204 Algorithm 7, but with Line 6 removed. Figure 3: Internal steps of ExternalMu-ML-DSA ExternalMu-ML-DSA requires the public key, or its prehash, as input to the pre-digesting function. This assumes the signer generating the pre-hash is in possession of the public key before signing and is different from conventional pre-hashing which only requires the message and the hash function as input. Security-wise, during the signing operation of pure (or "one-step") ML-DSA, the cryptographic module extracts the public key hash tr from the secret key object, and thus there is no possibility of mismatch between tr and sk. In ExternalMu-ML-DSA, the public key or its hash needs to be provided to the Prehash() routine indpedendly of the secret key, and while the exact mechanism by which it is delivered will be implementation-specific, it does open a windown for mismatches between tr and sk. First, this will produce a signature which will fail to verify under the intended public key since a compliant Verify() routine will independently compute tr from the public key. Implementors should pay careful attention to how the public key or its hash is delivered to the ExternalMu-ML- DSA.Prehash() routine, and from where they are sourcing this data. Acknowledgments We would like to thank ... for their insightful comments. Authors' Addresses Jake Massimo AWS United States of America Email: jakemas@amazon.com Panos Kampanakis AWS United States of America Email: kpanos@amazon.com Sean Turner sn3rd Email: sean@sn3rd.com Bas Westerbaan Cloudflare Email: bas@cloudflare.com