]> 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 PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or 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 Signature Algorithm The structures of the composite keys and composite signatures follow an approach similar to . The composite design is chosen so that composite keys and signatures can be used as a drop-in replacement in JOSE / COSE object formats. This section gives some details about their construction.

Composite Key Generation Composite public and private keys are generated by calling the key generation functions of the two component algorithms and concatenating the keys in an order given by the registered composite algorithm. Composite Public Key <- Public Key of the 1st Algorithm || Public Key of the 2nd Algorithm and Composite Private Key <- Private Key of the 1st Algorithm || Private Key of the 2nd Algorithm For the composite algorithms described in this document (ML-DSA with ECDSA or EdDSA), the Key Generation process is as follows: (pk, sk) 1. Generate component keys mldsaSeed = Random(32) (mldsaPK, mldsaSK) = ML-DSA.KeyGen_internal(mldsaSeed) (tradPK, tradSK) = Trad.KeyGen() 2. Check for component key generation failure if NOT (mldsaPK, mldsaSK) or NOT (tradPK, tradSK): output "Key generation error" 3. Serialize keys into composite form pk <- SerializePublicKey(mldsaPK, tradPK) sk <- SerializePrivateKey(mldsaSeed, tradSK) 4. Output the composite public and private keys return (pk, sk) ]]> As in , this keygen routine uses the seed-based ML-DSA.KeyGen_internal defined in Algorithm 6 of . This document makes use of the serialization routines from to obtain the byte string encodings of the composite public and private keys. In particular, the ECDSA keys and signature are encoded exactly as required in : the signature as an Ecdsa-Sig-Value , the private key as an ECPrivateKey , and the ECDSA public key uses the uncompressed X9.62 point encoding, including the leading 0x04 byte. Section gives guidance on how to encode the ECDSA keys and signature. These encodings are then used with the AKP Key Type. For more information, see the SerializePublicKey, DeserializePublicKey, SerializePrivateKey and DeserializePrivateKey algorithms from . For the AKP JSON Web Key Type and AKP COSE Key Type, point compression is performed for the EdDSA component, but not for the ECDSA component. In this document, as in , the ML-DSA private key MUST be a 32-bytes seed.

Composite Sign When signing a message M with the composite Sign algorithm, the signature combiner prepends a prefix as well as a label value specific to the composite algorithm used to bind the two component signatures to the composite algorithm and achieve weak non-separability, as defined in . However, only the pure ML-DSA component algorithm is used internally. A composite signature's value MUST include the two signature components and the two components MUST be in the same order as the components from the corresponding signing key. A composite signature for the message M is generated by:

• computing the pre-hash of the message M;
• concatenating the prefix, the label, a byte 0x00 and the pre-hash;
• calling the two signature component algorithms on this new message;
• concatenating the two output signatures.

For the composite algorithms described in this document (ML-DSA with ECDSA or EdDSA), the signature process of a message M is as follows: s 1. Compute the Message representative M' M' <- Prefix || Label || 0x00 || PH(M) 2. Separate the private key sk into component keys and re-generate the ML-DSA key from seed (mldsaSeed, tradSK) = DeserializePrivateKey(sk) (_, mldsaSK) = ML-DSA.KeyGen_internal(mldsaSeed) 3. Generate the two component signatures mldsaSig <- ML-DSA.Sign(mldsaSK, M', ctx=Label) tradSig <- Trad.Sign(tradSK, M') 4. If either ML-DSA.Sign() or Trad.Sign() return an error, then this process MUST return an error. if NOT mldsaSig or NOT tradSig: output "Signature generation error" 5. Output the encoded composite signature value. s <- SerializeSignatureValue(mldsaSig, tradSig) return s ]]> The serialization routines from are again used to obtain the byte string encoding of the composite signature. The SerializeSignatureValue routine concatenates the fixed-length ML-DSA signature value and the signature value from the traditional algorithm. For the ECDSA component, this document follows : the ECDSA signature is encoded as an Ecdsa-Sig-Value (see ).For more information, see the SerializeSignatureValue and DeserializeSignatureValue algorithms from . The prefix "Prefix" string is defined as in as the byte encoding of the string "CompositeAlgorithmSignatures2025", which in hex is 436F6D706F73697465416C676F726974686D5369676E61747572657332303235. It can be used by a traditional verifier to detect if the composite signature has been stripped apart. A signature label "Label" is defined in the same way as . It is specific to each composite algorithm. Additionally, the composite label is passed into the underlying ML-DSA primitive as the ctx. Signature Label values can be found in . Similarly to which indicates that the ctx parameter MUST be the empty string, the application context passed in to the composite signature algorithm MUST be the empty string. To align with the structure of the combiner, the byte 0x00 is appended in the message M' after the label to indicate the context has length 0. However, a second non-empty context, defined as the label, is passed down into the underlying pure ML-DSA component algorithm, to bind the Composite-ML-DSA algorithm used. (resp. ) indicates the pre-hash algorithms to use for JOSE (resp. COSE). M' is signed as a raw octet string in both JOSE and COSE.

Composite Verify The Verify algorithm MUST validate a signature only if all component signatures were successfully validated. The verification process of a signature sig is as follows:

• separate the composite public key into the component public keys;
• separate the composite signature into its 2 component signatures;
• compute the message M' from the message M whose signature is to be verified;
• verify each component signature.

true or false 1. Separate the keys and signatures (mldsaPK, tradPK) <- DeserializePublicKey(pk) (mldsaSig, tradSig) <- DeserializeSignatureValue(s) If Error during deserialization, or if any of the component keys or signature values are not of the correct type or length for the given component algorithm then output "Invalid signature" and stop. 2. Compute the message representative M' M' <- Prefix || Label || 0x00 || PH(M) 3. Check each component signature individually, according to its algorithm specification. if NOT ML-DSA.Verify(mldsaPK, M', ctx=Label) output "Invalid signature" if NOT Trad.Verify(tradPK, M') output "Invalid signature" if all succeeded, then output "Valid signature" ]]> The DeserializePublicKey and DeserializeSignatureValue serialization routines from are used to get the component public keys and the component signatures. For ECDSA, tradSig is encoded as Ecdsa-Sig-Value described in . For more information, see the DeserializePublicKey and DeserializeSignatureValue algorithms from .

Encoding Rules In each combination, the byte streams of the keys and of the signatures are directly concatenated. Signature of the 1st Algorithm || Signature of the 2nd Algorithm Since all combinations presented in this document start with the ML-DSA algorithm and the key or signature sizes are fixed as defined in , it is unambiguous to encode or decode a composite key or signature. lists sizes of the three parameter sets of the ML-DSA algorithm. Sizes (in bytes) of keys and signatures of ML-DSA

Algorithm	Private Key (seed)	Private Key	Public Key	Signature Size
ML-DSA-44	32	2560	1312	2420
ML-DSA-65	32	4032	1952	3309
ML-DSA-87	32	4896	2592	4627

Note that the seed is always 32 bytes, and that ML-DSA.KeyGen_internal from is called to produce the expanded private key from the seed, whose size corresponds to the sizes of the private key in the table above.

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 simply use it instead for the two DER structures. 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 (Section 4.5.2)	51	64
Public key	X9.62 uncompressed point (Section 4.5.3)	65	97
Signature	Ecdsa-Sig-Value (Section 4.5.1)	≤ 72	≤ 104

Ecdsa-Sig-Value (Signatures) Ecdsa-Sig-Value is defined in Section 2.2.3 of as: r and s are the same big-endian integer values already used today 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 happen to be 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 simply 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

After removing any leading 0x00 bytes from the raw value (keeping at least 1 byte), the first remaining byte is...	...then its DER encoding is
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.

ECPrivateKey (Private Keys) ECPrivateKey is defined in as: Given the raw, fixed-length ECDSA private value d (curve size n: 32 bytes for P-256, 48 bytes for P-384), the ECPrivateKey is simply d inserted between two fixed byte sequences that depend only on the curve (the publicKey field is never included), as given in : Fixed bytes surrounding d in an ECPrivateKey, by curve

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

For example, for P-256 (n = 32), with d = D1 D2 ...D32: Decoding reverses the same construction.

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 traditional signature algorithm for each combination in and was chosen to match the security level of the ML-DSA post-quantum component. 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, and COSE structures , and apply to 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 (RSA, ECDSA, and 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:

• Dual-Algorithm Security: 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.
• Impersonation Prevention: In particular, this prevents JOSE/COSE signature spoofing and impersonation attacks even if the traditional signature component is compromised.
• EUF-CMA Security: 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.

Component Key Integrity and Reuse To maintain the security properties of the composite scheme, strict key management is required:

• No Key Reuse: To avoid key reuse, when generating a new composite key, the 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.
• Certificate-Level Protection: The integrity of the composite public key is protected through mandatory validation of the certificate header (the x5c header in JOSE per or the x5chain header in COSE per ). Because the certificate itself is protected by a composite signature, an attacker cannot forge a fake certificate to swap a public key even if the traditional algorithm is broken. These specifications require the validation of the composite signature on the certificate itself.

Domain Separation and Non-Separability This document uses a signature combiner that prepends a fixed Prefix and a specific Label to the message representative M'.

• Non-separability: By binding the two component signatures to the specific composite algorithm, the composite scheme achieves "weak non-separability" as defined in .
• Cross-Algorithm Prevention: The unique label, specific to each composite algorithm, ensures that signatures cannot be removed from the composite and used in other contexts.

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:

• SUF-CMA Security: While the construction is SUF-CMA secure against classical adversaries when paired with Ed25519 or Ed448, it is not SUF-CMA secure against quantum adversaries (who can break the traditional component). Consequently, applications for which SUF-CMA security is a strict requirement MUST NOT use Composite ML-DSA.
• Non-repudiation: Composite ML-DSA is not suitable for use cases that require non-repudiation or signature uniqueness guarantees. In the JOSE/COSE threat model described above, existential unforgeability under chosen-message attack (EUF-CMA) is sufficient to meet the intended security goals.
• Replay Protection: This 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): n/a
• Algorithm Analysis Documents(s): TBD

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): n/a
• Algorithm Analysis Documents(s): TBD

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): n/a
• Algorithm Analysis Documents(s): TBD

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): n/a
• Algorithm Analysis Document(s): TBD

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): n/a
• Algorithm Analysis Document(s): TBD

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): n/a
• Algorithm Analysis Document(s): TBD

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: n/a
• Recommended: Yes

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: n/a
• Recommended: Yes

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: n/a
• Recommended: Yes

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: n/a
• Recommended: Yes

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: n/a
• Recommended: Yes

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: n/a
• Recommended: Yes

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. 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. 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. UK National Cyber Security Centre UK National Cyber Security Centre Naval Postgraduate School 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. SandboxAQ Naval Postgraduate School SandboxAQ UK National Cyber Security Centre 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/forwards compatibility, hybrid generality, and simultaneous verification. Tradeverifyd Tradeverifyd This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204.

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 00000000000000000000000000000000141f2c3a304502205c08a0f6a7e4cc02 8b2ecb57f92bfdf3908b35257e5262d3e54580ddf9465c29022100ed86790395 b1fbf5356fa8da76381cb2cc10e0b4789c70fc2f21a9e9f7dd9f7b' ]) ]]>

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 00000000000000070b101620263045022100c7a159bf3c820f2b6555d1759c42 51067ca742e30959600a967320a2a750bde0022004ccb16e3f95fa1a1df99883 852423e6f2973227f3929b4a646a70ef1e85f371' ]) ]]>

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 32003d6fd747cc68677a62997fd4a814d4c52c5e9fb7f705ab768d2208c65329 4e011af85badadf768cc7ec59891d43094aa6b303883e30c1ab7a04b6b831295 559a' / COSE_Sign1 / 18([ << { / alg ML-DSA-87-ES384 / 1: -56, / kid / 4: h'10da59a01e274d3d' } >>, / unprotected / {}, / payload / h'68656c6c6f20706f7374207175616e74756d207369676e617475726573', / signature / h'13c447a1b55ae88b08cbcbea8a4917cbbcaa138a945e4e31103a259e1830f7a3 9368671ff476c2a4d5cf117911438cbc2e9104145283e68b65a9e38a8035a0f7 07640c9c2e2611f5fdb63037cd0d0425dba8bda947d69722e0009cae2c991bec f3194e7fea730c5badf6f9fc51a5450d8189636bd726f0e89c15143244e8a4df 611df494906a5211610bb89a5759c350828a34bd8a34f86c43606714aae095f9 b6f896286cc6ee61765757250ae5c846cc086266c669d8764fb297c98c4b0914 015eaab46027495749ef7e8d70eb5b697e9abd6adbed7db655e606c1173bda1c 760a91f60609aa80487cfd5471c67f1389b61a9bbfa6f3fb07f70492967bbcf9 4c4b054e411331600e080dfa22be3e8fed5e0c6d3b986ee759c661736fba0f1f 92b616265d518622d48d852a06d2509c4e5b11cf2c5b3a580881ac9a848632d9 d9185ca6804045e9b8a15bcf44e2815748c6950edbeef19bd52174927cdbe4c2 e4ccb314708381ff4e08015cbd6887542ddc25cbcb434bb250bd38885b2558bf b014ebb7e4f4d0704a5291abede08c3617e00bf246ad666be941defe5fd783e4 392a1b766947973d50fbd08dbcb92137f0eb5785bc21291bd3ca99e4e12021e0 c28026a421dc5f6ab8f44667a7b387294fbce14ccb64036282c7e44b650d5584 d4c4592458bf3b318461b929f456ef7cb595daed90bea390ee28564c5a27000a 54b58e8ffc0862794743e0ae3f5658b0013bdcaf18f2ca771cb16701686e8626 cbdf90fa43583912934e6d73d77a0d9feb9987d5aefd25d97030f4365aad72e8 b3b3f9efc8d6250ee9e4fe654eea88c98a8d12e04440f4da6d50ec772247c0ef fd3805a5950f0a129b89434b619be3384bdb883a9e66f8ae5bc6457c8fe2c0dd 1f45961489808b2e97faf7b9ee4be66ea9984c74203a90bdaa8dfe5778174ea3 364375a8525224e1a3a88d1f05b4983d7cb1f83de207f3905bf73fd634436352 31895b8abce19a972c335a7688a85d79074ebea392b71ed3f53945052dc141ac 72d3065c38b9bab79f5426d3f8fe20fca713ae4f306cc7e8ad5a04dfd37323f7 2ce849a7bc2c324bbed5165bd4cd79c472668977d595ce046ba25f5629a9d10e 5344b7080cc6ff97e487cbfd0b9ea114744c2c071e43f536bc206a56300a1c09 be8047d797e948ae87eabfc1580328e0cb255a5409b50ea13e79a66ebfe9a9bd 6c61513300bef6d292469bc040c6744a02de2f5cf2086d5564f10df25cdc8ab8 db42d7b7dc6fb95daa3688e361e38e6c379fa043cd3661e40d7493e131276b2d 4592858e44746a4f1fed3f30765996ab0f805674dc15b957e90bf5cd9d0d5f87 bfe6a8860d1b2be8e792d3e81833f61bd1b457c9e051ab01d46b1609211caa47 6d0043b361f738ea0f8d92adc3a65632af0e10f1ba6d97f8095eb481e4206900 89379930f5a3293b0ace579c1fab53b53f47861761f25e47aab427ae1df9e50c 55ae019a81ca6fdeaa3046b72bbec397195d2a70f15afb0c441836efe8142e8b 177ff7d4680c0ed3a658f7d09ca883ea857737db8c88bd3650dbbb10f146ea15 422eeac31209c3b1c3f43bd72459f368e8280930e3b4abadb8b4758d24cedee7 2b8a5cdcbb299bb2c34c460c9f3b8e0831159bdcc2765ef4374175b24c116b8a 52e6beb3dcdf21477220502993c02cc221d65fd85fdbcca14dc17fc63d04e831 a90a9165e6c26f30f4a6ab1f6b011016abaa0f2a98f4de5556da89d4bd6b8855 74efcd862bf8dced571499cf6f9a533b2fae7891c38f8accd98dc0f482c78324 479e37116af557a57166d0d779c35297ecf4b66f89ae991a1968b60cdc294241 2aef5c8736049d631e788511c07060ecf5554eb2be97df9232920b7e8a6d9683 0d9c54d6ade2ecf4725f0013dd92b697094e3df0e57bfa0d0e7fe7b3fc0868ec bc8f187a7a7beae6f752100ebb3a44cdf41627a6710079bbd5ee3274ace2f23b bad4b26a4e3fa458ac7a062121a1ef4fc1c8d929b012a888bc98bf6a4c39c755 09e63cba46484b2ae5e0cbc3a3d598a9327ca6fa4868e7ea9c3696315c1cdeeb 1b6977dad72806365adfa839645ca9c3fe44cd9903cbdd495f55c793a0908cc5 05759f0fa7e09df9cfa064c0bfb6f5c350125ec025f2c2f0abaa87a568995d04 f99d7a68281d0f60a7a70767e4b6c17ac924851784579008cebd8bed6221ff62 bd59966c0a2d7d313dd9c0416c478c063565a419fe38f42d0437e92b76b41135 ab0f3310753945eaab0dbdb34a76852d515cd96dd8caffaaa7d742d7c89fd0bb acad8f9e60ea13c98b2a23baf737153877c67cb607732cb4e8b15a3e0f07b098 3c874ca4ebecc480e95daa47f364c46b03b26693594094adad9308ab1bd1d562 4fa6f39ccbdfbfa17d8716a1db15d564ea006266ee2d50d2260b9cb869711ce8 0e9864d4e5953cd99ac1ce79f87838679ab469a25bb5b342da0fb5e33044dd4b d70dc68ba41fb8aaae15449ab64f069e9786cc1bc03b58776ff82df3e5a53c32 c0611643a791151b1923a086a62cd9b25b5d2c4692166dba0040f19bdcfc7ec5 f4cf00ac81f382d5789cfef663b39eeefca7e52e80789fa82379bee3328fd8eb 9e636291b8d0d9782da09ae19e6d38079a5d426fdf449ef85bb07a9180eadaa4 4f382a9bb322da3022586ad3a59351b50f5420098c96907098251196687572f4 4ca4a1c3be2c9008f8ebbca1048ff7de47aa659555aa9969a71e6eed2af25920 6511021ae6525802b0bcefb22f3ebdf630456df76168ba2c2ce4519c4ac083da 31ba2ef6a1e3373997eacc9244f230c758ea6ddfcd96413b15f78bc738f9904b 7794b598244dbcca57caa5b15a9b6bd90ea23079f57a21e8f38e0ae90471139a e0570e52d7acae5ba678fdf6f8b9083f8f147849291b1ef0a19622ba90d1ff82 0450e41044a7c6f351adbfe0badda000c103a5cae89986adb299464c51688a9d 7bf1a91b1bfa6a095d0c0dad179a2b507698e6f03c34b4ba54b383d85f6393b2 ec1743a4b29a72c326ea986a6f31a2aa4357774ac7f851a1f8851330dc8b2d82 4ea665d39b9ef6140e33ec8a410086eb5ccbda83eb0c68a71c71aafdb1ff6020 3d377f4c4bda47ad68e62baf794bf0e4ea10b730d5c30dd3822b3b6ce41aefbc 9a5dfeac7860c4b5718fdb24af24305cd0352d6e66d11025e1bb36d4b71b32af b694bbbf1767a71fb067d078aa062ce4f125f7ffbdc601f7a89e47b89594b795 6c70b70a73e728bd14ec949089191dd5d2b94201c26d159c027c7456d6102c8c 3949b5b1adfa054c9ffcdd93917a2f7939a1dffec98903ef4b34068bbc7ef7d6 f7c9d5b294e4b5b464cdc560732de4634d95a6344d99938bbafa030970cb0803 978ee8de792f8f95716b037f03f19e885050af5f189d30ef3cc2ef16f71214c9 ce76fe6fb09d0c7ee862868c0ef1ff2b6df647849bc34c98d73ac0014ebfcd03 fae33e9c50378cae1f17921d8e435902f9fb860d8343a4e75f9e9ce72b710872 e7d8a42a59a44449eb54846a4bd77b6fe251ab2f6047e7686d3c8ab3660ed33d 4eda34123fd0f61c12f5dee53cb94b7ebcc308d114f08208b2c51cce45f318e4 804ccbe60536291e92ed9b50b0ccda61344984bb53742ff5173c26685bef52d8 c6ff752e7316b74e2aff43c436ba0161b427569dba9dbca119242cae0bb34108 574ff95f69a498cb6eb10930bb711642213f88c3dd771728d5625740d5f9f5b9 3ed99f9c329cd8cbcdc3fdbd7f02f25441bd1f4256bd5c7a9307ae4fd1acf24b 248ea5a995aa5b4f7271239f28b387ca3dc081ff2a00d4195c144c9df6794a6e bcf0526077954678f71de2f56eb81db590db52baa1ef7be014e7adecf3ba47ae 6c52e42bcf9c537c5eefbb984aab0c1dfc73ac780e3fb7effba0a4e23242de60 d83f87e1c9167747d09aa3fb83763f351a1de1ac44f1e9637202e9bfaeb27897 66ab31bed390cbf6a33c5210fffa1d01997e5e42b0a81368b1a4e3a16022cef3 21f89ae5d03d5c064a7e8ca3a63817c169ed000d18d4732aa4b37f68e3a47faa 0719e8f800c59b6b878a1be7e2be8807ce343b69dbbaf6c385994b730cbe26e9 170c509e7807caa00c924af7d494803ec9c3e5284eca4fea43ed2645444cb232 15facc1c9908acf2c6151f84cf384c48094383d910310ad535453bf650650d92 5f93e835fadbfd0d33fed488d3fa0a305ce5e14dd781c9daab36e7a6eccdc912 e2e957eddd40f084f76d1dbdce8506eeb99f958fe53e9ba005acd17ea23860a1 3ffafb777c6fe68b8ec52e4bc7158208e7e3d378eb60d3297fd09c3867fd2abd 276f7e510de3e3cde2be1797b4dfeed04c27b8a3cb270c3e1462229939008ffb 76312353d4f259822d659fb889369c121b90f8b6659e32d73d38ffdc0996e49a 47867ba7c33d29fc545b0812c0e994f4683bfd75e9ab9d80e553520c7c5ec46f c04fb80ed83f08f7b6bd015a659762c9936b1882a79e23ed35fb9d6b1e5882ed 88c5c1413eb8ec30d97b354fc818e660c729b9bafde5f816c0849e0b707f7944 12e5e20bf1ee445d33c8814e5693d32222eae89ca2caf01b909680b6799c4bda f032205ad1e4f01ccbdb6becbd65ef588db141f16effa1be241495f0313661d2 7c58652550a3eae5c349f7218dab91e2fe9635898b0348a67355accbda1a751e 04f55c2d2d2a24c137ac3f305062b2471552a3814ee6087bafb0cec17824a55f ee0aea80cb17dfcb02bc6c1dc625185f17fb48e2fb87aa1c8a5615974b891fa0 22b1877161a288e3c77166fbb4e2cbe3750c24bac80204a9f486f0338b135975 eca3649fd7d552af691afa2af8b8aaed57e2874a82db150cbd905c5208b94af2 2c723f71c4b3fb7428d3cedce5618b13ef9c340a7bc7d8f3085677aad2277dfc 7bf03d99e426a1c312c7950afe192102403c6a56a82f1e6e6651aa7a0d54000c 4d93e9cdc5858978546c2fa6e7f6771a0b1d10c87f88e24c0cc51bd0e6504224 b8a31d7e287189fb89439f204187c3a9b8429baa724451299fc72e3be5364822 da1edc755ae0aec8e9464747c0cf180c8e9ce5dc3ec0ec5b612a743d6cc73de4 192436b3befff69b3a59c676fe7476726ba1c673455a7756852afaf218ed191f 82f8ea94050224abb8c30d0c8e01024cb0de1b7651b261f979333f11170d5d8f db7ecff60c46160ff6b34006f6ace5bfd318180af926b92fcf58e492c06c9f89 86617caed1f0f866c0a4590ad47d503878457e44df4ce50b1187fb53709374f8 f84328ceef83c02314bbea2ba2c0b515919c310f2c86c2cc697b64f09b361330 4f7ebc457e3c80440215fa2758ea903540d61949fecfd323950e66aa0946055f 9eb018f7e39211c6266a2684131f4d4f4e292d9520693dfa2ea312c164bfbb06 3a451cb09e2d41e4eaa1e6ec8cd283cbe0709b2bce2c4a29378500862e846926 2afb6fde831d8eed286bffdaaf576486a102e3a102a3ed7dd087b1bd4519b3b3 2b033d561eb576e2dd995980bd31f67dbb58adb1527d350d50898b13010d44a3 8d90cd8fb7cf093e413817845e7ff38f5ac7a3da0a624946c31d6afd39e0b312 ce1bd21d3d78b561cd270b2a05aa5d12d4d9cad2af32a3e29b90742e3283dc92 535605f37c8bcace9b7a1a4016b651c554dee913348fc89fb40deecd70fb3b4a 34b29182a8cde3e81f2bcf3bf122290713d78b42bd2688e03d4da407903c3726 92b74f40ed113ded0ecf6b190d65eb26315bc6552154d2ec43d59f33aaabf97c 6bf0b1ff29253840d140f7964599467f5442d7a96fab4efd40ed93b2f878e306 2231056946de83a4203bc3a67d4a6cfa12ed5a307722942849e3824e67bc7ce6 ee893ecf76e3dcdaaed187c02fc851e01dcd33950381660bdfa7660dfe759cf9 a4147caab00e794ae150756c4485b9019a505b2f232d2cb23c704e6557aae8d1 f6f0ea38bd3567c708ed410e998b3c9b70a7d8428673a71d2f96dacf1fb71d55 5c6260f65b33fb4e16fedb3423ddf3cbf4c6484f063c984e51831e4d80177026 c67dc9168fea7e43a8b168692dd90a11e273506244784de1d6beae5af3350ac1 9dd6954c8de21fe67e700a019f5346129ea23b8faf4c3e3e70b3ab444fe819cf 966169af0ec7f6e12fd3bbeb65a8fc87a12dc2ff81ac518c9a19c77b3870a602 305cdc096a96fa18a08ecdb45edda76aba3cf6d39fbe0d15521bd367997b8c13 b2e39f54e59f58c6efb5833bbb1400afd2c4ea9c19faf4e94aee05e2a77d8868 a37e0847cb925991462ddc5f806032d5ccd3102422fe03a3ca650635809be994 ff246b0f3bcd07918efaa6dd6debb0470f30dbc72f8293349225901bc843c0f6 cf1572467986fb055a5c20b3705a7ac51333688c78752eacb06b564f3c196dbd 2386ef181b2b52b2cf090c20222f9a9cd2eefe065997999babc7dfe5e9f40a50 69b7c3c5d6353744919bbbea618e94c0dbe9304e83a0b7b8edf7000000000000 00000000000000000000000309131e252c323a30660231008a2fd552a21df4ce 623dbeef7f6a9385cb7bad3779bb35914fe211fd34d175043348a8efa56680df d45edced21ddc5de023100a3137028126347725829460993410c91bf7bffa939 8e37f6c6e142b89ae7f6775aa6f0847a4dc92cff5aba679125c65d' ]) ]]>

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.