rfc9881v4.txt		rfc9881.txt
	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 226 ¶		skipping to change at line 227 ¶
	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 481 ¶		skipping to change at line 482 ¶
	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 (xi) 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
	skipping to change at line 566 ¶		skipping to change at line 567 ¶
	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 606 ¶		skipping to change at line 607 ¶
	implementation with greater ease -- particularly against side-channel		implementation with greater ease -- particularly against side-channel
	attacks -- it does not necessarily provide resistance to more		attacks -- it does not necessarily provide resistance to more
	powerful attacks such as differential power analysis. Some amount of		powerful attacks such as differential power analysis. Some amount of
	side-channel leakage has been demonstrated in parts of the signing		side-channel leakage has been demonstrated in parts of the signing
	algorithm (specifically the bit-unpacking function), from which a		algorithm (specifically the bit-unpacking function), from which a
	demonstration of key recovery has been made over a large sample of		demonstration of key recovery has been made over a large sample of
	signatures. Masking countermeasures exist for ML-DSA, but comes with		signatures. Masking countermeasures exist for ML-DSA, but comes with
	performance 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
	skipping to change at line 3825 ¶		skipping to change at line 3825 ¶
	| 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).
	skipping to change at line 4064 ¶		skipping to change at line 4064 ¶
	# 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μ Pre-Hash Operation		Figure 1: Computeμ Pre-Hash Operation
	Sign operations:		Sign operations:
	Signμ(sk, μ):		Signμ(sk, μ):
	# Referred to as 'ExternalMu-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
End of changes. 7 change blocks.
	10 lines changed or deleted		11 lines changed or added
This html diff was produced by rfcdiff 1.48.