rfc9881v1.txt		rfc9881.txt
	skipping to change at line 114 ¶		skipping to change at line 114 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Identifiers		2. Identifiers
	The AlgorithmIdentifier type is defined in [RFC5912] as follows:		The AlgorithmIdentifier type is defined in [RFC5912] as follows:
	AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=		AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
	SEQUENCE {		SEQUENCE {
	algorithm ALGORITHM-TYPE.id({AlgorithmSet}),		algorithm ALGORITHM-TYPE.&id({AlgorithmSet}),
	parameters ALGORITHM-TYPE.		parameters ALGORITHM-TYPE.
	Params({AlgorithmSet}{@algorithm}) OPTIONAL		&Params({AlgorithmSet}{@algorithm}) OPTIONAL
	}		}
	| NOTE: The above syntax is from [RFC5912] and is compatible with		| NOTE: The above syntax is from [RFC5912] and is compatible with
	| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1		| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1
	| syntax.		| syntax.
	The fields in AlgorithmIdentifier have the following meanings:		The fields in AlgorithmIdentifier have the following meanings:
	* algorithm identifies the cryptographic algorithm with an object		* algorithm identifies the cryptographic algorithm with an object
	identifier (OID).		identifier (OID).
	skipping to change at line 159 ¶		skipping to change at line 159 ¶
	3. ML-DSA Signatures in PKIX		3. ML-DSA Signatures in PKIX
	ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with-		ML-DSA is a digital signature scheme built upon the Fiat-Shamir-with-
	aborts framework [Fiat-Shamir]. The security is based upon the		aborts framework [Fiat-Shamir]. The security is based upon the
	hardness of lattice problems over module lattices [Dilithium]. ML-		hardness of lattice problems over module lattices [Dilithium]. ML-
	DSA provides three parameter sets for the NIST PQC security		DSA provides three parameter sets for the NIST PQC security
	categories 2, 3, and 5.		categories 2, 3, and 5.
	Signatures are used in a number of different ASN.1 structures. As		Signatures are used in a number of different ASN.1 structures. As
	shown in the ASN.1 representation from [RFC5280] below, in an X.509		shown in the ASN.1 equivalent to that in [RFC5280] below, in an X.509
	certificate, a signature is encoded with an algorithm identifier in		certificate, a signature is encoded with an algorithm identifier in
	the signatureAlgorithm attribute and a signatureValue attribute that		the signatureAlgorithm attribute and a signatureValue attribute that
	contains the actual signature.		contains the actual signature.
	Certificate ::= SIGNED{ TBSCertificate }		Certificate ::= SIGNED{ TBSCertificate }
	SIGNED{ToBeSigned} ::= SEQUENCE {		SIGNED{ToBeSigned} ::= SEQUENCE {
	toBeSigned ToBeSigned,		toBeSigned ToBeSigned,
	algorithmIdentifier SEQUENCE {		algorithmIdentifier SEQUENCE {
	algorithm SIGNATURE-ALGORITHM.		algorithm SIGNATURE-ALGORITHM.
	skipping to change at line 181 ¶		skipping to change at line 181 ¶
	parameters SIGNATURE-ALGORITHM.		parameters SIGNATURE-ALGORITHM.
	&Params({SignatureAlgorithms}		&Params({SignatureAlgorithms}
	{@algorithmIdentifier.algorithm})		{@algorithmIdentifier.algorithm})
	OPTIONAL		OPTIONAL
	},		},
	signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(		signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
	{SignatureAlgorithms}		{SignatureAlgorithms}
	{@algorithmIdentifier.algorithm}))		{@algorithmIdentifier.algorithm}))
	}		}
	Signatures are also used in the CRL list ASN.1 representation from		Signatures are also used in the CRL list ASN.1; the representation
	[RFC5280] below. In an X.509 CRL, a signature is encoded with an		below is equivalent to that in [RFC5280]. In an X.509 CRL, a
	algorithm identifier in the signatureAlgorithm attribute and a		signature is encoded with an algorithm identifier in the
	signatureValue attribute that contains the actual signature.		signatureAlgorithm attribute and a signatureValue attribute that
			contains the actual signature.
	CertificateList ::= SIGNED{ TBSCertList }		CertificateList ::= SIGNED{ TBSCertList }
	The following SIGNATURE-ALGORITHM ASN.1 classes are for ML-DSA-44,		The following SIGNATURE-ALGORITHM ASN.1 classes are for ML-DSA-44,
	ML-DSA-65, and ML-DSA-87:		ML-DSA-65, and ML-DSA-87:
	sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= {		sa-ml-dsa-44 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-ml-dsa-44		IDENTIFIER id-ml-dsa-44
	PARAMS ARE absent		PARAMS ARE absent
	PUBLIC-KEYS { pk-ml-dsa-44 }		PUBLIC-KEYS { pk-ml-dsa-44 }
	skipping to change at line 213 ¶		skipping to change at line 214 ¶
	}		}
	sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {		sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-ml-dsa-87		IDENTIFIER id-ml-dsa-87
	PARAMS ARE absent		PARAMS ARE absent
	PUBLIC-KEYS { pk-ml-dsa-87 }		PUBLIC-KEYS { pk-ml-dsa-87 }
	SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }		SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }
	}		}
	| NOTE: The above syntax is from [RFC5912] and is compatible with		| NOTE: The above syntax is from [RFC5912] and is compatible with
	| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1		| the 2021 ASN.1 syntax [X680].
	| syntax.
	The identifiers defined in Section 2 can be used as the		The identifiers defined in Section 2 can be used as the
	AlgorithmIdentifier in the signatureAlgorithm field in the sequence		AlgorithmIdentifier in the signatureAlgorithm field in the sequence
	Certificate/CertificateList and in the signature field in the		Certificate/CertificateList and in the signature field in the
	sequence TBSCertificate/TBSCertList in certificates and CRLs,		sequence TBSCertificate/TBSCertList in certificates and CRLs,
	respectively, [RFC5280]. The parameters of these signature		respectively, [RFC5280]. The parameters of these signature
	algorithms MUST be absent, as explained in Section 2. That is, the		algorithms MUST be absent, as explained in Section 2. That is, the
	AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-		AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-
	ml-dsa-*, where * is 44, 65, or 87 -- see Section 2.		ml-dsa-*, where * is 44, 65, or 87 -- see Section 2.
	The signatureValue field contains the corresponding ML-DSA signature		The signatureValue field contains the corresponding ML-DSA signature
	computed upon the ASN.1 DER-encoded tbsCertificate/tbsCertList		computed upon the ASN.1 DER-encoded TBSCertificate/TBSCertList
	[RFC5280]. The optional context string (ctx) parameter as defined in		[RFC5280]. The optional context string (ctx) parameter as defined in
	Section 5.2 of [FIPS204] is left to its default value: the empty		Section 5.2 of [FIPS204] is left to its default value: the empty
	string.		string.
	Conforming Certification Authority (CA) implementations MUST specify		Conforming Certification Authority (CA) implementations MUST specify
	the algorithms explicitly by using the OIDs specified in Section 2		the algorithms explicitly by using the OIDs specified in Section 2
	when encoding ML-DSA signatures in certificates and CRLs. Conforming		when encoding ML-DSA signatures in certificates and CRLs. Conforming
	client implementations that process certificates and CRLs using ML-		client implementations that process certificates and CRLs using ML-
	DSA MUST recognize the corresponding OIDs. Encoding rules for ML-DSA		DSA MUST recognize the corresponding OIDs. Encoding rules for ML-DSA
	signature values are specified in Section 2.		signature values are specified in Section 2.
	skipping to change at line 299 ¶		skipping to change at line 299 ¶
	{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }		{ digitalSignature, nonRepudiation, keyCertSign, cRLSign }
	PRIVATE-KEY ML-DSA-87-PrivateKey } -- defined in Section 6		PRIVATE-KEY ML-DSA-87-PrivateKey } -- defined in Section 6
	ML-DSA-44-PublicKey ::= OCTET STRING (SIZE (1312))		ML-DSA-44-PublicKey ::= OCTET STRING (SIZE (1312))
	ML-DSA-65-PublicKey ::= OCTET STRING (SIZE (1952))		ML-DSA-65-PublicKey ::= OCTET STRING (SIZE (1952))
	ML-DSA-87-PublicKey ::= OCTET STRING (SIZE (2592))		ML-DSA-87-PublicKey ::= OCTET STRING (SIZE (2592))
	| NOTE: The above syntax is from [RFC5912] and is compatible with		| NOTE: The above syntax is from [RFC5912] and is compatible with
	| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1		| the 2021 ASN.1 syntax [X680].
	| syntax.
	[RFC5958] specifies the Asymmetric Key Package's OneAsymmetricKey		[RFC5958] specifies the Asymmetric Key Package's OneAsymmetricKey
	type for encoding asymmetric keypairs. When an ML-DSA private key or		type for encoding asymmetric keypairs. When an ML-DSA private key or
	keypair is encoded as a OneAsymmetricKey, it follows the description		keypair is encoded as a OneAsymmetricKey, it follows the description
	in Section 6.		in Section 6.
	When the ML-DSA private key appears outside of an Asymmetric Key		When the ML-DSA private key appears outside of an Asymmetric Key
	Package in an environment that uses ASN.1 encoding, it can be encoded		Package in an environment that uses ASN.1 encoding, it can be encoded
	using one of the ML-DSA-PrivateKey CHOICE formats defined in		using one of the ML-DSA-PrivateKey CHOICE formats defined in
	Section 6. The seed format is RECOMMENDED as it efficiently stores		Section 6. The seed format is RECOMMENDED as it efficiently stores
	skipping to change at line 358 ¶		skipping to change at line 357 ¶
	* encipherOnly		* encipherOnly
	* decipherOnly		* decipherOnly
	Requirements about the keyUsage extension bits defined in [RFC5280]		Requirements about the keyUsage extension bits defined in [RFC5280]
	still apply.		still apply.
	6. Private Key Format		6. Private Key Format
	[FIPS204] specifies two formats for an ML-DSA private key: a 32-octet		[FIPS204] specifies two formats for an ML-DSA private key: a 32-octet
	seed (xi) and an (expanded) private key. The expanded private key		seed (ξ) (GREEK SMALL LETTER XI, U+03BE) and an (expanded) private
	(and public key) is computed from the seed using ML-		key. The expanded private key (and public key) is computed from the
	DSA.KeyGen_internal(xi) (algorithm 6).		seed using ML-DSA.KeyGen_internal(ξ) (algorithm 6).
	"Asymmetric Key Packages" [RFC5958] specifies how to encode a private		"Asymmetric Key Packages" [RFC5958] specifies how to encode a private
	key in a structure that both identifies what algorithm the private		key in a structure that both identifies what algorithm the private
	key is for and allows for the public key and additional attributes		key is for and allows for the public key and additional attributes
	about the key to be included as well. For illustration, the ASN.1		about the key to be included as well. For illustration, the ASN.1
	structure OneAsymmetricKey is replicated below.		structure OneAsymmetricKey is replicated below.
	OneAsymmetricKey ::= SEQUENCE {		OneAsymmetricKey ::= SEQUENCE {
	version Version,		version Version,
	privateKeyAlgorithm SEQUENCE {		privateKeyAlgorithm SEQUENCE {
	skipping to change at line 424 ¶		skipping to change at line 423 ¶
	ML-DSA-87-PrivateKey ::= CHOICE {		ML-DSA-87-PrivateKey ::= CHOICE {
	seed [0] OCTET STRING (SIZE (32)),		seed [0] OCTET STRING (SIZE (32)),
	expandedKey OCTET STRING (SIZE (4896)),		expandedKey OCTET STRING (SIZE (4896)),
	both SEQUENCE {		both SEQUENCE {
	seed OCTET STRING (SIZE (32)),		seed OCTET STRING (SIZE (32)),
	expandedKey OCTET STRING (SIZE (4896))		expandedKey OCTET STRING (SIZE (4896))
	}		}
	}		}
	| NOTE: The above syntax is from [RFC5912] and is compatible with		| NOTE: The above syntax is from [RFC5912] and is compatible with
	| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1		| the 2021 ASN.1 syntax [X680].
	| syntax.
	The CHOICE allows three representations of the private key:		The CHOICE allows three representations of the private key:
	1. The seed format (tag [0]) contains just the 32-byte seed value		1. The seed format (tag [0]) contains just the 32-byte seed value
	(xi) from which both the expanded private key and public key can		(ξ) from which both the expanded private key and public key can
	be derived using ML-DSA.KeyGen_internal(xi).		be derived using ML-DSA.KeyGen_internal(ξ).
	2. The expandedKey format contains the expanded private key that was		2. The expandedKey format contains the expanded private key that was
	derived from the seed.		derived from the seed.
	3. The both format contains both the seed and expanded private key,		3. The both format contains both the seed and expanded private key,
	allowing for interoperability; some may want to use and retain		allowing for interoperability; some may want to use and retain
	the seed and others may only support expanded private keys.		the seed and others may only support expanded private keys.
	When encoding an ML-DSA private key in a OneAsymmetricKey object, any		When encoding an ML-DSA private key in a OneAsymmetricKey object, any
	of these three formats may be used, though the seed format is		of these three formats may be used, though the seed format is
	skipping to change at line 453 ¶		skipping to change at line 451 ¶
	The privateKeyAlgorithm field uses the AlgorithmIdentifier structure		The privateKeyAlgorithm field uses the AlgorithmIdentifier structure
	with the appropriate OID as defined in Section 2. If present, the		with the appropriate OID as defined in Section 2. If present, the
	publicKey field will hold the encoded public key as defined in		publicKey field will hold the encoded public key as defined in
	Section 4.		Section 4.
	| NOTE: While the private key can be stored in multiple formats,		| NOTE: While the private key can be stored in multiple formats,
	| the seed-only format is RECOMMENDED as it is the most compact		| the seed-only format is RECOMMENDED as it is the most compact
	| representation. Both the expanded private key and the public		| representation. Both the expanded private key and the public
	| key can be deterministically derived from the seed using ML-		| key can be deterministically derived from the seed using ML-
	| DSA.KeyGen_internal(xi). Alternatively, the public key can be		| DSA.KeyGen_internal(ξ). Alternatively, the public key can be
	| generated from the private key. While the publicKey field and		| generated from the private key. While the publicKey field and
	| expandedKey format are technically redundant when using the		| expandedKey format are technically redundant when using the
	| seed-only format, they MAY be included to enable keypair		| seed-only format, they MAY be included to enable keypair
	| consistency checks during import operations.		| consistency checks during import operations.
	When parsing the private key, the ASN.1 tag explicitly indicates		When parsing the private key, the ASN.1 tag explicitly indicates
	which variant of CHOICE is present. Implementations should use the		which variant of CHOICE is present. Implementations should use the
	context-specific tag IMPLICIT [0] (raw value 0x80) for seed, OCTET		context-specific tag IMPLICIT [0] (raw value 0x80) for seed, OCTET
	STRING (0x04) for expandedKey, and SEQUENCE (0x30) for both to parse		STRING (0x04) for expandedKey, and SEQUENCE (0x30) for both to parse
	the private key, rather than any other heuristic like length of the		the private key, rather than any other heuristic like length of the
	skipping to change at line 481 ¶		skipping to change at line 479 ¶
	For the ASN.1 module in Appendix A, IANA has assigned the following		For the ASN.1 module in Appendix A, IANA has assigned the following
	object identifier (OID) in the "SMI Security for PKIX Module		object identifier (OID) in the "SMI Security for PKIX Module
	Identifier" registry (1.3.6.1.5.5.7.0):		Identifier" registry (1.3.6.1.5.5.7.0):
	+=========+=========================+===========+		+=========+=========================+===========+
	| Decimal | Description | Reference |		| Decimal | Description | Reference |
	+=========+=========================+===========+		+=========+=========================+===========+
	| 119 | id-mod-x509-ml-dsa-2025 | RFC 9881 |		| 119 | id-mod-x509-ml-dsa-2025 | RFC 9881 |
	+---------+-------------------------+-----------+		+---------+-------------------------+-----------+
	Table 1		Table 1: Registered ASN.1 Module
	8. Operational Considerations		8. Operational Considerations
	8.1. Private Key Format		8.1. Private Key Format
	An ML-DSA.KeyGen seed (xi) represents the RECOMMENDED format for		An ML-DSA.KeyGen seed (ξ) represents the RECOMMENDED format for
	storing and transmitting ML-DSA private keys. This format is		storing and transmitting ML-DSA private keys. This format is
	explicitly permitted by [FIPS204] as an acceptable representation of		explicitly permitted by [FIPS204] as an acceptable representation of
	a keypair. In particular, generating the seed in one cryptographic		a keypair. In particular, generating the seed in one cryptographic
	module and then importing or exporting it into another cryptographic		module and then importing or exporting it into another cryptographic
	module is allowed. The internal key-generation function ML-		module is allowed. The internal key-generation function ML-
	DSA.KeyGen_internal(xi) can be accessed for this purpose.		DSA.KeyGen_internal(ξ) can be accessed for this purpose.
	Note also that unlike other private key compression methods in other		Note also that unlike other private key compression methods in other
	algorithms, expanding a private key from a seed is a one-way		algorithms, expanding a private key from a seed is a one-way
	function, meaning that once a full key is expanded from seed and the		function, meaning that once a full key is expanded from seed and the
	seed discarded, the seed cannot be recreated, even if the full		seed discarded, the seed cannot be recreated, even if the full
	expanded private key is available. For this reason, it is		expanded private key is available. For this reason, it is
	RECOMMENDED that implementations retain and export the seed, even		RECOMMENDED that implementations retain and export the seed, even
	when also exporting the expanded private key. ML-DSA seed extraction		when also exporting the expanded private key. ML-DSA seed extraction
	can be implemented by including the seed xi that is randomly		can be implemented by including the seed ξ that is randomly generated
	generated at line 1 of Algorithm 1 ML-DSA.KeyGen in the returned		at line 1 of Algorithm 1 ML-DSA.KeyGen in the returned output.
	output.
	When encoding an ML-DSA private key in a OneAsymmetricKey object, any		When encoding an ML-DSA private key in a OneAsymmetricKey object, any
	of these three formats may be used, though the seed format is		of these three formats may be used, though the seed format is
	RECOMMENDED for storage efficiency.		RECOMMENDED for storage efficiency.
	8.2. Private Key Consistency Testing		8.2. Private Key Consistency Testing
	When receiving a private key that contains both the seed and the		When receiving a private key that contains both the seed and the
	expandedKey, the recipient SHOULD perform a seed consistency check to		expandedKey, the recipient SHOULD perform a seed consistency check to
	ensure that the sender properly generated the private key.		ensure that the sender properly generated the private key.
	skipping to change at line 566 ¶		skipping to change at line 563 ¶
	prior to hashing, as described in line 6 of Algorithm 7 of [FIPS204].		prior to hashing, as described in line 6 of Algorithm 7 of [FIPS204].
	This means that in the unlikely discovery of a collision attack		This means that in the unlikely discovery of a collision attack
	against the SHA-3 family, an attacker would have to perform a public-		against the SHA-3 family, an attacker would have to perform a public-
	key-specific collision search in order to find message pairs such		key-specific collision search in order to find message pairs such
	that H(tr || m1) = H(tr || m2), because a direct hash collision H(m1)		that H(tr || m1) = H(tr || m2), because a direct hash collision H(m1)
	= H(m2) will not suffice. HashML-DSA removes this enhanced security		= H(m2) will not suffice. HashML-DSA removes this enhanced security
	property. In spite of its lack of targeted collision protection, the		property. In spite of its lack of targeted collision protection, the
	practical security risk of using HashML-DSA in X.509 signatures would		practical security risk of using HashML-DSA in X.509 signatures would
	be immaterial. This is because a hash of the issuing CA's public key		be immaterial. This is because a hash of the issuing CA's public key
	is already included in the Authority Key Identifier (AKI) extension,		is already included in the Authority Key Identifier (AKI) extension,
	which is signed as part of the tbsCertificate structure. Even when		which is signed as part of the TBSCertificate structure. Even when
	it is a SHA-1 hash, general second pre-images against the AKI hash of		it is a SHA-1 hash, general second pre-images against the AKI hash of
	existing issuing CAs would be impractical.		existing issuing CAs would be impractical.
	9. Security Considerations		9. Security Considerations
	The Security Considerations section of [RFC5280] applies to this		The Security Considerations section of [RFC5280] applies to this
	specification as well.		specification as well.
	The ML-DSA signature scheme is strongly unforgeable under chosen		The ML-DSA signature scheme is strongly unforgeable under chosen
	message attacks (SUF-CMA). For the purpose of estimating security		message attacks (SUF-CMA). For the purpose of estimating security
	skipping to change at line 595 ¶		skipping to change at line 592 ¶
	efficiently recover the private key by trying a small set of		efficiently recover the private key by trying a small set of
	possibilities, rather than brute-force searching the whole keyspace.		possibilities, rather than brute-force searching the whole keyspace.
	The generation of random numbers of a sufficient level of quality for		The generation of random numbers of a sufficient level of quality for
	use in cryptography is difficult; see Section 3.6.1 of [FIPS204] for		use in cryptography is difficult; see Section 3.6.1 of [FIPS204] for
	some additional information.		some additional information.
	In the design of ML-DSA, care has been taken to make side-channel		In the design of ML-DSA, care has been taken to make side-channel
	resilience easier to achieve. For instance, ML-DSA does not depend		resilience easier to achieve. For instance, ML-DSA does not depend
	on Gaussian sampling. Implementations must still take great care not		on Gaussian sampling. Implementations must still take great care not
	to leak information via various side channels. While deliberate		to leak information via various side channels. While deliberate
	design decisions such as these can help to deliver a greater ease of		design decisions such as these can help to deliver a secure
	secure implementation -- particularly against side-channel attacks --		implementation with greater ease -- particularly against side-channel
	it does not necessarily provide resistance to more powerful attacks		attacks -- it does not necessarily provide resistance to more
	such as differential power analysis. Some amount of side-channel		powerful attacks such as differential power analysis. Some amount of
	leakage has been demonstrated in parts of the signing algorithm		side-channel leakage has been demonstrated in parts of the signing
	(specifically the bit-unpacking function), from which a demonstration		algorithm (specifically the bit-unpacking function), from which a
	of key recovery has been made over a large sample of signatures.		demonstration of key recovery has been made over a large sample of
	Masking countermeasures exist for ML-DSA, but comes with performance		signatures. Masking countermeasures exist for ML-DSA, but comes with
	overhead.		performance overhead.
	ML-DSA offers both deterministic and randomized signing. Signatures		ML-DSA offers both deterministic and randomized signing. Signatures
	generated with either mode are compatible and a verifier can't tell		generated with either mode are compatible and a verifier cannot tell
	them apart. In the deterministic case, a signature only depends on		them apart. In the deterministic case, a signature only depends on
	the private key and the message to be signed. This makes the		the private key and the message to be signed. This makes the
	implementation easier to test and does not require a randomness		implementation easier to test and does not require a randomness
	source during signing. In the randomized case, signing mixes in a		source during signing. In the randomized case, signing mixes in a
	256-bit random string from an approved random bit generator (RBG).		256-bit random string from an approved random bit generator (RBG).
	When randomized, ML-DSA is easier to harden against fault and		When randomized, ML-DSA is easier to harden against fault and
	hardware side-channel attacks.		hardware side-channel attacks.
	A security property that is also associated with digital signatures		A security property that is also associated with digital signatures
	is non-repudiation. Non-repudiation refers to the assurance that the		is non-repudiation. Non-repudiation refers to the assurance that the
	owner of a signature key pair that was capable of generating an		owner of a signature keypair that was capable of generating an
	existing signature corresponding to certain data cannot convincingly		existing signature corresponding to certain data cannot convincingly
	deny having signed the data, unless its private key was compromised.		deny having signed the data, unless its private key was compromised.
	The digital signature scheme ML-DSA possesses three security		The digital signature scheme ML-DSA possesses three security
	properties beyond unforgeability, that are associated with non-		properties beyond unforgeability, that are associated with non-
	repudiation. These are exclusive ownership, message-bound		repudiation. These are exclusive ownership, message-bound
	signatures, and non-resignability. These properties are based		signatures, and non-resignability. These properties are based
	tightly on the assumed collision resistance of the hash function used		tightly on the assumed collision resistance of the hash function used
	(in this case SHAKE-256). A full discussion of these properties in		(in this case SHAKE-256). A full discussion of these properties in
	ML-DSA can be found at [CDFFJ21].		ML-DSA can be found at [CDFFJ21].
	skipping to change at line 680 ¶		skipping to change at line 677 ¶
	[X690] ITU-T, "Information Technology -- ASN.1 encoding rules:		[X690] ITU-T, "Information Technology -- ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules		Encoding Rules (CER) and Distinguished Encoding Rules
	(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,		(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
	February 2021, <https://www.itu.int/rec/T-REC-X.690>.		February 2021, <https://www.itu.int/rec/T-REC-X.690>.
	10.2. Informative References		10.2. Informative References
	[CDFFJ21] Cremers, C., Düzlü, S., Fiedler, R., Fischlin, M., and C.		[CDFFJ21] Cremers, C., Düzlü, S., Fiedler, R., Fischlin, M., and C.
	Janson, "BUFFing signature schemes beyond unforgeability		Janson, "BUFFing signature schemes beyond unforgeability
	and the case of post-quantum signatures", 2021 IEEE		and the case of post-quantum signatures", Cryptology
	Symposium on Security and Privacy (SP), pp. 1696-1714,		ePrint Archive, Paper 2020/1525, October 2023,
	DOI 10.1109/SP40001.2021.00093, 2021,		<https://eprint.iacr.org/
	<https://ieeexplore.ieee.org/document/9519420>.		archive/2020/1525/20231023:114351>.
	[Dilithium]		[Dilithium]
	Bai, S., Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky,		Bai, S., Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky,
	V., Schwabe, P., Seiler, G., and D. Stehlé, "CRYSTALS-		V., Schwabe, P., Seiler, G., and D. Stehlé, "CRYSTALS-
	Dilithium Algorithm Specifications and Supporting		Dilithium Algorithm Specifications and Supporting
	Documentation (Version 3.1)", 8 February 2021,		Documentation (Version 3.1)", 8 February 2021,
	<https://pq-crystals.org/dilithium/data/dilithium-		<https://pq-crystals.org/dilithium/data/dilithium-
	specification-round3-20210208.pdf>.		specification-round3-20210208.pdf>.
	[Fiat-Shamir]		[Fiat-Shamir]
	skipping to change at line 870 ¶		skipping to change at line 867 ¶
	PUBLIC-KEYS { pk-ml-dsa-65 }		PUBLIC-KEYS { pk-ml-dsa-65 }
	SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 }		SMIME-CAPS { IDENTIFIED BY id-ml-dsa-65 }
	}		}
	sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {		sa-ml-dsa-87 SIGNATURE-ALGORITHM ::= {
	IDENTIFIER id-ml-dsa-87		IDENTIFIER id-ml-dsa-87
	PARAMS ARE absent		PARAMS ARE absent
	PUBLIC-KEYS { pk-ml-dsa-87 }		PUBLIC-KEYS { pk-ml-dsa-87 }
	SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }		SMIME-CAPS { IDENTIFIED BY id-ml-dsa-87 }
	}		}
	END		END
	<CODE ENDS>		<CODE ENDS>
	Appendix B. Security Strengths		Appendix B. Security Strengths
	Instead of defining the strength of a quantum algorithm in a		Instead of defining the strength of a quantum algorithm using the
	traditional manner using the imprecise notion of bits of security,		common but imprecise notion of bits of security, NIST has instead
	NIST has instead elected to define security levels by picking a		elected to define security levels by picking a reference scheme,
	reference scheme, which NIST expects to offer notable levels of		which NIST expects to offer notable levels of resistance to both
	resistance to both quantum and classical attacks. To wit, an		quantum and classical attacks. To wit, an algorithm that achieves
	algorithm that achieves NIST PQC security level 1 must require		NIST PQC security level 1 must require computational resources to
	computational resources to break the relevant security property,		break the relevant security property, which are greater than those
	which are greater than those required for a brute-force key search on		required for a brute-force key search on AES-128. Levels 3 and 5 use
	AES-128. Levels 3 and 5 use AES-192 and AES-256 as references,		AES-192 and AES-256 as references, respectively. Levels 2 and 4 use
	respectively. Levels 2 and 4 use collision search for SHA-256 and		collision search for SHA-256 and SHA-384 as references.
	SHA-384 as references.
	The parameter sets defined for NIST security levels 2, 3, and 5 are		The parameter sets defined for NIST security levels 2, 3, and 5 are
	listed in Figure 1, along with the resulting signature size, public		listed in Figure 1, along with the resulting signature size, public
	key, and private key sizes in bytes. Note that these are the sizes		key, and private key sizes in bytes. Note that these are the sizes
	of the raw keys, not including ASN.1 encoding overhead from		of the raw keys, not including ASN.1 encoding overhead from
	OneAsymmetricKey and SubjectPublicKeyInfo wrappers. Private key		OneAsymmetricKey and SubjectPublicKeyInfo wrappers. Private key
	sizes are shown for both the seed format and expanded format.		sizes are shown for both the seed format and expanded format.
	+=======+=======+=====+==========+========+=========+===========+		+=======+=======+=====+==========+========+=========+===========+
	| Level | (k,l) | eta | Sig. (B) | Public | Private | Private |		| Level | (k,l) | eta | Sig. (B) | Public | Private | Private |
	skipping to change at line 2664 ¶		skipping to change at line 2659 ¶
	}		}
	C.3. Example Certificates		C.3. Example Certificates
	| The example certificates in this section have key usage bits		| The example certificates in this section have key usage bits
	| set to digitalSignature, keyCertSign, and cRLSign to lessen the		| set to digitalSignature, keyCertSign, and cRLSign to lessen the
	| number of examples, i.e., brevity. Certificate Policies (CPs)		| number of examples, i.e., brevity. Certificate Policies (CPs)
	| [RFC3647] for production CAs should consider whether this		| [RFC3647] for production CAs should consider whether this
	| combination is appropriate.		| combination is appropriate.
	The following is a self-signed certificate for the ML-DSA-44 public		NOTE: The following is a self-signed certificate for the ML-DSA-44
	key in the previous section. The textual encoding [RFC7468] is		public key in the previous section. The textual encoding [RFC7468]
	followed by the so-called "pretty print"; the certificates are the		is followed by the so-called "pretty print"; the certificates are the
	same.		same.
	-----BEGIN CERTIFICATE-----		-----BEGIN CERTIFICATE-----
	MIIPlDCCBgqgAwIBAgIUFZ/+byL9XMQsUk32/V4o0N44804wCwYJYIZIAWUDBAMR		MIIPlDCCBgqgAwIBAgIUFZ/+byL9XMQsUk32/V4o0N44804wCwYJYIZIAWUDBAMR
	MCIxDTALBgNVBAoTBElFVEYxETAPBgNVBAMTCExBTVBTIFdHMB4XDTIwMDIwMzA0		MCIxDTALBgNVBAoTBElFVEYxETAPBgNVBAMTCExBTVBTIFdHMB4XDTIwMDIwMzA0
	MzIxMFoXDTQwMDEyOTA0MzIxMFowIjENMAsGA1UEChMESUVURjERMA8GA1UEAxMI		MzIxMFoXDTQwMDEyOTA0MzIxMFowIjENMAsGA1UEChMESUVURjERMA8GA1UEAxMI
	TEFNUFMgV0cwggUyMAsGCWCGSAFlAwQDEQOCBSEA17K0clSq4NtF55MNSpjSyX2P		TEFNUFMgV0cwggUyMAsGCWCGSAFlAwQDEQOCBSEA17K0clSq4NtF55MNSpjSyX2P
	E5fReJ2voXAksxbpvslPyZRtQvGbeadBO7qjPnFJy0LtURVpOsBB+suYit61/g4d		E5fReJ2voXAksxbpvslPyZRtQvGbeadBO7qjPnFJy0LtURVpOsBB+suYit61/g4d
	hjEYSZW1ksOX0ilOLhT5CqQUujgmiZrEP0zMrLwm6agyuVEY1ctDPL75ZgsAE44I		hjEYSZW1ksOX0ilOLhT5CqQUujgmiZrEP0zMrLwm6agyuVEY1ctDPL75ZgsAE44I
	F/YediyidMNq1VTrIqrBFi5KsBrLoeOMTv2PgLZbMz0PcuVd/nHOnB67mInnxWEG		F/YediyidMNq1VTrIqrBFi5KsBrLoeOMTv2PgLZbMz0PcuVd/nHOnB67mInnxWEG
	skipping to change at line 3826 ¶		skipping to change at line 3821 ¶
	| in production systems.		| in production systems.
	The following examples demonstrate inconsistent seed and expanded		The following examples demonstrate inconsistent seed and expanded
	private keys.		private keys.
	Three ML-DSA-44-PrivateKey examples of inconsistent seed and expanded		Three ML-DSA-44-PrivateKey examples of inconsistent seed and expanded
	private keys follow:		private keys follow:
	1. The first ML-DSA-PrivateKey example includes the both CHOICE ,		1. The first ML-DSA-PrivateKey example includes the both CHOICE ,
	i.e., both seed and expandedKey are included. The seed and		i.e., both seed and expandedKey are included. The seed and
	expanded values can be checked for inconsistencies.		expandedKey values can be checked for inconsistencies.
	2. The second ML-DSA-PrivateKey example includes only expandedKey.		2. The second ML-DSA-PrivateKey example includes only expandedKey.
	The public key fails to match the tr hash value in the private		The public key fails to match the tr hash value in the private
	key.		key.
	3. The third ML-DSA-PrivateKey example also includes only		3. The third ML-DSA-PrivateKey example also includes only
	expandedKey. The private s_1 and s_2 vectors imply a t vector		expandedKey. The private s_1 and s_2 vectors imply a t vector
	whose private low bits do not match the t_0 vector portion of the		whose private low bits do not match the t_0 vector portion of the
	private key (its high bits t_1 are the primary content of the		private key (its high bits t_1 are the primary content of the
	public key).		public key).
	The second and third examples would not be detected by		The second and third examples would not be detected by
	implementations that do not regenerate the public key from the		implementations that do not regenerate the public key from the
	private key, or neglect to then check consistency of tr or t_0.		private key or, when they do, they neglect to check consistency of tr
			and t_0.
	The following is the first example:		The following is the first example:
	-----BEGIN PRIVATE KEY-----		-----BEGIN PRIVATE KEY-----
	MIIKPgIBADALBglghkgBZQMEAxEEggoqMIIKJgQgAAECAwQFBgcICQoLDA0ODxAR		MIIKPgIBADALBglghkgBZQMEAxEEggoqMIIKJgQgAAECAwQFBgcICQoLDA0ODxAR
	EhMUFRYXGBkaGxwdHh8EggoAUQyb/R3XN09Oiucd1YKBEGqTQS7Y+jV/dLu0Zh7L		EhMUFRYXGBkaGxwdHh8EggoAUQyb/R3XN09Oiucd1YKBEGqTQS7Y+jV/dLu0Zh7L
	GSHTp1/JO4jvDmqbhRvs7BmZm+gQaMhZ1t8RXGCMFQEXDrbAVcIvYlWSSXbYlaX1		GSHTp1/JO4jvDmqbhRvs7BmZm+gQaMhZ1t8RXGCMFQEXDrbAVcIvYlWSSXbYlaX1
	TSw4WWxAPM72+XPiKl+MfCuoNjNEcJCniyK7Qc/e2vvLLt7PkHDM5hLkKrCh8T65		TSw4WWxAPM72+XPiKl+MfCuoNjNEcJCniyK7Qc/e2vvLLt7PkHDM5hLkKrCh8T65
	3DwUkDGJwoHgsDHalISCEgijtDDSKEoEByDDRELgQC5EoHEBqSwDJmQSQSQYMiQA		3DwUkDGJwoHgsDHalISCEgijtDDSKEoEByDDRELgQC5EoHEBqSwDJmQSQSQYMiQA
	Ii5KlmALGZAiMyBShkUbCEyTGIQZAG1TgAwQpChQBgogBgwjETLSxEDSEgIENIYj		Ii5KlmALGZAiMyBShkUbCEyTGIQZAG1TgAwQpChQBgogBgwjETLSxEDSEgIENIYj
	skipping to change at line 4046 ¶		skipping to change at line 4042 ¶
	Implementations of ML-DSA using the External μ pre-hashing mode		Implementations of ML-DSA using the External μ pre-hashing mode
	requires the following algorithms, which are modified versions of the		requires the following algorithms, which are modified versions of the
	algorithms presented in [FIPS204]. The nomenclature used here has		algorithms presented in [FIPS204]. The nomenclature used here has
	been modified from the NIST FAQ [FIPS204-ExternalMuFAQ] for clarity.		been modified from the NIST FAQ [FIPS204-ExternalMuFAQ] for clarity.
	Pre-hash operation:		Pre-hash operation:
	Computeμ(pk, M, ctx):		Computeμ(pk, M, ctx):
	# Referred to as 'Externalμ-ML-DSA.Prehash(pk, M, ctx)'		# Referred to as 'ExternalMu-ML-DSA.Prehash(pk, M, ctx)'
	# in the FIPS 204 FAQ.		# in the FIPS 204 FAQ.
	# M is the message, a bit-string		# M is the message, a bit-string
	# μ and ctx are byte-strings.		# μ and ctx are byte-strings.
	# ctx is the context string, which defaults to the empty string.		# ctx is the context string, which defaults to the empty string.
	μ = H(BytesToBits(H(pk, 64) || IntegerToBytes(0, 1) ||		μ = H(BytesToBits(H(pk, 64) || IntegerToBytes(0, 1) ||
	IntegerToBytes(|ctx|, 1) || ctx) || M, 64)		IntegerToBytes(|ctx|, 1) || ctx) || M, 64)
	# The functions `BytesToBits` and `IntegerToBytes` are defined		# The functions `BytesToBits` and `IntegerToBytes` are defined
	# in FIPS 204.		# in FIPS 204.
	return μ		return μ
	Figure 1: Computeμ Prehash Operation		Figure 1: Computeμ Pre-Hash Operation
	Sign operations:		Sign operations:
	Signμ(sk, μ):		Signμ(sk, μ):
	# Referred to as 'Externalμ-ML-DSA.Sign(sk, μ)'		# Referred to as 'ExternalMu-ML-DSA.Sign(sk, mu)'
	# in the FIPS 204 FAQ.		# in the FIPS 204 FAQ.
	if |μ| != 64 then		if |μ| != 64 then
	return error # return an error indication if the input μ is not		return error # return an error indication if the input μ is not
	# 64 bytes.		# 64 bytes.
	end if		end if
	rnd = rand(32) # for the optional deterministic variant,		rnd = rand(32) # for the optional deterministic variant,
	# set rnd to all zeroes		# set rnd to all zeroes
	if rnd = NULL then		if rnd = NULL then
	return error # return an error indication if random bit		return error # return an error indication if random bit
	# generation failed		# generation failed
	end if		end if
	sigma = Signμ_internal(sk, μ, rnd, isExternalμ=true)		sigma = Signμ_internal(sk, μ, rnd, isExternalμ=true)
	return sigma		return sigma
	ML-DSA.Signμ_internal(sk, M', rnd, isExternalμ=false):		ML-DSA.Signμ_internal(sk, M', rnd, isExternalμ=false):
	# μ can be passed as an argument instead of M'		# μ is passed to the function via the argument M'.
	# defaulting is Externalμ to false means that		# Defaulting Externalμ to false means that
	# this modified version of Sign_internal can be used		# this modified version of Sign_internal can be used
	# in place of the original without interfering with		# in place of the original without interfering with
	# the functioning of pure ML-DSA mode.		# functioning of pure ML-DSA mode.
	# ... identical to FIPS 204 Algorithm 7, but with Line 6 replaced
	# with		# ... identical to FIPS 204 Algorithm 7, but with Line 6
			# replaced with
	6: if (isExternalμ):		6: if (isExternalμ):
	μ = M'		μ = M'
	else:		else:
	μ = H(BytesToBits(tr) || M', 64)		μ = H(BytesToBits(tr) || M', 64)
	Figure 2: The Operations for Signing μ		Figure 2: The Operations for Signing μ
	There is no need to specify an External μ Verify() routine because		There is no need to specify an External μ Verify() routine because
	this is identical to the original ML-DSA.Verify(). This makes		this is identical to the original ML-DSA.Verify(). This makes
	External μ mode simply an internal optimization of the signer, and		External μ mode simply an internal optimization of the signer, and
End of changes. 29 change blocks.
	71 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.48.