rfc9881v5.txt		rfc9881.txt
	skipping to change at line 214 ¶		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.
	skipping to change at line 300 ¶		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 359 ¶		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 425 ¶		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 454 ¶		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 488 ¶		skipping to change at line 485 ¶
	+=========+=========================+===========+		+=========+=========================+===========+
	| 119 | id-mod-x509-ml-dsa-2025 | RFC 9881 |		| 119 | id-mod-x509-ml-dsa-2025 | RFC 9881 |
	+---------+-------------------------+-----------+		+---------+-------------------------+-----------+
	Table 1: Registered ASN.1 Module		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 2663 ¶		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
End of changes. 10 change blocks.
	20 lines changed or deleted		16 lines changed or added
This html diff was produced by rfcdiff 1.48.