]> Huawei

lucas.prabel@huawei.com

Huawei

sunshuzhou@huawei.com

Entrust Limited

john.gray@entrust.com

Nokia

Bangalore Karnataka India kondtir@gmail.com

Security Javascript Object Signing and Encryption JOSE COSE PQC ML-DSA Signature Hybrid This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Post-Quantum Traditional (PQ/T) hybrid composite signatures. The composite algorithms described combine the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) as the post-quantum component and either the Elliptic Curve Digital Signature Algorithm (ECDSA) or the Edwards-Curve Digital Signature Algorithm (EdDSA) as the traditional component. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Javascript Object Signing and Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The impact of a potential Cryptographically Relevant Quantum Computer (CRQC) on algorithms whose security is based on mathematical problems such as integer factorisation or discrete logarithms over finite fields or elliptic curves raises the need for new algorithms that are perceived to be secure against CRQC as well as classical computers. Such algorithms are called post-quantum, while algorithms based on integer factorisation or discrete logarithms are called traditional. While switching from a traditional algorithm to a post-quantum one intends to strengthen the security against an adversary possessing a quantum computer, the lack of maturing time of post-quantum algorithms compared to traditional algorithms raises uncertainty about their security. Thus, the joint use of a traditional algorithm and a post-quantum algorithm in protocols represents a solution to this problem by providing security as long as at least one of the traditional or post-quantum components remains secure. This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. This document follows the terminology for post-quantum hybrid schemes defined in . This section recalls some of this terminology, but also adds other definitions used throughout the whole document: "Asymmetric Traditional Cryptographic Algorithm": An asymmetric cryptographic algorithm based on integer factorisation, finite field discrete logarithms, elliptic curve discrete logarithms, or related mathematical problems. A related mathematical problem is one that can be solved by solving the integer factorisation, finite field discrete logarithm or elliptic curve discrete logarithm problem. Where there is little risk of confusion asymmetric traditional cryptographic algorithms can also be referred to as traditional algorithms for brevity. "Post-Quantum Algorithm": An asymmetric cryptographic algorithm that is intended to be secure against attacks using quantum computers as well as classical computers. As with all cryptography, it always remains the case that attacks, either quantum or classical, may be found against post-quantum algorithms. Therefore it should not be assumed that just because an algorithm is designed to provide post-quantum security it will not be compromised. "Post-Quantum Traditional (PQ/T) Hybrid Scheme": A multi-algorithm scheme where at least one component algorithm is a post-quantum algorithm and at least one is a traditional algorithm. "PQ/T Hybrid Digital Signature": A multi-algorithm digital signature scheme made up of two or more component digital signature algorithms where at least one is a post-quantum algorithm and at least one is a traditional algorithm. "Composite Algorithm": An algorithm which is a sequence of two component algorithms, as defined in . "Component Algorithm": Each cryptographic algorithm that forms part of a cryptographic scheme.

Algorithm Key Pair (AKP) Type This document makes use of the Algorithm Key Pair (AKP) type which is defined in . As a reminder, the AKP type is used to express public and private keys for use with algorithms. The parameters for public and private keys contain byte strings. This document makes use of the serialization routines defined in to obtain the byte string encodings of the composite public and private keys. The process to compute JWK Thumbprint and COSE Key Thumbprint as described in and is detailed in .

Composite ML-DSA in JOSE and COSE The composite algorithms registered in this document are the Composite ML-DSA algorithms defined in . Key generation, signature generation, signature verification, and the serialization of composite keys and signatures are performed exactly as specified in , and are not repeated here. In particular, composite keys and signatures are encoded using the SerializePublicKey, SerializePrivateKey and SerializeSignatureValue routines of , and decoded using the corresponding DeserializePublicKey, DeserializePrivateKey and DeserializeSignatureValue routines.

Use in JOSE and COSE The Composite ML-DSA algorithms are used in JOSE and COSE as follows:

• Signatures are produced as described in for JOSE and in for COSE, using the Composite ML-DSA algorithm as the signature algorithm. The signature value is the output of SerializeSignatureValue.
• The application context string ctx passed to the Composite ML-DSA signature generation and verification algorithms MUST be the empty string, similarly to . As a consequence, the context length byte in the message representative M' defined in is always 0x00.
• The prefix, as well as the label and the pre-hash algorithm of each composite algorithm, are those defined in . The prefix is the ASCII encoding of the string "CompositeAlgorithmSignatures2025", which in hex is 43 6F 6D 70 6F 73 69 74 65 41 6C 67 6F 72 69 74 68 6D 53 69 67 6E 61 74 75 72 65 73 32 30 32 35. The labels are recalled in , and the pre-hash algorithms in (for JOSE) and (for COSE).
• Composite keys are expressed using the AKP key type (see ). The pub parameter contains the output of SerializePublicKey, and the priv parameter contains the output of SerializePrivateKey. As in , the ML-DSA component of the private key MUST be the 32-byte seed.

For the ECDSA component, the signature, private key and public key are encoded as in : the signature as an Ecdsa-Sig-Value , the private key as an ECPrivateKey , and the public key as an uncompressed X9.62 point. gives guidance on how to produce and parse these encodings. For the EdDSA component, keys and signatures are encoded as defined in .

ECDSA Encodings This section describes how to construct and parse the three ECDSA encodings required by this document: the DER-encoded Ecdsa-Sig-Value and ECPrivateKey structures, and the X9.62 uncompressed point encoding used for public keys. None of it requires implementers to write a general-purpose ASN.1 encoder or decoder, but implementers who already have access to a standard ASN.1/DER library MAY use it instead for the two DER structures. When such a library is used to encode, its output has to be exactly the encoding described in this section. When it is used to decode, any other encoding has to be rejected. In particular, some libraries include the optional publicKey field of ECPrivateKey by default, which is not permitted here (see ). Sizes (in bytes) of ECDSA keys and signatures as encoded in this document

Field	Encoding used in this document	P-256	P-384
Private key	ECPrivateKey ()	51	64
Public key	X9.62 uncompressed point ()	65	97
Signature	Ecdsa-Sig-Value ()	<= 72	<= 104

Ecdsa-Sig-Value (Signatures) Ecdsa-Sig-Value is defined in as: r and s are the same big-endian integer values used by and , where they are zero-padded to a fixed length for a given curve (32 bytes each for P-256, 48 bytes each for P-384). As integers, however, r and s can have fewer significant bytes than this fixed length whenever their leading bytes are zero; Step 1 below removes this padding before re-encoding them as DER INTEGERs. Building an Ecdsa-Sig-Value from r and s takes two steps:

• first, r and s are each turned independently into a DER INTEGER (Step 1);
• then the two results are wrapped in a DER SEQUENCE (Step 2).

Decoding reverses these two steps. No prior ASN.1 knowledge is assumed below. Step 1: encode r and s as DER INTEGERs. A DER INTEGER is written as a 0x02 tag byte, a length byte, and the value's bytes. Because a DER INTEGER is signed, an extra 0x00 byte is prepended whenever the value would otherwise be misread as negative, i.e. whenever its first byte is 0x80 or greater. explains how to turn a raw value (r or s) into its DER encoding. Turning a raw value (r or s) into its DER encoding

First byte after removing leading 0x00 bytes (keeping at least one byte)	DER encoding
less than 0x80	0x02, then the length in bytes of the trimmed value, then the trimmed value
0x80 or greater	0x02, then the length in bytes of the trimmed value plus 1, then 0x00, then the trimmed value

The length is always written as a single byte in this document: r, s, and their DER encodings are always well under 128 bytes, so DER's multi-byte "long form" length encoding is never needed here. For example, for P-256 (32-byte r and s):

• if r starts with 4F ... (no leading zero byte, and 0x4F is less than 0x80), its DER encoding is 02 20 <r, 32 bytes> (0x20 = 32);
• if r starts with F3 ... (no leading zero byte, and 0xF3 is greater than 0x80), its DER encoding is 02 21 00 <r, 32 bytes> (0x21 = 33);
• if r starts with 00 07 ... (one leading zero byte to remove, and 0x07 is less than 0x80), its DER encoding is 02 1F <r without its leading 0x00, 31 bytes> (0x1F = 31).

Step 2: wrap r's and s's DER encodings in a SEQUENCE. Using the two encodings produced in Step 1, the full Ecdsa-Sig-Value is simply the concatenation Ecdsa-Sig-Value <- 0x30 || length || r's DER encoding || s's DER encoding where length is a single byte equal to the combined length, in bytes, of r's and s's DER encodings from Step 1, and r's encoding always comes before s's. Continuing the example above: taking r's DER encoding from the third case (02 1F <31 bytes>, 33 bytes total) and an s whose DER encoding corresponds to the first case (02 20 <32 bytes>, 34 bytes total), the combined length is 33 + 34 = 67 = 0x43, and the full Ecdsa-Sig-Value is 30 43 <r's DER encoding> <s's DER encoding> (69 bytes total). Decoding reverses Steps 2 and 1, in that order. An Ecdsa-Sig-Value that is not encoded as described above MUST be rejected.

ECPrivateKey (Private Keys) ECPrivateKey is defined in as: Given the raw, fixed-length ECDSA private key d (curve size n: 32 bytes for P-256, 48 bytes for P-384), the ECPrivateKey is d inserted between two fixed byte sequences that depend only on the curve (the publicKey field is never included): ECPrivateKey <- bytes before d || d || bytes after d The fixed byte sequences are given in : Construction of an ECPrivateKey, by curve

Curve	Bytes before d	d	Bytes after d
P-256	30 31 02 01 01 04 20	<d, 32 bytes>	A0 0A 06 08 2A 86 48 CE 3D 03 01 07
P-384	30 3E 02 01 01 04 30	<d, 48 bytes>	A0 07 06 05 2B 81 04 00 22

For example, for P-256 (n = 32), with d = D1 D2 ...D32: An ECPrivateKey used in this document MUST have exactly this form: the parameters field MUST be present and contain the OID of the curve, and the publicKey field MUST NOT be present. Decoding reverses the same construction. The decoder checks that the ECPrivateKey has the length given in and that the bytes before and after d are those of , and then reads d between them. An ECPrivateKey that fails this check MUST be rejected, even if it is valid according to . This is the case, for example, when the publicKey field is present.

X9.62 Uncompressed Point (Public Keys) The ECDSA public key in this document is encoded as the X9.62 uncompressed point: ECDSA public key <- 0x04 || x || y where x and y are the same raw, fixed-length, big-endian coordinate values already used by and (32 bytes each for P-256, 48 bytes each for P-384).

Composite Signature Instantiations The ML-DSA signature scheme supports three possible parameter sets, each of which corresponding to a specific security strength. See for more considerations on that matter. The combinations in and are a subset of those defined in . As explained there, each ML-DSA parameter set is paired with commonly deployed traditional algorithms, rather than with a traditional algorithm of exactly the same security level, as such an exact match is difficult to define, since there is no consensus on how to compare security against classical adversaries with security against quantum adversaries. The specification defines both pure and pre-hash modes for ML-DSA, referred to as "ML-DSA" and "HashML-DSA" respectively. This document only specifies a single mode which is similar in construction to HashML-DSA. However, because the pre-hashing is done at the composite level, only the pure ML-DSA algorithm is used as the underlying ML-DSA primitive.

JOSE algorithms The following table defines a list of algorithms associated with specific PQ/T combinations to be registered in . JOSE Composite Signature Algorithms for ML-DSA

Name	First Algorithm	Second Algorithm	Pre-Hash	Description
ML-DSA-44-ES256	ML-DSA-44	ecdsa-with-SHA256 with P-256	SHA256	Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA256
ML-DSA-65-ES256	ML-DSA-65	ecdsa-with-SHA256 with P-256	SHA512	Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA256
ML-DSA-87-ES384	ML-DSA-87	ecdsa-with-SHA384 with P-384	SHA512	Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA384
ML-DSA-44-Ed25519	ML-DSA-44	Ed25519	SHA512	Composite Signature with ML-DSA-44 and Ed25519
ML-DSA-65-Ed25519	ML-DSA-65	Ed25519	SHA512	Composite Signature with ML-DSA-65 and Ed25519
ML-DSA-87-Ed448	ML-DSA-87	Ed448	SHAKE256	Composite Signature with ML-DSA-87 and Ed448

Examples can be found in .

COSE algorithms The following table defines a list of algorithms associated with specific PQ/T combinations to be registered in . COSE Composite Signature Algorithms for ML-DSA

Name	COSE Value	First Algorithm	Second Algorithm	Pre-Hash	Description
ML-DSA-44-ES256	TBD (request assignment -54)	ML-DSA-44	ecdsa-with-SHA256 with P-256	SHA256	Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA256
ML-DSA-65-ES256	TBD (request assignment -55)	ML-DSA-65	ecdsa-with-SHA256 with P-256	SHA512	Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA256
ML-DSA-87-ES384	TBD (request assignment -56)	ML-DSA-87	ecdsa-with-SHA384 with P-384	SHA512	Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA384
ML-DSA-44-Ed25519	TBD (request assignment -57)	ML-DSA-44	Ed25519	SHA512	Composite Signature with ML-DSA-44 and Ed25519
ML-DSA-65-Ed25519	TBD (request assignment -58)	ML-DSA-65	Ed25519	SHA512	Composite Signature with ML-DSA-65 and Ed25519
ML-DSA-87-Ed448	TBD (request assignment -59)	ML-DSA-87	Ed448	SHAKE256	Composite Signature with ML-DSA-87 and Ed448

Examples can be found in .

Composite Labels for JOSE and COSE The JOSE and COSE composite label values are listed in . They are represented here as ASCII strings, but implementers MUST convert them to byte strings using the obvious ASCII conversions prior to concatenating them with other byte values, as in . JOSE/COSE Composite Label Values

"alg" Header Parameter	Label (in ASCII)	Label (in Hex encoding)
ML-DSA-44-ES256	COMPSIG-MLDSA44-ECDSA-P256-SHA256	43 4F 4D 50 53 49 47 2D 4D 4C 44 53 41 34 34 2D 45 43 44 53 41 2D 50 32 35 36 2D 53 48 41 32 35 36
ML-DSA-65-ES256	COMPSIG-MLDSA65-ECDSA-P256-SHA512	43 4F 4D 50 53 49 47 2D 4D 4C 44 53 41 36 35 2D 45 43 44 53 41 2D 50 32 35 36 2D 53 48 41 35 31 32
ML-DSA-87-ES384	COMPSIG-MLDSA87-ECDSA-P384-SHA512	43 4F 4D 50 53 49 47 2D 4D 4C 44 53 41 38 37 2D 45 43 44 53 41 2D 50 33 38 34 2D 53 48 41 35 31 32
ML-DSA-44-Ed25519	COMPSIG-MLDSA44-Ed25519-SHA512	43 4F 4D 50 53 49 47 2D 4D 4C 44 53 41 34 34 2D 45 64 32 35 35 31 39 2D 53 48 41 35 31 32
ML-DSA-65-Ed25519	COMPSIG-MLDSA65-Ed25519-SHA512	43 4F 4D 50 53 49 47 2D 4D 4C 44 53 41 36 35 2D 45 64 32 35 35 31 39 2D 53 48 41 35 31 32
ML-DSA-87-Ed448	COMPSIG-MLDSA87-Ed448-SHAKE256	43 4F 4D 50 53 49 47 2D 4D 4C 44 53 41 38 37 2D 45 64 34 34 38 2D 53 48 41 4B 45 32 35 36

Security Considerations The security considerations of the component algorithms (ML-DSA, ECDSA, and EdDSA) as described in , , and apply to this document. Similarly, the security considerations relative to the JWS, JWK, AKP and COSE structures , , and apply to this document. The security considerations of also apply to the composite algorithms used in this document. In addition, the following considerations specific to the composite design and its use in JOSE/COSE must be taken into account.

Hybrid Security and Quantum Resistance An important objective of Composite ML-DSA is to provide protection against CRQCs. Under a CRQC, traditional signature algorithms (ECDSA, EdDSA) are vulnerable to private-key recovery, enabling attackers to forge arbitrary JWS objects or COSE_Sign/COSE_Sign1 structures and fully impersonate the signer. By requiring the successful verification of both the ML-DSA component and the traditional component, this construction ensures:

• An adversary that compromises only one of the component algorithms cannot produce cryptographically protected JOSE/COSE objects as long as the other component remains secure. In particular, this prevents JOSE/COSE signature spoofing and impersonation attacks even if the traditional signature component is compromised.
• The scheme provides existential unforgeability under chosen-message attack (EUF-CMA) provided that at least one component algorithm is EUF-CMA secure and the pre-hash function PH is collision-resistant. This is the case for all combinations present in this document: ML-DSA, ECDSA and EdDSA are designed to be EUF-CMA secure (the latter two against classical adversaries only), and the pre-hash functions used (SHA-256, SHA-512, and SHAKE256 with 64-byte output) are collision-resistant.

Component Key Integrity and Reuse The security analysis of Composite ML-DSA in assumes that the two component keys of a composite key are freshly generated together and are not used anywhere else. The considerations below apply to composite keys used with JOSE and COSE.

• To avoid key reuse, when generating a new composite key, the key generation functions for both component algorithms MUST be executed. Moreover, compliant parties MUST NOT use, import, or export component keys that are used in other contexts, combinations, or as standalone keys. In particular, existing key material, such as an ECDSA, EdDSA or ML-DSA key already published as a JWK or COSE_Key, MUST NOT be reused as a component of a composite key. If a component key is also used on its own, a component signature taken out of a composite signature verifies under that key as a signature over the message representative M'. The prefix and label leave evidence that the signature comes from a composite, but they do not prevent this. Key reuse MUST therefore be avoided despite the weak non-separability of the combiner.
• A composite public key can be conveyed in an X.509 certificate, using the x5c header parameter in JOSE () or the x5chain header parameter in COSE . Such a certificate carries the composite key as specified in , with the same serialized public key as the pub parameter. In that case, the binding between the composite key and the signer is only as strong as the signatures on the certificates of the chain. A quantum adversary cannot forge a certificate signed with Composite ML-DSA as long as ML-DSA remains secure. If a certificate of the chain is signed with a traditional algorithm only, such an adversary can obtain a certificate for a composite key of its choice, and the composite signature on the JWS or COSE object no longer provides protection against a CRQC. The same holds for any other mechanism used to distribute composite public keys.

Domain Separation and Non-Separability The Composite ML-DSA signature combiner defined in prepends a fixed Prefix and an algorithm-specific Label to the pre-hashed message before signing.

• By binding the two component signatures to the specific composite algorithm, the composite scheme achieves "weak non-separability" as defined in .
• The label, specific to each composite algorithm, helps protect against component signatures being removed from the composite and used in another context. However, it does not fully prevent it as the traditional component still verifies under the traditional algorithm as a signature over M', which is why key reuse is forbidden.

For more information about the security properties relative to the signature combiner, the user can read .

Security Objectives and Limitations In JOSE/COSE, the security objective of digital signatures is to ensure that only an authorized signer can produce a valid signature over a given protected header and payload. Therefore, users should be aware of specific scenarios where Composite ML-DSA may not be appropriate:

• The ECDSA combinations are not SUF-CMA secure against classical or quantum adversaries, since ECDSA signatures are malleable. The Ed25519 and Ed448 combinations are SUF-CMA secure against classical adversaries, but are not SUF-CMA secure against quantum adversaries, who can break the traditional component. Consequently, applications for which SUF-CMA security is a strict requirement SHOULD NOT use Composite ML-DSA. An application can still use it, after carefully weighing the security implications, if it only needs strong unforgeability against classical adversaries and uses an Ed25519 or Ed448 combination, or if it needs strong unforgeability only to obtain a unique identifier for an object and identifies the object by a signed identifier such as jti or cti rather than by the signature value.
• Composite ML-DSA does not guarantee that a message has a single valid signature. Applications therefore cannot use the signature value, or a hash of the complete JWS or COSE object, as a unique identifier.
• Replay protection is not handled by the signature itself but must be addressed through claims such as exp, nbf, and jti in JOSE () or the equivalent claims in COSE ().

IANA Considerations

JOSE Algorithms The following values of the JWS "alg" (algorithm) are requested to be added to the "JSON Web Signature and Encryption Algorithms" registry. They are represented following the registration template provided in .

ML-DSA-44-ES256

• Algorithm Name: ML-DSA-44-ES256
• Algorithm Description: Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA-256
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

ML-DSA-65-ES256

• Algorithm Name: ML-DSA-65-ES256
• Algorithm Description: Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA-256
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

ML-DSA-87-ES384

• Algorithm Name: ML-DSA-87-ES384
• Algorithm Description: Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA-384
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Documents(s):

ML-DSA-44-Ed25519

• Algorithm Name: ML-DSA-44-Ed25519
• Algorithm Description: Composite Signature with ML-DSA-44 and Ed25519 using SHA-512
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Document(s):

ML-DSA-65-Ed25519

• Algorithm Name: ML-DSA-65-Ed25519
• Algorithm Description: Composite Signature with ML-DSA-65 and Ed25519 using SHA-512
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Document(s):

ML-DSA-87-Ed448

• Algorithm Name: ML-DSA-87-Ed448
• Algorithm Description: Composite Signature with ML-DSA-87 and Ed448 using SHAKE-256
• Algorithm Usage Location(s): alg
• JOSE Implementation Requirements: Optional
• Change Controller: IETF
• Specification Document(s): RFC XXXX
• Algorithm Analysis Document(s):

COSE Algorithms The following values are requested to be added to the "COSE Algorithms" registry. They are represented following the registration template provided in , .

ML-DSA-44-ES256

• Name: ML-DSA-44-ES256
• Value: TBD (request assignment -54)
• Description: Composite Signature with ML-DSA-44 and ECDSA using P-256 curve and SHA-256
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: No

ML-DSA-65-ES256

• Name: ML-DSA-65-ES256
• Value: TBD (request assignment -55)
• Description: Composite Signature with ML-DSA-65 and ECDSA using P-256 curve and SHA-256
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: No

ML-DSA-87-ES384

• Name: ML-DSA-87-ES384
• Value: TBD (request assignment -56)
• Description: Composite Signature with ML-DSA-87 and ECDSA using P-384 curve and SHA-384
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: No

ML-DSA-44-Ed25519

• Name: ML-DSA-44-Ed25519
• Value: TBD (request assignment -57)
• Description: Composite Signature with ML-DSA-44 and Ed25519 using SHA-512
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: No

ML-DSA-65-Ed25519

• Name: ML-DSA-65-Ed25519
• Value: TBD (request assignment -58)
• Description: Composite Signature with ML-DSA-65 and Ed25519 using SHA-512
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: No

ML-DSA-87-Ed448

• Name: ML-DSA-87-Ed448
• Value: TBD (request assignment -59)
• Description: Composite Signature with ML-DSA-87 and Ed448 using SHAKE-256
• Capabilities: [kty]
• Change Controller: IETF
• Reference: RFC XXXX
• Recommended: No

References Normative References This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK] This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. IANA n.d. IANA n.d. National Institute of Standards and Technology (NIST) American National Standards Institute In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. One aspect of the transition to post-quantum algorithms in cryptographic protocols is the development of hybrid schemes that incorporate both post-quantum and traditional asymmetric algorithms. This document defines terminology for such schemes. It is intended to be used as a reference and, hopefully, to ensure consistency and clarity across different protocols, standards, and organisations. This document describes classification of design goals and security considerations for hybrid digital signature schemes, including proof composability, non-separability of the component signatures given a hybrid signature, backwards and forwards compatibility, hybrid generality, and Simultaneous Verification (SV).

Examples

JOSE

ML-DSA-44-ES256

ML-DSA-44-Ed25519

ML-DSA-65-ES256

ML-DSA-65-Ed25519

ML-DSA-87-ES384

ML-DSA-87-Ed448

COSE

ML-DSA-44-ES256 >, / external_aad / h'', / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573' ] / Message representative M' = Prefix || Label || 0x00 || PH(M) / h'436f6d706f73697465416c676f726974686d5369676e61747572657332303235 434f4d505349472d4d4c44534134342d45434453412d503235362d5348413235 3600ad9c56542caaef74ac6ad7cbf62386c2f4aac8c329e4a6a614fd272572cc bead' / COSE_Sign1 / 18([ << { / alg ML-DSA-44-ES256 / 1: -54, / kid / 4: h'08e7acdb81ec1e3e' } >>, / unprotected / {}, / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573', / signature / h'2a2fa6272a8cabd04670e6adce8f462c9c905742f528d59012cb6ad1aabe8734 1df45c39c840a5c2007febfbeb0f755becb8d1bfa4bde4b16656cea016f42f8a 5cbdc37ff388b419a91ffc31680c14744c3e4d6263f7db6a6d1ab6a983bb6ff3 5ad62e388b59508913a786ce0fb39d8badbca771021afd7df255002a5ba3dd9c 0da9b2850a816913c3ef3b353fb24e6294287b7d0799d01056e4ef23aaffb68e 10a3df96b90ab38d2d4b5e6373d8f321f8c2ffd0a9fc672f8d0bdb677e39ce5d c1a3ae817cc1b6bc033bc0fdfea2dba7cd24558bddd594f96c8b21f206b7f2bf 64b094f829f54f57be1357c3c610e406250f4a689cf00b23f4107b1c07062e55 b18a73c9ec282abccee312f05a4c057e517647f13593ce6455f1ee721ac7099f 6bb42f61b8cef0d8faebfa2924a48f2210b25ea1b9daeb698d7d96a3348e921b 84b98d9fb78111c174aa8f234eb06f02e78a662c2f76302022be516f9012edbf 26b07b9ee6086d8e5b549d2a953cd35f9a27ad89bbc2747471d38383e4e53c2b cddb293fa2807b9baa18d37f8729dad3ee86ff0efa8fe7750eda6d48e838b70a 94e6b062f402afdb7089bbe24ebd81cfdf0bd73b38c188a9e66bafc3dbe62288 3d4427c276fd3b101add92294fbee3cf4891022e0899446d76e1c6b20f848965 f7fa8bfff642c75a3975b8f4317f528ca46d3c08bef2d586be15bf684619017c 411dcbbefa7333c834f25a137dba319e24b89479a84357765be4be74063d9172 a1cf2891594b5de34aed7a387ca6928d538e0daf4cfda698545f7ec2a71635a7 f086e7e342950000a6ce46cf8c52f8139bddb9288cd0e4130b3e90422bc9f464 fe0453795156f0cd62721e9cc831cc2a9ec0558feb4fa79c1b2b8442b55d9d82 7e085119afef0c8a6706fba58117c4e5c77f1fe1f766c54f0cd789e383479418 c5968230d5f86d319d97a009c35c6288c6ac6b7846b3dcc3b9daae92c7759017 2b77e0ff9258faec938c9996a10d82cbaec999c08a05ee0244002c2383bd110b 8ad7218cada06646455de2afc247b723961961523b5633fb00bc46aac1bb2a26 70ac0cb5e79e4335728535c78374dfbafbced9c8a65d01f20435d0500d3622dc 74ff528cbae4926080c83e4879a0887e168db95c59e85489b0a0146399231f40 fe9d965908d9f685827d0393a74edf8bf6bc015ab4071dbdfa9e1157db6b63d9 35144c481966037a464875fff90555c3d055ac8b39b996d3794fc264dd2a334e 7a0ec253986e283e36c4346e93f97b4f7e62015d72be5352dcc03771c4b4b485 81367f26296645dd1c886b166b7d91bb8ece9e50a42d86bf22855cdd8c190042 b502c5d22c7f1f473b25d2c1b5412efaaf5c195c37846bd455c783f9083e46a2 8a2fcbaeb39a792675ff31431d51a13871091a0c35844904aff57288f076636c a826142943837c0ebe5ad0c3210a89d88655c1792c0704dca97bce5b144d3e94 6100c626d352a1e17e24717fe4478bd9901b0df9fd5eda7eefb1a582732f3a33 cfa7df15234b59cacf868e1141cb22442e8ccbe970d842b7d1dfe2d6ca1e4ed8 ccd0f4fbd8d1799177b6c2ef210602b1dd9033ae899c52137937d1538875b152 dd05357842dd0087325ec0b5343335174968b5b2f15b76db936b6db29bd79e35 ed9eb0575375a884a3efd57bac1449699b93fe186e0cc6e43b3d0d3e2973033b feaf2e1803798b087b049ce8a2c7a2156d1b3a16dde288a158bc740afa154835 ef7d1b5e6dddbcaafbaf2c490a0bf08a14b69c871576aa370d43cdcb9a0e346a 4b79f740a8f0168d95c9e2d684ec6759d0302d5346803252bda5bee8d64dee39 e1686c90a293fb8c2bfedfdc00778141b362e522827a26f3c095ccce0680d7b8 6b7650cd40f94b272dec01e58da108b0312de29b738b04f26034515a35e4235f 92b877c5fb64494b54c9e1f8005140ae73b0d60d8ca0f234ae6de7deec60867e d3eb04b08602b313c99f69a9497e9a65fb574e1a2e749724fbdea47f58192e96 17e90afb5a88681042591aa092acbaaf68424287651bca7b1a35fab63936c85c 440be4aa5a5b86425d7117c6f3a51d499dbf42148cec7dd877733adf30e1c23b e878715e58b3538295b02138144b70398bff8124fe2d4931339769e24e563c89 d75870ffccedb1fd1d5b2eaa2adac94fdf1660dd272513b28b7a2aa8266117e0 58800dafc46fb20de541d275804933e9e30f5beb5bffa36f4665ba334bf88214 672a95a104b1877f74ca9b0a18ec2c0769c67871eae04b5b9820fa4e6742c37e 1ad126a323e28c6c83c2182390297aa304fe8c0b21c85713fbf94f19a2094816 6c1b5fe68371b509e693fbcfc750aa84eff2608a4d1083647eab2af2a074f475 732e5fc667c97f1d7374fab7b54897204d61e4f6de7b949a4a8580407f877056 cb6eee57c95e566fb8f8eb25387f52beacd85813ab6dc779f9b92b278ee414ff 643ae3bf4c4c449ff35392d5b9e9cd914d1eabfa043ac33d9312ce5b9a82dd04 eb0491c4584a711c386b78d8e86705c1c07db3cd5a53a3e4ce340f9a178a6107 eadf883d2ee481ee3c84b73d37d85332b344d235a0ab1cdeb513875949a5948f 918b1243f43c90b135bc8c4867f53348f563f660efb44401f0aa72e90ddefe65 7521a382adb5b6100feea242349b70ceff91391e2ad922fb50842a8fdb8a276e 9f3e5601b8fe27979afd40b1039eaa6b580d672d0a7424162f4a50bd517fe4d3 3a9cf6d6889895c92aea189b18f6505dd72b9434d2a819e5dd62eae2a3fa26e3 211e26c7d8751d4fec2304e13839ead9e006d9ba3bbf4a2789339eb2fd974742 acfecdd9420d3eb68ee031e9d7ad0ca8ab508d9776f2a60e804d0aacad590f60 bc864b042b0b1e1d90e653bb5171d9637b551b0a04b257866ce2a9830f6822c6 f56ba8ee1705e527cd5536a09e71acde5faf65e8ce9d3660cd5d4a6e6554c742 12b01b4baaae32392dc91be9fd764844b7509f7b81c5a54c8ffaba91bc8a9f9a db85f46f15a85662adbabf3320164640e5df7d3e1388fd9503ad5f5b43f2945c 5cdca8cf7f25299ca5b661042fef8a9d3abe25c52003676df0ecda149810dc0f eb0e815027994bd1d7b61d80af71b48f22fa709ae8fc80fbc0ead415303d830b ea2b10d2f2df077635f7bb9d31ab14e1286e1b4fd20016b869c7fef906d6c257 148f6bf73d32952b66267b90723e4252d49aadeed1ef89149b684f9747474b8d 8224afaca962a94c76ead84b91c21fb10c4c3b125c1915978390b525c7010547 2333393d4e5a6d76777da1a8c7d3d7dee3e9ebf609115584868a979fd4effb01 1d232931437f929aa9b6bde8020a12172f344b516e7e9fa5b1b6000000000000 00000000000000000000000000000000141f2c3a3045022100c397b4122fc219 aa149bf555c3afbd27109b56ee9a02fb12f05ea582b22b7e5f022009ff09b243 991efe4477811876b9f0bc5e80d98e923804340a9b13a5b73c1fd6' ]) ]]>

ML-DSA-44-Ed25519 >, / external_aad / h'', / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573' ] / Message representative M' = Prefix || Label || 0x00 || PH(M) / h'436f6d706f73697465416c676f726974686d5369676e61747572657332303235 434f4d505349472d4d4c44534134342d456432353531392d53484135313200e1 3c73e6534f34e69f9e2dfa19e812f1f92e308c477bf2eb351a47fa69e68af55e dea2a595419d44082ea6d38d0908d59ea3e97aac61ae9391dbe56c0e5b85eb' / COSE_Sign1 / 18([ << { / alg ML-DSA-44-Ed25519 / 1: -57, / kid / 4: h'b930f85dd9be4a04' } >>, / unprotected / {}, / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573', / signature / h'b90b8fd47a1c28cb219c3cfc816935c875de6c45578c2f0188e3be659eee9003 d58f029bf5a0abb8af014c0b56bbb3b79ffeb188b7c55cd3111c0fdf6ae109d6 231225b426f2cc014885306e3286416c3f3bf6d76f93745c15bb47e413356a0a db194d5434f542e63a9ad3d6dd9cf79df2c525ba2b7a4e584bbc6ce189dea259 557f6edf772d2eeb0deedb703e4af723290ac5703394ddea72f9b12597cd52f9 619df061b0cbf81f428e24fcbc4938caa118201e620a514993b393b3e339f6a6 7e292f443c72502a4901b6578b8444d76e5a55ed379bd2553b476d522a78bb0e 18ea01bc09bb89ecc53e606d1082f1010add7c92301b5f8167fde54215fd28ef d0aa4e7704312e4d081375917e5697826b1eab14f37765ab1ff1ae9804ebcc1b ce26f3a109b563ecf293106536a5623578ae851e35f3431f8a963a1f5186bf1c e61612984a06659e1bf49dcbf5dcba6c811b079a03749aebaa56125ecf8f3c9f 608e2c12993885641dbc97b8ab171ada3f7f0fb29a4280aceacb5b2e7709efe9 0a1fdf0eea4bb2b702914da3be3d553bb632d4b90fb1c5269121b15d81d4d859 6cbc60898eb0f0c6acc12fbf28bd0a49d5ee7b666b92ce92712a77f80de223d1 63e4e6ce002375c4a299d7f1113332ad0d9c04a2ec29090ea57c6f2ae37e3c65 97f93951a4de89e0cd585a6c24341d67f9f30a576c8d231e8084278d02fe7895 6df4eb22bfe3ef8a62e18d865f03890551e79626540e7d83c213d3f5f01d6093 eeab5741dbfed50b3af9511821726325b7f56783cb7bef0ba5db19277a27d05b 794fc5918e19ef40404f50bcefe8ec06c672b0289ff514d47bedbe8bee7185c1 20289b3ad26550116189bb7f789c2b73fcc257f3f96fd6d398277934dc224beb 7f3ee5282e8798203c563045aa0d722c7c4b7b0d0a70a69306cee51d506de71a dc8f5b2d2cd9bb77d89f2b2a87914bb9c4d0cf8a32688ed9388ae6e6306f91c0 c5bb10c6f28bb2d4ac53863c2cec9dd18b4f68dccca8006ed0f2f0675fbd7439 5c47f4d7e6242f5a8273c406e7bc01181cc12a87cc23c967e2e4731a6eb43c5c 775b4b1a74658bc38d184d2b5f9fe1a781e57fb9151b45b50e7c959cf73810a9 ec4bc2ab6bcfda35f92ce53b8e5147fec4a41cc626d1fcce2bcd0b2e8d701694 bf2b99a895163149ece20b4ed17eb6046ac0eeb7f595b1c85836b246813ac414 f993ce346bc98ea56fe2e60e4225f22d338d5e6db71c9de0fb83162159eab381 b1961680d8a87b59bb29096653f27a92eeac28eeb1df6c6c78e4f67288887a23 bd2294431942cfc3f3deb3d053aace6cf813cb4326ce1004aeba4835f3bd48c8 ae2b4a9e964d4b24eef0cec84193910c2d0a971dc055cd3f4f248f24a9216e79 209f73868ea79f692b4cd1e7d262a657566130ff0433459931d309c00f304a31 5f2fcf7ab89f3206e0a13e0d9e8ef7e1e968b48d071e146d4af01c5fad74f6e1 2a531018c52113621b9b71252c4dfb11a0674b7d485d791eeee21dc6b86f3c1e e8557fee3077c055b7194221a365bcf71898dfed6b9d870d29a63a199b1dae83 309356a457d660218f53d65e973d2d68eaf43cef0c2990fbc322b76269032f2d d5e54dff349d81ec9be3de4d20c101752bc0cb7ff519240a9da5e74b0accdfff 797c116e338adee136e955d2be61440a23e2b0d05eee023ed777bbf7f32bb4f8 363f5887aa5e69f456f4865aadbeb450eddc25736466bfa71ec8cbe0a48c6bed 5fe28ff3d61c5f955318e8fbaa8bb4390ac152ae84fa043b1be624238b4bf1b0 629bfbb341222fb186d36f2f2349b185fc9f52933433ac02d8430142dc93783d 9a0324e044e0f0cb7b5881baaa06898dc78c856f0e0884c8c174d82437755e88 d2717a893a63812b71313248620ed519b2031c6466a16d4fe448df3313e8702a 8c55485aa7219fb2d178464a5cb044420b135c650905205683fdc0b31c225808 bbf689310aaa7333e87e7b5e45d85a8c987d14cc65a9f41d7ea3c24fa44aab90 cf87519ea9b1d61940dfe99d3a84966e1429955ecb9207087268aef699282100 10096815f3a88a967f595009f7cd778aeb28daec5c6e3be09b1a32f4580517e3 6253d4942cb160300a60cc8c02df6fdb8db861dbbee60a537a738f9225266c22 471a20acd4049c9c32334fc216765e51b56da9ec3cfbdb816a05d1615635b51e f41ab87cab6687a8d7935d1dc3e74a2daa5e122149c0d1679b0ea2ea912fd9da ac610e9fc591f9544d893d1dcc58187b9149e9a66d7a7c3408fdf5ea79bd962d e72b5c3e2f741f5185bcb12fa3e58c96d6c7bcabcfb87b2862194feb09660693 f3d5aa9eb4b717724ba78f13cee6ba9a60894971dbf266f986a003225e0e20c0 0d3dbe577d27274d4123595fd4fd8223edab6268dc0bab3501c2249a3a6a6531 fa571482562894994fd661c1718d7e0295417fb917dd5feb8dbeb3233cab2b37 be26833f29142113bfef92eac50327639312a33db9947892916a0d2245b49551 1e6f9d4ae25b79763295dae1dc33f4df38394c4a85c192370c002670d20271cf 8db0cfeb8ab5c1bace322c7dc9df3a6131c797f4cccb4afe12b46a2aad3b713c 69632f4e82c665a1c42292ec4c6dff66e881cc283d7d1c4923cf2a827255d616 7a578ab43b315a574488f95dac92c0e4196559bfc5977f83da68a8f7ec6ff7a8 256df71a071950d3cbfd84f7ed706b7d358eb200f2e92ce2d79e9f3d6adfd834 5691fbea66ce1099d55520f635b47ad32a3d158cada5253fba8ce2c7a5042fa0 d20f3402f06d7bcbcb9c8e8a5c6fec6f00d88c131f3e8f17c3389668ac3bd971 1a982f24c36cd6d56108556e98227313199aed7a79ce9cc661569f482c4a228f 8c85b3ac65cde8477dd16e3197629c6ec2836ef6ffd032c732f17d420aeb4cc8 0f41608716d87a9e77a5fece9d38dc99108ff09910c925ad7e82a1bc84bd45de 4057f64539ca1c63e46d0247ab8dac08d28fe430aebd9aa97cc53322303aa791 173633a253856d5b956ad23d9d14827040eccbefb5950332493b90fb1763dea2 7031a146362da86f0b6c750adea1b0386a3e50d072c56b882feabaf7e07898a9 85152a603468e0d41b8ffb941c343a7255781f5c608f98cbfedb01565f355f84 cefc32b4562239e42ed0387a1a59d2d68f730288d608cd4385e4b01b2e135b6e b11b6c39767675878858236595bed7d7fda32472ad50dbb033cbf94925f8f8ea b7e349a300cc2c1ada46f8f59c1f052e06dddd3a5bb8ca455b9a2e1b673675f9 0b1318252b313a3e445d7077808c979aa1b5bdc1cbd8e7effd03202c3b436f8a 91a0a6bcdcdde5e9f6f7f8154c5983b7c2cbd0dde1e5f4f7181b5a5d6265a0ae b5b7bbd5dbe8f5000000000000000000192b3847c9961e24ac6f9ffe772eeb6a c83bccfd7c09891a34e65475b990a446c6dfe19c88afee71cf55978a927cc021 127ec31626c3284c31c05eb64cc58fcec24c9d06' ]) ]]>

ML-DSA-65-ES256 >, / external_aad / h'', / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573' ] / Message representative M' = Prefix || Label || 0x00 || PH(M) / h'436f6d706f73697465416c676f726974686d5369676e61747572657332303235 434f4d505349472d4d4c44534136352d45434453412d503235362d5348413531 3200ca2b702903acf278f47a0ca5abb69b13a60605a055f7334ed9c6de25e1ca 63ae2bc4995cc7f9279eaf70c25a1f46a77b90756657e2b1fc623ea4bd79c384 6935' / COSE_Sign1 / 18([ << { / alg ML-DSA-65-ES256 / 1: -55, / kid / 4: h'65c28ec7cdef33cd' } >>, / unprotected / {}, / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573', / signature / h'eb31a839b3b9a2de6740077573d34b0f8536f7bc480f42a07e44eaf3b5efa783 6fb96ee559f841693beb99ac8c458343f233640f6f54243cb93840a13959e0e6 b0dd1b34891b56cc126ee9ac4ebac54ba28a8c0b676266a4543abfa9f00d403f ae8323e28b11d3e0017274bad65ff2a322bd36b86e8108cd9704e47d70d7cc92 8065cfe0c5c18ddcae6debdbd90e1aa08b2101adbd648399987aa2aeee602873 97beb5c3e83b1ad102a31ada5c7a32b265ae5a7dc6643f6591d4b3b6109c7b8f 311d8de6c53efe6100110227106de0475d202de65a6d5cad520909f50cf0d117 fed2b65242014940de066e9d02ae4d56d3b462c7500035911c96164db7b101d6 b68e73babfaa68cc435af83f98d2284c99831e1d1811059153cf25c6300bfd73 a6549bd512f095f3a220530c41090ec52f6b76e29b3e6efa5f016ebb5e351ce2 4f78144d306fd947b921fa14afc10b107e5a801412a5d2332a1eaf2cf7e993c8 baa74a75a26f118ca44da3ffef9c1ecd9d5cedc29cab177a1f0ec58acf6e54d3 4e57177c63fb74e34a15acbaf1cdec9902054f749492c798543384de2195bc56 5002551b52c6d5c5069a7d3c8e4fd9cd4b7d32ee579171952712109efdc2ef4f 1929a69bc40c976d6af90fb956af77b891718dc491845193c14549782f207d70 baa59d9ad3fe201d753e28eb8756a0572500d74cecd1fe5503428e5a925fe09a b42dfa11421be6fd88e96de15bac81d6fa8f7e1390e9671d24540c26b94f2a78 f37bb1a8b9ac908defc8f2771297e1702f10542e6d922ad8332ab16455fa4caf f5c6b246ff8fbb378dd966dc436e03ee22e83e073e60feb916c7ef1be6f424e5 d401423a72b7953f7705bfcf569355b20a9fa8ae340738e98bd8a62369774bba c2a47b8f87cb4a0a4f5e82cc6214c17b517f4ccd556f29caeb8c0e11acf8d018 3e44e313335821c3fcf992597181127d8254a2d74a20369fcd51fe2a5f309815 dee9f9a307808d624145b09b45fb8ca4e14f716823ba465f160da727783c454d 0aca565c56226af06bd0634e969bb950d9fb96555bf8814ab28593f2d4b4a945 4851f7013a4ea7d46d781e219484a43ae4d308c2f546405fd750fa2fb9b187ed 18f9b7d1e52eaa58d78a49a0c0ac390723f975d96277df4a0c0746bc76bf4722 c84ebd11aface18fa9269a7a95a9c6a0667018f78583875d30691d2043437289 c1480a77f6dc55138a9eceadabf7173769c0d1a4e65091244120e51a974238e0 ed3f79eb879f67f6066b3fa40fd9e0f34f55e4aa80edfef9bd8ad073a8e681dd c3cb3b35947549aee8fe3a241ffbfc0cf10cff212c69e7f8d4074ac2fd89bd4b 6111be94c1cf3abd41dbcc414d0956e01a65f7f684abe574dbd4db5fa4afad83 364659577debbcec6fcca437bffe9280a26cae019c01b25d393ddb46e2c09e36 80a3a7bbf4a5908867e761e225a6fb9dc3a9c2226bc68b3849e218b936600a63 34c1586e152e84ad68ac0055ff6142670f2c51a47ffa4dfd8e84d75c289339f0 491f9eb8db2292b4da6ec54c3034e60ad4adceaa7dfcc349ab0964865469a081 3de15284d23d101d02a03b16a1807214b708d79625f86e94f26b234b5640d505 3df76b00b9cb3cc1b46ad08692192f232e1c03dd55d22aa6b3ea3aded2c70a11 c4c8dfc18f4b85ee273d07a9297b5f1c104958927b23733086df4510a1346e34 a01046b12906857f8f789d681c6ccba97526fba5a9e742615484b6a0a32dcc30 7a5215e9d36be0098e4300f29b8601f15e0d0a6facd899304cdc3de814e3ec9c d2f294143c8e5d56780575ba06ec1d34a18df398124397a8d879b59683068a47 07c357f1bede1788569651f2f7ca06beea3096bc5463b4088702c74cf978bee8 96e0d99c2eee8ae2320d4003ccb4903dcf6452baf318df5d9a94f2d9f30ff37b f77a9106d680d73e835b6f23ed8105621e6c8f0e6b02ac5866e439ff3d2ca4fb 32a9398d5a04f507f5f0d5b82a5284492768cdf9a89fbd854c28a459604ddbf6 f6586e23df3cea929a96396cebb03a4321773d23157805edde975290673d8ea5 10f071c04b645009e8b20bafc37324525e550519d17e132253edd3e920b85b71 c877291e36710b5b57933ddf718315c1a230f284b3a1715f858922b37f679508 9ec69874fbf3dd2c544f77fde18775686d85c92a8fa52582fa5f444c5bea0c13 1c593d8ac8b0bd96acde9b9abaa16a05be0bf604c4de1af77ef6b3c9474a5953 2ba10e8d4a05f8d9ec7a6fb545c7b6a30c5a83916603a016977c65e2b8b4583c 24489da237d153c0bbd8ef1009604ecb988cf319de06adf1d24237642373154f 2d6723161b35ecf5d7d1b4ba6bdec9931681cf6dba67c7fe7def2370b7b4f73b 8eb14d2042323843e69761f015940120dc7edea9ea1d6ed4a4a43f4b31e7e692 91cbbbedc615e3e2ef453f65387e180686b08de8cda0a9f761e02c4b76db484f 010908f6f97d73c2154f6083abf12c907415d199ac9df6a157d511f8e2f5d1e2 0c36ce7da69a8457263eada6ab152bc6928b3357eda17314dec890bda5fe33f2 3d0dcc823480bacb02e7b56a68381216f0575cfa2491e68afb88653e349b7574 5b0fa711360762ad8bab39f7e498c65c2ddc796b156dbef72ccfa3bca4789060 ac33f0179c0a925c4697b490523066675bcc40519ac49756832fe73b948af61a f48ea20b775afa4e4880c0cd0001d9ee831e7e0baf5fddf12aba12b5c001108f 16aa342bd1df76ea2f8358e2e5677997c24c1e467906da82c0307dfda6b8c40c 14218c9a98057765bd154b1e6083ed7e9507e67b97d8356cd58c2bf8f68c95e5 b15be7d43577711932f33ae99a99f2329fef451c132651a7aa44a52d0ca8221a a6f8d53779c160b61dcb747863a2a43e96cfea88c1203fbfb1e36a19b2bea394 e9160bd9731ba5ce87509460aefa03396e314de7fc90d5135caba197cd3d991a 5a899d649f9f0335f72cba9885bef04d314ca20740681c0e710cb590494289a9 b331536139b1cb2566bf3f2d3fafbe8016350cb9938ee87e926bfb9b07401d5c 244cd774103fd4a713d7080acd1639158201f17f80244812433e4fcbb69975e8 3c9bc26bd7cc9bdea6fbb29aa52e92177f2cccec409ad1c5d6a3608994c6a8d2 65704ddb492bbf5b580e2c04a8b0ed36b75c8f10569b06b7d0f007ee0f7162b1 f7c3f8d1e7f496568b53d596df98bbd2983337c5b3b37208e1ed4e2f5e9c7e73 dd498e3a3400b34d32240e491bdff35ef7c2ae9e99f13ca5f7d235eebfc6bcd4 5695b47bdf482a792eeaeae048175d3f7a5d51f0dba4f4dd4fcce2300f7df8c7 6e26ab36686e73d2fd29e2be23d577f7efb01549cd5462e69325db648fc09bbd ec3146f3f80a7d0b958c02ad7276e8326d72806570a85131bd0ac4d4bb7b3c16 6247e2669ea62d3bc24da1175f80dc726f29232e5f2136401bc53556add83245 4b3d1b54e22a944028f1c1d05f1741b519b63ab9d2881508a0ae1be515890fdc f8a3b82cd99565335d3120501ae01115f1c0f266a90fb3498528d67b039b77e1 9f050a1cc1837f00f539f65af7e85c57fccbfa054355b501a9f0529b401c86b5 350561c16628c771a34b86e99d3941bc37beb2119f53020eaf71885220216b47 8a867e6d2c39e5ad1d92d8c629f1e851e9b298f1926ecaebff6b57a7f4789cf1 c8c3b9f87c289ef139997382759d991de9733161169185d546ff288e35584f61 d44940c799e1f9bb8591b49a7f5cef234c454e6d97c8879869ce57a2e30bad36 f93a34183e25f0e60a8b9f6ece0426143c0ce94b9545854a8e7ba93ef5af604f 10204de39608915f1826a42acaa4c2ed5840cac6cbb3d65706ecec946d04f6c1 923e1492a40d7d39a68f38f4c5baa982055b5f6e419167a55ac8c9806fdd90d9 5e0f783ec4d90ecf89bc8a90689fd3116c4102a002714822e2754168c70a3cec 69ee0cda813ae34a0c01d46bf6102dbbbfbccf6b9c50fce710621fe2a330a014 0577eb81dee01567a05356cf7433d68368687b909e54f495382a478abbd95efd 17537dbfcc514c43ec522a7c0d0b4829809215ba6a4b1854ca9aacf312df139b 931a1d1f97ebce2cfc6b0c713ab0c7a3c9b9cb543c9f02f316e0f9e813ebe130 bfd6d4c3c7d6c4c0f03940f07548c63226d4327119670c61fa954e31d0c4b47f 9df65076a6a6a672a0fea7cec3de8fd40f1e3a3ffb83c3882c334408d55e788e 0490b1b49c5ca75e2d154f8c507c2183cc7ceb98864c369f29b116c80e80a14b b0a1374c4258721093f386d6161ed32cbc943776ec1136b2bae812ab3f949aa8 5bac47f1a2001f39acedc313cb8f2f1156a8181aa30d86a80a036b1643e5f18b 51ea5a07ce06d972081cd015a348a6e69f963107f5d166e673d96d7f9d574035 667feef40096e9677f12a0ea9cdbbe99a23beafc33311fe85b58d309de9c77d8 ce1a4b104434db0c7e32719b7fc950b2a4cfad52ce167b6acc8c4a84a532a215 13df7b1b28f6526351de26955a0e01924f4e4fb531f2d28a1c1e6312cedaf8d4 a284a26de3f4ce7dc313f34121f8204a5f627c99c5edf0117998b42f315b95d7 016c95d5d9f20415292a4e4f5f74c0ee042b3b7791be00000000000000000000 00000000000000070b10162026304402203cac4b8b860ea4fcc49913a5c28ced 206f89ce54b8fcafdc7c3351afeea6f8ac02201791ae5d55c6ef09d95be88a1c 14fd4816ffea3d3b4c9f70ea9651ab9066fcd3' ]) ]]>

ML-DSA-65-Ed25519 >, / external_aad / h'', / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573' ] / Message representative M' = Prefix || Label || 0x00 || PH(M) / h'436f6d706f73697465416c676f726974686d5369676e61747572657332303235 434f4d505349472d4d4c44534136352d456432353531392d5348413531320013 bf26c18c38c85eec2ea1676900c4e51f304ab5d26947817f2729d93ee9eac71c c5ba8f35065b5b44b2fe52c4dc3e8b686dd0098edb8775206a386db94e305f' / COSE_Sign1 / 18([ << { / alg ML-DSA-65-Ed25519 / 1: -58, / kid / 4: h'93fe1616a4131f5a' } >>, / unprotected / {}, / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573', / signature / h'87d1c8ddc4b0604e2ba43597c743bd02ebcd1529c00a57f4064a22258d676130 d05cf245a6cd5f2e85bf8f9baaae3d295e50850618166f07480cd182a0a10c28 7f9dd0dffd6c14a2cf60a89165997d6659ef884d71ac41d83d52a5553002c890 e3edc58e8e828e194c3573fce2dd6044975d8283b13dbb6c7642401ef90a0930 89d7e593ed04b0766e755b3edd23209c80e1998be8accf72584d4a6e33ab0bd8 1fb530b49d24737ab7cbf6b03db261c56163819066ee14a3c7d0371ca742470d c7a33a08a35052eb5d3e4ecdb8d8950b9fbeaa694e5aa0d9b7e45ae09d6d92b9 d51e99e2eac4334ee0c404ecf28f25494411f7e6288594657ee2fcdc4fe54166 f76dbb1f2cef71f430228b161bc850ac43bdcb80379658c3321bcf4a7379fee1 dcaaf46d16693b3a1262d3af45f1c91f80e906fc8124aa269540dbf287261d7d a562a83073a2f2d4160473219c4ba41227a39f480bb08e61ad59300996062735 c9df06fa5eb4e7830e7d7dd3e767f07dcb6fc39ba9a01409520684f406bd2f2e 1421730f547e5d92f8af3b335d70580c6a6f452cee6aa44bd0c440145a7c2b64 cccc8f8f6d3258d17fbd4a1b87fd5ec1bc837ed275a4f6440ab230e996817f25 0bb37a078458ad5c747513ec52dcd015ed64dd03aaa5edca6adeb144336863d4 6f36385099dbf6f1b12dca8241d8819f9499a702f2cb5a7a2d93a2714ee4ad87 161c9d41104888c483c8472cc27ffb5c84fb4fb388ee14de18cd4796c247b676 df4f4d59e489297777d0a9130b3815956d18167f78940b2d355469806ebae845 c4be54c57ec14eab7a0fcdefb6e20a96ffb6d637d8d79412e9dbc892ea89994d 49cb08d6a0fc0f31296f8930bdd74f131eb19a3827bcbe40506dbb2d4327100a 269501325f86303289e4cb0bec2c5024ba23081b6610fc0bfd7605bc63101143 fa9833ad55aaa056164d097eefdaea0f56826051ee9a808d983cb20572da144a 884acba016749c3962d2cbb5b6cde867f7b31b19f78443860f145da2536358b0 4bfa2918283cb278ae401af937c6aba3d9089ecba820e8299935fefc8997969c 6b9be7220a306cf1f7d8cc492b06f94ef7b43a2cc3e1ae3f0d4baf4e558a6769 80dd130d7c44b92dd99804e342d0f6078872badfbf2580dd86a26fc10495a69e cc985ced0b34248558c5400da617ea552f8671379b788e1d09e8e83575cc32cc 8f3ed81a63b4c945dcf2ff54f3266ce28089f5f68bb0e49714ad9ef80bc8aa70 20da6a038e66972fcf335742ad8dddc8b959620ca177717ad498524cd96014dc 15514f514cf17f0433db1127526f25ba17c0938359e373e43998169bc99a07bb bdf1bbd7c363cdfa6249ce1bd207923cd2c286994ec75e9f26fdd0ff752f44bd 011cb3e753fc0717d11f88011a0c84db8d88038c351b91931ad5cd477e02859e 01c4c2bfd9945de2f1fb067bef79e430f00b069dfca02c2533e56c0ebdb47594 83155bb7e45ae86f47eb0fa051cde714833c9a0aef8deeb9fb98ddbfa3d8f7d7 86218d54eb9593c4011d38d5521067bfe03a3859d3606b4b3eb3b2cb1760b7c2 0d0f886810f3656edebf4bdb1c51711aed2f452bd69cc04546da0922b922670d 4d9110ea24986b85bcd6c707146022863ad85556e857f06ed6b0bd585f89c119 59ab1650851b23b773518ed9bbfdce997711940d47f915d0bc11170a0babe85c f6d1c272e5d0573d4aac2e595579c7457e4d6c881443f472cf5e865a69dec3c6 69d8c1775a86b249cd8f3618c9259add0a71a5a82c375137067e0ffe4f8d544d 5a825c1a64ec33707da7e3de4ffee65064711c4e06626e66c85ff13ed50242e2 1917a2647e47b8c158137e716ff308b207e80c95c3c8eba252d00d5d475a130b 931d11995200ed0e2a24a0795c436a997f00b6ee47ce6ab66f53502f64e02180 dcada208f21a584d703a996c378de45964768200cc42c5471f07d9d82652c826 534c6c1a7619231b073171575dee7764a274033f066ba6051a87cc864e2d3033 6ea6a49dcebab9de149ed8b07bfd3264120311b3bd9a1f05bf343e2bc1fd4e85 64e6b8bde25fdc7af3e90db002d0b1b1d98760692dca483af82c337e3595f714 4668cea652cd0de44ccb9c7e367dd50bd5fe61c03a3d7cd605552a5d439f556d 600b60b6f1e984a6af1ea083cee8dfaec7d1190b99423320fcbd92bc884c4b40 9d776eeae6dbbfe0864237c5748a243eca01c2da9a6c8d7d5a832c2acf1989de da9a75b6218a5074d34e769d62a12a58aa4e7d805b1a44b1fdfb2d4e90890865 5a3b063593d6b9d02ca57eaee51e8ed1dfd424ab35a7ac80ebff839167e33e19 c68249b6a54e9f7016ad111f13a0857249a97231e37a860669bf9a094093c8b2 0d721e06ba200691e7e551112a90905fdc7b083b36cbbf4647aaa2b66c9f9e5d 221fe1ef48a46b35df63898383f90a99eca53840aeb71df47849adbbb449a707 7aae229aec51c3674ffac50ef6a8c7f047b382d2da716b32c381168c2799f650 779bb8532b470fa81091a12fc9ac43499124cea67dba8203b71b203b8ede4105 c91e13d4364cdbc7a7c05c7b5ca38a0d1e55389286b54a51ca5b53b73c785ce7 8a4d854c6f37d5bb2a6a658f1e51a916c9ff573cf23b11def800792cd83fdb64 ed773010ae15f5bc6890b3fc5c2410998d6565427823b200b2390aa9dc209850 b1da9152e97f3b87afb356cb86b95fad6c5eecd1e4184c0f8abf2a8d1b088def 6a973f97d5c6210e8a471f82a246babba14774e1dcbe25da51f0ddbd86d1284d 0a6f1d4b4e8056d098ed7cd66acff2e5cb54217c0a6890f36fb9ec70f08f887a a437395a0efa9be575b05aa37187a4c032468e539d637eebc998b5a026502a68 fccdee1545bb74bbc518e5ac5f49e607ba8c047393160f9f330e2862045694e4 521beee46a6594bbab59802d93377b7158ae7803a56b908e98879ae6f94ba2e5 ce58d7c3367ac216391ab60592b690bf936193cb25cc6ae23d7fda0089b485be 1790a9a3d9198036597e7315507c637de1f890566bb8ba1adc00d4eb2623ebc7 8849d167d5b6a69e8b8b541e252963404c62c16a4476efd04ffd49a65e44a030 c4ed134878a483ff369f5553a695bcb90f31dd0bee1d28a1f240950ba9cbfa4f c53015f98a04ddb3a69ebad552b51604fb864d636fd1c5f5758416cfda17cc33 049b1119cf82706d28900a36e8af5fb6eabb01ae2384237c136aad9142364886 26bc3fe073086a1dbc64f7f39a9fece1719e3a3ab8581c964f6470c71d1008b4 cad337ecf297eeb3978f4a9618073a2ed4b6df84a2994c2dd442d8eb233dbf8f 7aae015d54cae131bb575c5031ad8c909d16c778c95d95ee0605e255d0f1d8ab 2b8f1602865de9132e8f52e667001b1115b4fec4df86b7c9dc02f75ad3f85757 c4202342729e0b0cd986f4918d2f68d607a075237976843b80fbec81bc1592f8 68682ce14bd9afb31c1ffe9baa5b23bbcdbf9dcd3193333f4c600c8c19f53c34 c43c964bed80149c990f9af7b7259a37502d8671a1491c4b3faeea8a8c331fcd 73c3ce7f7c4efb1782f2a78f117e174d498ed5127bb043861cf276330dcf120b e7435ca7d62ae7b7a2ee673931bc891df1f3737ff8b2bba6eb741cf37d279c0c d41e2691a8f4534c02803ea720b50d4339d75ea9998650c8b30db56e95333875 6b8dd7a242c95e92fc8825bd9cb2700af12ab75a17f73935b9f8013ec6f8a6c0 7d2f856d9f7a02ea851b71452d978c7eccc3de248aee679021d4758d12379811 5d6690040a57ce722b0e8bf6b3b63382615c570da0fcd7d75f228878020e7c40 b3cc8b79d2e6e5b0b520b928d1a717f0f4815677d5f3978d309615cb69cb3faa 9b596d4b48c6ce8edbd73b37f0cd002170b4bdaca4d05b82d7f5f41a8c6cd9db cfc0567d709017ec13ffb54a598b52b0d0490c0731eb01554a4909004501aded f7f82d0a282514d03eadbea6cbc3c1bbfe8aa56ce1bb90611730f644debc8976 e064b3d2a380129cda5f290f95bbc47c5420174370a1c2c548ffacc1bd51b0a7 aaf8fcf57c975044b74df7a462dcbb808521e935b7ca4dc663208c0859fcf5cd 3e2be1f29b0cf5df8e5e348d9983889924810d3e4be6f51c365adf3b6c015058 8899f4d782daca9b4231fc35ab5c9445d25adaf773d20ec893959306d6255759 dfdb26b0625cabb2764f00b58afbbee7081cf35165494fba3cf6248da5e24611 0c9288a20bc3047e99374e2e6f70752d707a377d8846806e8626bba3891f6ed0 884a601fc27c5885aac1b46919dcab0399b60c43cb1b8143b798e1eacd1ab663 e2241d4d228230dd53211bbee783fe6363122a001994f45321b131ffb91ce395 7b6de21342cf456365e59863f90c83ce7bc3a565a885eac0f9b34fa10c52418e 1d70a8a065ec5682c48eacf731354c0e89823e94ed20ed7c50e4ffab56dfb578 04c020649dedf5fad3a764fe3f97901d2e56176facf69ff1b03d2c645707c6f9 165a6136eb1cf0ad6eef6d315c479e3b717fb88b254528230e54769e758fc4d1 ee611e04884c9c2090a23e2900c56a48011a3ab7f3214354676ea0b61c5474ab c9d9fbfd081a30565ba1b0d74e8a8ea7cbe5e90c243e4771ef00000000000000 00000000000000050c141c23296fedf9de10b3aaeba9ab0de9820002613293d2 68425d7a34c3e2aa1cc86d28ef32fc69b2f842ae14de62f70de597c2b16cbe61 67d2629dca0fcc3cfb0b6cbf09' ]) ]]>

ML-DSA-87-ES384 >, / external_aad / h'', / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573' ] / Message representative M' = Prefix || Label || 0x00 || PH(M) / h'436f6d706f73697465416c676f726974686d5369676e61747572657332303235 434f4d505349472d4d4c44534138372d45434453412d503338342d5348413531 3200bbabaaf08599f673a61a129dff4e96c866ab8c91e80e69e099425785cb2d eac04139c7dbd1e3c73f98b266ed8a3a2fe2540474de88cca0c9729bee6c9142 64ad' / COSE_Sign1 / 18([ << { / alg ML-DSA-87-ES384 / 1: -56, / kid / 4: h'10da59a01e274d3d' } >>, / unprotected / {}, / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573', / signature / h'c0d61764f4117f858818b80a1d418d0dfb91cac5e4cbeddacc6cc396a4db3f9e f9853502cf7b08ba48cfea1be7a0cefc1f0f8e63b773b4cb8df73fd85738b654 21a7cd0075feca49be9dc113db76bb41f71bc2d57d8713584d61aed2d0b98d67 f41c49a2a91c41fe36bfbed30945cd61ab42b4b3ad965ea45538b40681e479fa cb8b82441aba8d64b43b9617764df001655e9a3d4d314d5cb6eeb0b70797cf3d 6dc4a2ff6cab59bf29833f447eb13d2bda8f6560debf06e0d7f526bf78a1904d 6b2a9c21a85cf9c31551dc3ab113a0806e60fe58f839fa4024a9faab1c76e0b7 42a869f1b72c407975cfdd04b4e9091523b7bbfb6111214525aa198c2c46a685 6cc1727f49572b0a7c226aa913eb5d4a2ab62f50ce55a2a8c5e060dc1ac73dbe 26bb0b8015e287e7c43171a2f397aca587a8de87b976da79dd0733ce60845289 84acd70fc79f869913e9a973f0e68548b574500e3fe5eb0ecb9ec0d5e7f93750 b8a9b35787b6160b3fac2a22b96ab89150c13d755bcf9e3993d87f13a42d1ef0 c49039214f288c46ad4e0df32a755f050ccb36613aa9a90348a7b09f87f5d3e7 9f67d1df50cf792e59ca42f0c19ab3302b54eb93601852aaa0795177aa40fdb3 2efaf070258c7bf469327b9115f7e505998a80651ff774e998ea1a58de763775 68f7d82662799920ce22837c6c065d150fd6a0a3c11764c93fd8ce6fbbf86df9 c33e604fec239a09f352001bc71b71349dc83b06a136f17283dd27bb5a5d911d 36906c4afd4eb52a40b83c6ed9bf37860c467c5d49c2fc07f2ae28d07b6830e4 aa6f7501f1ad3de07868ec927df0997e676480c3672cd490fdf58a1d38651a6a 0f412c68ec53b6204678f6719c88bbfd76351019936fc6dc00491453cc38cd59 a22a4c5a70828cfb31d7929ad31c7abf92d928448938bcc14947907a239afb3d adb38d5f023d3da5b04e4cc6e2e3ce211a14a4517acd9c24feee0b7891f7fe56 bc7a655d61bd4045c4afde430f66065dffc77eeca15ee0524fa8b0746fec97c2 031707129cf181aeb96973aaac54664f65fa0c2c3180a87aa9e4b8925dcf2815 7e3f2aee652103a14760984c82b9c8a2799d63ff8365a6c2457f2e636ca5cafa 1ee07f4ca5f178fe6dff55a83af673b9a3faf25e263582323d9f6c21e5c0bd29 b4c11d0a9bcbc911a58335661be37f40da4c60e15a5ee2b8e6d79e1f468b1d73 6b75950330ab8b35e00f1fcd63334a555a5cef77964204e84bb3687fdd6f763f d3c963da8d9b3d6e3177ddce707d27b4aad7446608c1c28409b4fafcea397b9d 109af8a58f2051e3f75797549daa31198bd17bfa3ef40f4424e20d9b9694be25 c2946edd6c0d47d9b92154bfb12594ed7e7dd18ca0387e5ce9dc9816598ab1b4 c3edff62d1070eb4a425a57ef123166fea1926479e987a4d25baa01a87da8544 99f62897e82082fc6324d9ce090fabe9711897c194438dd82763c52f7285eb21 073910a6262937aca4f3a23d832690d81b33e6231675bcf7c3eb55c7f2897e0b 353bb0a9c42ed4130fc283757672c44a032d95893cc2c1e2144b2ec591f4a5ac 5f87bd64a99f2b9030a6318ea4da8c20e11c9561448a08e381ad07392a21f99e 669080b51f1534c616d896f2dc7099b49be62c926bddb07d7943a35685b2cb00 c2e2e8a7a45c55b8da936ab1579277a77d951848a40f8e70287903d6c5dc7830 ac6cee48c3766933f141cc31e499ffb12992bb3fa0376477d1f5fef3b7e22abe cf6731acec6f3cd2a8e2fc20e1c32088a615f54787a0edbb0b6ad01e10446986 80e3a17e52420939487a55b1c4775213a709de05a51a6e644105b9c09ade2a65 2892f7d01bc7e48555a1ad7e875bae864fac68be1603495f01e5b548666902ed afec2daea3e15c2c1ca2e44721bfeb37f45627103236521e1721e723f042e033 e900323cf6d60ccabcde46245eaef55e59149ea7b0bf79847d2f065578b70bc8 e94702f6bdfe40b4c178138d9a5793319dc6988e1b4e66e4b49f2f30c0fb00cf 60e78abd030993f6029c178dff63031d5beb1c910c23f1dd98f8aaf16806ca28 abe4dcaa7c7b788048b937fe671856d7a2377c1da51666888b2c81ec1e7ac032 2d9e8d7b12a6bb1fd8e1a68f3d0aaed52de2180832329697a04e8343818924ce 88721ca96ae8847ed66aa06f5b2858b89525d0ab782c60e879f8a8b311ef5060 9611f13230d9d74e0ea9c052cd02bfc7b27ee62cf807fc25e37091b0e9dc3f7f ac101df5647929606a21cd7466888816eb0547d48b02281b473dc6f3decfee6c 059cf9b42b66b9da9c2cb20677d3bbb5d764fa21a040ff87c90213d1a1d80d1c eb9363a030aa0df508c06622e6180eebfd4497e6481675e2c06756f71a01658e cc5f6934ee10993e005946b78abf172298ac6714f60a0b57b3382051664cc54d ecf4d4e1868a78874a64e6f866526051d5285d39840512404d8c6ab9902eb6a8 5e4936b4b6d89ebe5e7138a6597f65b44821a49e5c5648cef772a17348fb419a 956f5efa0614414ef6c77d95d3ec6dd7483497a7556e4324115fd632f5d30c96 4a07ab8eba3c101847b7f39638b1265d6eb4cd243d0ce79137ad980faf022d58 40851a4b2aeb1d238a7400f07e0c3327fdf92be28f53fc77db3ef35f441dc315 d56b2e8e919e655a456fb500c8649f39d4befed9c4ee234d887785a001455243 86f7d8e2c4446faf99d40ecca83e50714bfaa78453d213fc87b87db336b724dc 50026013b48bf5fc1003602be2d29d94f7fa3e0f3a96efca1524052f116e9779 a764c614103cb5536db28718978d7e606536f22daea6444f640a49abe5f1b270 6b4906340fb79bd219fdee9f756e9107055b9f1d5e567f9ea3458c2a9edfe908 98b09daa0398dda6b0b892caaeb4144364c49b00ff2b329db0b6c86946cbd103 a3a1fb4c2c8077cd81f1673a4dba25db3081ccbf03e23769d98183046422899d 332e94a186132e9ea49e47ba3e888a2a9a13370cbff2a2871f4e5d0f94f223f1 369beec4700a05eb52e0ba1d599c5d000f907d49b09e37ac84915f685c28fc36 d879407d9c8d061e556f209c0291e109dcfaf6cf5301fa1a169dd4d50b3beac5 eb18442aadfe957448c3c2a210afe388c11301bdec55a5a72849eb9288bef0aa 70cbeb79d99c6efef9468bf00bfaa7f6d0dbf995c44461cd22e24b6d1d70d4ca a344fd4b57895bef8c17f62cf27b92feeda5922b52a12fa39b69bcac22f222e9 4720b1f5d57d274d72a3dc310932f11594f7cf59c199072404d5060cdadd8801 cd292189ae40e349de3e3acf124166d82bbd4b7af5c9ebdaeaea9a6713833531 0d157e2bbb46fd2b28d555d91cafd5fc397785bad3e57350d5238b509815c390 b7de0e1927327b2b1f5def273900ca13405bd342e405d156bd1b79beb53d63a9 6dc377cd26cce22355a1ce0f23f1a5272a6f264a7a2414d56d81832649837972 6406d3b3d7f025e3f0736f98087e3ac533e64798e63e74d22c0635c2baf5b670 0f4934efe85e8fc0123e0d239aeba0dfdca64fc6879bd93e1638117c5c6c6d17 462945e1d46607691dd33541924d4e6d9f77626a489d37d88681ff6f1318c5f7 183613d4cf8e4e263026a8d6cfde54f7ba4f70e68e286c882c134e13373d8695 694b53aa21029f329322c13f753a5959aa3224306ad3b2e71fecbc63b333777e 42958bbff88aa9a97578ffc3bcbd98782bda53e27bd629edd10b3bc59e680703 fc03acae032fc4f5e0bace98163b0c52b4677bf651f0040cc6be7f66a8d4bbe6 c2ea590c1adbb4b12a21df9d4367f8d4aeb43c9ea763b406b4c6f467db2007a2 bc7f2a410c9ae9648ec9b421f85d7e2063c23b6e6ba8f218106e911bbda38fca 4aada43eebbc0d4923917bcae82a55ab4484cb11b2370732911d98cfa7e7627f 9654ce4e6f815a6a0d2d6dbae97b436b736bf2bfd31b89017a209c321c542b15 255ab9c869b6a528141b8862a52560bbbfae22c8b6aab04ca18ac8647cca68f6 38aa0ab7f01f8407787842c8a36be4ef9bc0eea5e201267ae93f76dd6aec5a1c bcf82d7acadeac9b9817abbd5602400198dc97937cc07d35554b84d52a99f8a7 741af3d412575c8dcd89e05a436cc2a7c7f048b589d833bb9f327a8db83a458f 47c424579808781cf95b1d0a65b816a0656f50aabb07991a63537952ac5ac964 c27af35ad72a22650063dae2e1aa385cfae0594e6358b3c6728f5ec90d0d4080 153754b850ef61ab85bf994e745928274c611c43f1cff9f2798c2400856f657f f6c298be5d8131edb903d7fb53cec5fa4fee8fea1add2fc057a6d3d00c6322e2 063e7377675706203dbd8412334594eb1aa9a320f0127f950f1d28af7ce4b014 04e843510e2cc34ad94040905516b87fe221b8c05faedbbeea6ac5ac738e4301 015410e1dcef82925596a50c9587ad7e52be83cd8faad6e8d3aea6e199dfd19b 4c231575978d1275b34befbb0a58fc4c7d3d0fc3faa49f77210d9d639f45df1a 4a7a0b12e2e568821566241d9a77e47f6065bd987a3b1a933c6e8d80420cd2c8 a52b49f26a76327fe98aa245f3d5f0cd33223d87a38024bb55cd2da3b1b123c7 c48b9aed2560a9b0c75c93123cddddf2f893993d19db066f4887ecac6a721bc7 768c16f3e8aeda165e1cdac8e232adf6b87a5bb8833f2cb6eb52e2245911d276 d238c7001536119c7ffeb331330ba4db7f6ad8dbebbaef00e267cec50dd9c24e 2ae8b776753592f3725b36259377767f7995860a6b2d278d091a423afc941d7e 14fc1709e8494d7825fd526097321f04cfd87b90d7aecd745ae454e3334d1fb4 3f039666c016dda2fb7701ec8a76da63fbcca2e72cf3ca55c87262dd309c6742 f6fd3c6f9ca892fee69dab0d23f553926b6a756b5b3c9947cd93e8db21547748 85b6ba33a4e405c140ece61d8718770d6177396a1f5699bf226f767f11e4dfe1 03011f89782711440792ffdc685746d5c9474b6b9d3127f31e486c6c25426ebd 99ab321d9d3727eb494f2a6e4308d657557a6128d15414f72a74c9c075afe2bc e67aa7e3bb7517ff1c31f9f31bacc127d59a64b853ff3c1db74188efca83c1ac 8dfb50db5c9487729f8231f6e2687fa3f2e8a66132e729be4cca18bc99bb0794 1ebe0be96a25c13e466a31f306e03a3fcdd014c498b28f522ef0af5e34c775c0 15e2c53547eb77a725310ae10290822683c994d9089e2f4fac4c3c12ae7f5afc 6bec064b6896c3ae1fd856d7a4a12e768e0f9900f29a58e31f0c69888b29de6c 44818a12a1fbaceb29d4be169c570aee12cb645c4d64694a73dcd4f917ff975f c3196d438770c09a02b52ac2c9f88895d14f58e279cbaa63effbd88fcd356633 9882158110028a63e8a3e689d1d0637363d9e2392c3f8a87991cfd25b183eef4 88248484e509eb6136a8c063ab3d6a202c763dec6925fa9e41bc9a7104ab0606 056a8b32927d47c004eab3a55be198b5818408f55993ef833702e4db3c052c88 578190b8879d4a599fbecd6b2e01c9be1b146b145a9f624084fe48511c047064 0fe0d036a535cb0a09647591fff7bf40dae5aea121177dbfdf0264b7a8b84532 28754af3561b61533a5423f4f9641f4f8cae3288587e1c8edba15224acb695c1 91441675977382d922dec3c15e50f0a9502d95e0721e57b46e79b2aa68c03112 a22491fb3bc84db239f06cf64ee179bd61ad93cea5a179bdedacc66a8ec28b84 2d28719110a5d48be8c9db42d7e74ddb0fd99b17cd5ba60efa3d3b1ef406b65e 3078ff9fd59e4db1f0ccdd61fd78eda87c2876cb998d8e38d56453112b975c57 cf8a4d907ef06ae9df52cad6596d7f33087052c3fc0445a30029b8997350ffa3 fbf14781e5359dcbb3e4baab4119c335a7477cf14eba23c65f783e281fb2b0f6 6356d85c597064bb9b68908fade8d1f1845306a1094da620a693c6c61bdf87f7 60a9c319c7376e0c8939b92fff1bffc3143939f871500a4b11b7adc250600c8a a448086b6fc629e95a7e2633b80df5dc189ca800614a5b6fd2e1dabafc69798f 8675a851cc3f73b42f6ac99e4f48c6fa596f96b8e46aa1ef977bed3182b4baf0 87af5b160a0f12300171fae57df2e845c785a0427ba05388f55c6321b88587dc 7537f2099998a6b205cd1dabd484f95f07f48cfd2e4fdfb2d31c69acad42d102 e909cc27129882004fdaac32fd5be0219b5a20bedc038ff5bc697c04c8341634 10039d16dca4cd0ecf1247dfc5b85a10d2956c24ba5ea458041f850b461e38ba 82c9c98eeb509ea9c782e80adbaa28f16a0c6c57294a28b1912dec4f702d02d2 3faac7c33bf407f6d3bdc5a95d2cb2f66cf5f5e5f341d999c3a0f5e8eda82886 76d7fe9fd9fc369d8a4b5cbeab254c490457691a45241ec145ed7c56fbd541a5 14193949627072c8d6272c3b46cbd90b247cbbd6ec1646619eacc0e006233568 a8bbc1deeaebec051f363889d1082e395bb70f383a405f9dc4f0000000000000 0000000000000000000000090f151c272d323a30660231008288d16bd680f871 f8f009e6ec2938f0e3c250c3a8f657bf9cf70631a00fc1cb62d1e58b6dcf8a07 6ef61e25379ee89e023100fb3339e0d292290d12e5a036f37951d77d54a614e8 fbc666834433eff74cba5f71dc5a15e35d4a31b6d404238d79f0c3' ]) ]]>

ML-DSA-87-Ed448 >, / external_aad / h'', / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573' ] / Message representative M' = Prefix || Label || 0x00 || PH(M) / h'436f6d706f73697465416c676f726974686d5369676e61747572657332303235 434f4d505349472d4d4c44534138372d45643434382d5348414b4532353600eb 80b80e807c0f16622892f1601d0d3490d4bfd302131d01a2d4bf7bdd3a779cfe 9e8f724e18e0c40bbcbc6b765ec6e265d470334456a0ea65eceff85438207d' / COSE_Sign1 / 18([ << { / alg ML-DSA-87-Ed448 / 1: -59, / kid / 4: h'a03b6fee7d98ff7a' } >>, / unprotected / {}, / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573', / signature / h'f0daaff4a8ad5dd198507460ddf682da14042e8b9b959e87f288c0d1ba23988a 74dab4714bf83ce0e08faf21fa583ff32a17aaa82b47c20004b8a1b5268ba2d6 1090ef4759fb88aae86ca29d64b37892a213ecd7e42f75c2c309d4b600157694 5ad7f4350a44a4f695727ad919d663b6e9c316c00bead18dd9a612ce0dfa30d0 ffb38883b5e078901d6c316ccfc2f68e833b20e344c8f0d76f197061198434f2 60939eafffa4004fe6ba52203cdf38576eb0d0ea0663b4faebdd447aae574fd4 e4b415e81aafeccac2461099679dcc77cd07bcf7eff34267646aa1b603f8b304 783a36c1478ad7e09f545d0f3a9c56f89433d74a410161e98c5f94bb8e0a15af a09e89d2460a7f5cdd28336fb63812dd43f5a58f311e4484ae4e7a543e11b134 124a5f85c3b3c7a46270e2a36c733378d8b94946ca0c84d32c40c60430ef1d1a d34c975e8a919e978eeaa001ecac29f0e26a5a96cbb33686101235ea18f293c1 4c4d1d50e1f8f5e7ca656e216aa363745707549d5ab5e423a3e5449506e56523 15343344da1c07b6c57e2da431583b21a3cf43d03a90ffb7cc58acb5eca7e801 ad18a8aeba1827a799dd44054c65e512da40f00db77ec3757a166147e077bdea 275f64d7e14a0b9c1fc69b58e210450b77a0cb4ea1659a84a42c576681c6cb6b 962d795cf2205fe460f52a7bca3956fb583ccc31a1ef753dd5418e7072f70000 77a57c2c286d6c6d7e04f5d3f71504bb084a88f2fd99138b18cd6d94d0b9835f 920701a26541356d0b2a5cad75e07726d41a5d2cf97ad4634f120800b766ba96 4b905141d163c896a60d24803fe82b8acaf54850e5094d14e3c5b974f6920b27 47b8ee0f83ffaa7e3fd03c83c38cf7f357590e04cc58555ff7c7d30b5d81708b 60719d4c87ba37a02f3b45097b92b62b96010736a6b90d59d9c8dc0113ac6bec 5858e5423b40b9bb5fb6d56065681fcc15ed8662d99448393cfbbbbff3bfbd42 1006b33c73a7dddd825aec52ef8994ae51680989514b36e41901fe2fc6fe9398 63e683d76777a54911776a1243293d3649401742765835acd99ce355d156abcf f04b24d7e0e3b060086abbb44bb1208916712cd78fe969ed00bcd184df271dd3 5f2af483412f77e097de302e8b41503b00ea6c2035c1a6531c426b95946f792e a7613ed9f441d7bcb0a1988e337109f7fc4b6cc2a3d67d36d60b8f3d8e378f61 3e05612ca610ca8ffcd5a87c1dbddef704da1a935e8f58ba0e10613bc321dc6b 0be699755891138b5596da7b3a3ab73fe196808e3cb37e3d7f5c57bccb7d0c0e 859291b87239ee764240f1bcfa75a9d777fda1d15d46d132d4ab77ad990ded3f 148780db9a262a79102023990d863eb6a8d20a267851d704fdd264c989c39038 a339e41ba89e1600869df1c4c5a5be4476af6feac43fd98f3c7c6be37f3d4118 d8555c31933c8bd87c57fc8aa2ee0cf1ce6ccc4bdbfc5eadde807d22e1c4fc4e 8d905f77cba4acb88989384f78b966d8eb511c34c686cbb542172dfc616c5789 950c03c877bfa62729e733c0acb945a4bc75479afd0d3c2ab8dab5947d507322 4500ab781c26a817983bee7fe704c939b49465094957814bfca726354f1ff25d 1c97040803c28cd0b36dfec32b5ce3e0b5d47441a9af3dc63127bde4caecb23d f954ecee58b68292f804e449f672449a2512bd89cc3faccfeffdb288fe434c03 88c6f585d84f02ef489a10cba22639ea252ad9a61e64b2b11672c6b5ebc910ca 045779a2b1de7f5d2587dcf8a22e4651e21cd95f0a190a08fe25da94ed31b1b5 928fbbe746f58ed47d816d9a12d02cf91fc80ca28c48ec7d77a0829965a44f84 5139c845876349a09c4909b5914ebafee567582af2bd26e7b0f9c01d77682085 82b123223dff3dd9cb68a7f74ba7592496aa9ee30c8a32eb0c7d15cb5b3eaf5f 94e5e219300ec93ca5e903d0f1d548d47b1caab71b2b2883625442e138412acd 58487062d5d0f4664381013c0173aa16f6b7344df63be78ee4a4a5133fd8ca76 fba958f56f7fdff3beb271cd309c397c3ba72f67305946661a3ac430c8774704 f7af069591f74c3184f6e3d45f37d89ab9cefa0085d46f231c5c641ff36c1115 4ad82c76f81a59dda5a03446af7b25635ac46ba6912bdc4c1dbe47c263159707 512a7b6d91d28c407610c567bb694ba3e5ddbfe63b4220d1a3438c12bcb82ccc e97ac5052748516ee56b605ecfe5aa5b9572efcc0ea05b327d253ea4bee956cb ead080ab735e65ba7894f64acbc96eece3f3c47e6d2d8b44167f030652e4a82b 292c3d1f0fc7e9b4aee8686a3fac99fbdbe8c71b9aab0a5b3121c68bfe89c17b 96c67095a6e43b5ae90fa622fcb99adcd91bbce0f08ec073184c245df0664207 adee86fa220e3d7193c262e9a1c2a8cf58badeb48fe97b9db780ea3c904d438a 18eb72489d6e191b78c157049ff733b553fa7ffd4c47547d3a675b40a93378be 1888690e4d661aa42aa63ab14d4fafc0db81b38584d8df1f6aa8cf45eabe33c9 2b7932426267097a5643a1c7b400c2deebb9aadb42e8fe9395666fcb947e4051 0078068f30f8fd8c8c1fb40fa0fa67e1e520afac66cd021addc50ebd9185b4a2 8752dec586c1661d0dac4a387e289cde7dfe216eeea96e165c67ecfd41e7c560 8c0d9092a92584866230419edf5a7db40fe0526831eb2ee658f2398cc93420ed 64f6bd4b3b2873c148d4d9f4722c24992ef9ef5ea04e86ea0109dfdac965355c 6531950cb497e2b95ae7f36e1a80e9b18f7d9cfbdc98f29404e95235a03709f1 54d8496d0a245ceb62d433901dae95001a95df6d16968db01f0e53f61c69183c c4855eaed460c53eef95c9ac59b69f8be5f856caa45ed389ba9a5e9b65ad3d0b 496ea2fb3c23362ae314cb67066fe78838a410a0378b2ace255bf965ef494475 d741c1f25a610733792c071cd067709a3b70e03e6b443de436f890893a00222d 20223618d680efd0090a386855bd80dea02a7a1c7b9a8077dd8b9cea56878202 7b4b9bd549c433746cbdfbeb1c9e877230a2c7f8d24ddde580a8d25bf15b3ec1 08c5a1cc84ff7b263d1cc36663f45b50d53ef8c50c465faa135afdb99d482906 84492198c47c798e650d48022a66a1d2d44df4194c99901be3a23952c1aa7732 e83b3183b42d2386118410ede7ebc8e738cf6580ebc3f7a4d194c9105f94942e 570d853406075c7032f9066d86c774dc0d3eec2eb3ec63f7b433196c51746524 f0808f45be8813a89250e8afd9183754cfa9345749ab897d79104efbc52728cc cfe6d0d06aa74adebacb181d04ba53826de7b676292a32fd0879441b2ff16fd9 19b40a9c09eb77af0c9f14254137b39a70e8e0033aa1bd4b1901d9126ec79ac3 de23f2ed3c6e816b3550485ae00c6ef2e5f3dfbcd9415abcae46a4149ec95351 5e3e072715697613d20fa32d86be4ed734eaa4d8d2341c570e2e51d11b3c5753 8bcb9face76a8afb9dc9b8e862f9974cfb266c5165a83d4b93f2da3d00f23172 ddbcf3424b724175ce69353dfceb73af1c293bb048b31ae71461ae54a144b2ea 09455a909d4d46d666500d1a4f1e5785e27ac1295f2a1ec00b6c4f3a04b451be e912f96ab80cb4c3559419cf307d00de7eca7585645e6443a1a58636085bc63d 50ff0b26aabdafc495874caaa43766198fd652e6949d3a09a35537105a7d6c0c 1eee2ca43c2a830adadb0c4dd1ca17cd4c3f2da0ee114f70237019a222daf1d9 fc68255ce9fca00eaeab2f66c1691d293e272d8a6fc818deca35b169ce875bdd 71e5904d322fbe56e4db2916a4f779ef54d355b2a5690184ad42299da27200e8 6141679886b2a5f3a0cd3b6962f33e502d07c44363c058714d3c792074aaf9dd 26f92fcd2a9bd0850ee30f025826996ff5fa2046f09aa1248349ccda0fea91c6 76dd36e0f84cabe5344d88721ad8cb3ec52e1117e48bb82a92876c2f7617638b 563dbff74d984cb324b927c1e19e9f46f233ff0a8f5ba433521f553e42379912 443731fd82d2b8101501be1f63eab6c5d7648f9028bb2610154e7e45beb4fb5a e66c1d90e9dfdbef6f8f6c27bb939795f06415cea46efc999067327376513997 90aa0486e1241bcce73c0fa5d1f46bc9c203a4156f9bcbb7e46d3d9e7d7e5592 078facf12685ae550fc9806ef2c52cd668b5c5f4de1e3e0ffb6cfd2158b5bc46 29c172f7db81cf077c2e43f5d7722bc6058ee7a64f5fa3ce4f80814e5e168ed2 f69130cdc7a26cda23b9d6b4f3d521b2a03fa83473703d57fb6714c3f40f9b12 e1a2e5df462019d597a42f0bb92161be6e6e2ba64c22542bd4dead5753330751 7807935c062703a05c2d79c51a5e661312d740823ef73fac7170de7b2458399e 49c25304f0c2e889f62892717562981ab274892fd2a663505068149a81b48cbd 069bad6bd0f22d35c4f998264f2fcf600ea500dac7fd86db5015ee6e3e34e23f c246c0d8d3a3abb8d6dcc87d034e98076cadbe2a52f4038e4dea8c50c60641f3 c68e4c7cc34153b2bbb2033464bd26b286c11993d35b13ae6fe001aab44d7abf 4eb933ea0ad64186d0e87d7b3cac21232097655ea4f90dfb9f59e3d936f1e298 256aaa0a9b772ffcf7aada0674276010027c1b5ca9674678e780215986606bd8 9fc47ddd3af77cdfb29efc3828561fea5d786ae556639d8b9058c95972fe9b9d b429a639b96addd1ba31bcbe00d068723450cb3c6169adbd987b040c9dc17259 1ddd61db109027905e30cf6643ba77c34b46f7bec71ef7b868a88d7a6852cb01 e72a099278dd0511073419b829df0d97bb0e73bd83a43a112a27fb7a6032451d 7ac48527fcd93299fa282f9c1d9d89f4c5e22694b906f9de335bc0e958d16077 95f23eb205d4110be165e92964f45865b405005df1f8697260e2dedf788374bb 0350da2d3f655c5a79be0333299293851c8a1671c21d08dace45bbb8da8fa4cd ca88418d0f9e992d188351a500fd7304cc7429d0c237bff6891d4efa5e6e33ce 6cdd3a7ec15a99b010cd4386298ed4a444e8cbd0f9d3e59366596a25306edccc c890ce7772d65f3519f9407f4dda76b509ba2b208ea7a178bb40f6315c70f639 dc1d84abd25628954d78c32509eba5f6652010cad55b2625d418257416e65591 68dd372d3ce79234c417edacc0150a6fc6918360fe4885822d06cded80ed9f5c f4a75305872aec90fdb993a87f5eaf4188a22225713a3c2d5e83880491aeb8f1 12238391935c3af9cf8b744973ae2c629fadd49be904d68f2850144456dfa9b8 f2c3082df42253232a73a54cf815cb399755d2da5ac8a5df6e4ef8fbd32a3dda 41beeb4ca6c39b429bb4e5e2a8870f3dcdd7db96ce39f14023584fdab750f6c0 2cdaa3535734d5d451f032b40058ae10d467d7bd5f09653a46d537ec783b2ae8 2df1a0aa7a2df1c61513a3fe833c35923658670651615f268e0b69e50c5ed08b 24ba21be32c58da5d88462ee2977ed2439f79fdac1ff06e70ab9d4e19556fa14 3b591b31550d89c04da670e51fe61049a1b09f892a41f374f37e3d78acabd0a8 110eb5f01666df2f6cad3041705afe446360388386a7c638a91de78421bd1069 2d428b8b28c45580fe78de631a92d70d415ca7ac09c6ffe402ee9300faf51563 4c143eb1b8f3d4f472baed7e6d677da61ced15d6020ea747e9a60b935c87e21f 90c0bcf61de09d2ce76cb08da76364e0ec48ca5d68843c9a80dff6a5945d1693 64460adb04b1c09b5f468e32c08ae0397a706fade0c491bfa0e51c082543b0f8 15c30c90c5e00bce1d2417abed483ac9464dd7b7b73fe2c108703d8e3735eff8 3c2642aae0c2340cc77cba0dc70637399e27957a90131045f2cbdc41989682a2 d6cd3d72b4d927261957c311fe43e8c217a131df6961c481f32bb52ef4c1d2af 998e18e4443dc41d429b6b70a812a9ffe159c3d374a981ac142a064b1747003b 0c82fcc60e0a3160f9065eb5ed379e5c01fbbc047c936705bc12c9e3c3f948b3 713c2ed01d56a68e87554214a356d024b1630e4ff879fe561a1fb0fdc6834d8c 3dac25519fd45cbf8e91a0fae36010cb2ac565fcb16a36798952842c302ef427 6992db67d4aef58401b36a404e5e0880ee7a016b7156fe2c79d4d1cb90809232 ae8f6cfd56280e4fdd9a228437919096b1bdbf3ced4da0b2fa7bd10c8b277015 766216c20dfe8f5a91a744f22c83d6c0511812b3d44082b609a3c6f506b053c0 46c9eaeab574991928df91d58efd4ce6ae4f26964a51de3a04b69ce1c4444f7b 5606a88a44580f0b179472f3dd5b0ffcda7d05b19b2a6b82ed32fd85143e76e4 0c970ff93c35aac17a60912449e3a25027ae84cae1775ba3a978ec8170384e66 ad73ff7cedee0c841d11e032cb824683d5bb76a0ac954e27ed5d12e927526fe9 0c344368717ccaff171a2b2c477f88a5bacede17263039435188b7f300051a2f 38537a959e42438d8fcfe4e6202935466ea6afd3fc9bcfd3e81424627aa2a5e5 eef400000000000000000008131c252c353942682497c03104f244b9bd4f9a8b 3eb24f760d4823561d23b259698e3efa608a939b09bb5877074deed54c523a38 c1879f5e484eb27a037b0b0012d40ab02ad6c9e9a2a465b827cb90b9dbf7dd47 2dd37041f2e7729225c7715c8776428b52b67982facd1a706a2a502a5afe1b1d c960f62200' ]) ]]>

Acknowledgments We thank Orie Steele for his valuable comments on this document.