rfc9883.original		rfc9883.txt
	Network Working Group R. Housley		Internet Engineering Task Force (IETF) R. Housley
	Internet-Draft Vigil Security		Request for Comments: 9883 Vigil Security
	Intended status: Standards Track 26 June 2025		Category: Standards Track October 2025
	Expires: 28 December 2025		ISSN: 2070-1721
	An Attribute for Statement of Possession of a Private Key		An Attribute for Statement of Possession of a Private Key
	draft-ietf-lamps-private-key-stmt-attr-09
	Abstract		Abstract
	This document specifies an attribute for a statement of possession of		This document specifies an attribute for a statement of possession of
	a private key by a certificate subject. As part of X.509 certificate		a private key by a certificate subject. As part of X.509 certificate
	enrollment, a Certification Authority (CA) typically demands proof		enrollment, a Certification Authority (CA) typically demands proof
	that the subject possesses the private key that corresponds to the		that the subject possesses the private key that corresponds to the
	to-be-certified public key. In some cases, a CA might accept a		to-be-certified public key. In some cases, a CA might accept a
	signed statement from the certificate subject. For example, when a		signed statement from the certificate subject. For example, when a
	certificate subject needs separate certificates for signature and key		certificate subject needs separate certificates for signature and key
	establishment, a statement that can be validated with the previously		establishment, a statement that can be validated with the previously
	issued signature certificate for the same subject might be adequate		issued signature certificate for the same subject might be adequate
	for subsequent issuance of the key establishment certificate.		for subsequent issuance of the key establishment certificate.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 28 December 2025.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9883.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. ASN.1
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Overview
	3. Attribute for Statement of Possession of a Private Key . . . 4		3. Attribute for Statement of Possession of a Private Key
	4. Conventions for PKCS#10 . . . . . . . . . . . . . . . . . . . 6		4. Conventions for PKCS#10
	5. Conventions for CRMF . . . . . . . . . . . . . . . . . . . . 6		5. Conventions for CRMF
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		8.1. Normative References
	8.2. Informative References . . . . . . . . . . . . . . . . . 9		8.2. Informative References
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9		Appendix A. ASN.1 Module
	Appendix B. Example use of the privateKeyPossessionStatement		Appendix B. Example Use of the privateKeyPossessionStatement
	Attribute . . . . . . . . . . . . . . . . . . . . . . . . 10		Attribute
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19		Acknowledgements
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19		Author's Address
	1. Introduction		1. Introduction
	This document specifies an attribute for a statement of possession of		This document specifies an attribute for a statement of possession of
	a private key by a certificate subject. X.509 certificate [RFC5280]		a private key by a certificate subject. X.509 certificate [RFC5280]
	enrollment often depends on PKCS#10 [RFC2986] or the Certificate		enrollment often depends on PKCS#10 [RFC2986] or the Certificate
	Request Message Format (CRMF) [RFC4211]. As part of enrollment, a		Request Message Format (CRMF) [RFC4211]. As part of enrollment, a
	Certification Authority (CA) typically demands proof that the subject		Certification Authority (CA) typically demands proof that the subject
	possesses the private key that corresponds to the to-be-certified		possesses the private key that corresponds to the to-be-certified
	public key. Alternatively, a CA may accept a signed statement from		public key. Alternatively, a CA may accept a signed statement from
	the certificate subject claiming knowledge of that private key. When		the certificate subject claiming knowledge of that private key. When
	a certificate subject needs separate certificates for signature and		a certificate subject needs separate certificates for signature and
	key establishment, a signed statement that can be validated with the		key establishment, a signed statement that can be validated with the
	previously issued signature certificate for the same subject might be		previously issued signature certificate for the same subject might be
	adequate for subsequent issuance of the key establishment		adequate for subsequent issuance of the key establishment
	certificate.		certificate.
	For example, a subject may need a signature certificate that contains		For example, a subject may need a signature certificate that contains
	a ML-DSA (Module-Lattice-Based Digital Signature Algorithm) public		an ML-DSA (Module-Lattice-Based Digital Signature Algorithm) public
	key and a key establishment certificate that contains a ML-KEM		key and a key establishment certificate that contains an ML-KEM
	(Module-Lattice-Based Key-Encapsulation Mechanism) public key. For		(Module-Lattice-Based Key-Encapsulation Mechanism) public key. For
	another example, a subject may need a signature certificate that		another example, a subject may need a signature certificate that
	contains a ECDSA (Elliptic Curve Digital Signature Algorithm) public		contains an ECDSA (Elliptic Curve Digital Signature Algorithm) public
	key and a key establishment certificate that contains a ECDH		key and a key establishment certificate that contains an ECDH
	(Elliptic Curve Diffie-Hellman) public key.		(Elliptic Curve Diffie-Hellman) public key.
	A statement of possession may be used in lieu of the usual proof of		A statement of possession may be used in lieu of the usual proof-of-
	possession mechanisms. The statement is simply a signed assertion		possession mechanisms. The statement is simply a signed assertion
	that the requestor of a key establishment certificate has possession		that the requestor of a key establishment certificate has possession
	of the key establishment private key, and that statement is signed		of the key establishment private key and that statement is signed
	using a signature private key that was previously shown to be in the		using a signature private key that was previously shown to be in the
	possession of the same certificate subject. If allowed by the		possession of the same certificate subject. If allowed by the
	Certificate Policy [RFC3647], the CA is permitted to accept this		Certificate Policy [RFC3647], the CA is permitted to accept this
	statement in lieu of proof that the requestor has possession of the		statement in lieu of proof that the requestor has possession of the
	private key, such as [RFC6955].		private key, such as [RFC6955].
	Note that [RFC6955] offers some algorithms that provide proof of		Note that [RFC6955] offers some algorithms that provide proof of
	possession for Diffie-Hellman private keys; however, these algorithms		possession for Diffie-Hellman private keys; however, these algorithms
	are not suitable for use with PKCS#10 [RFC2986]. In addition, the		are not suitable for use with PKCS#10 [RFC2986]. In addition, the
	algorithms in [RFC6955] do not support key encapsulation mechanism		algorithms in [RFC6955] do not support key encapsulation mechanism
	skipping to change at page 3, line 49 ¶		skipping to change at line 131 ¶
	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. Overview		2. Overview
	When using the attribute defined in this document to make a statement		When using the attribute defined in this document to make a statement
	about the possession of the key establishment private key, the		about the possession of the key establishment private key, the
	process to obtain two certificates with PKCS#10 is:		process to obtain two certificates with PKCS#10 is as follows:
	1. The subject generates the signature key pair.		1. The subject generates the signature key pair.
	2. The subject composes a PKCS#10 Certificate Signing Request (CSR)		2. The subject composes a PKCS#10 Certificate Signing Request (CSR)
	in the usual manner. It includes a signature that is produced		in the usual manner. It includes a signature that is produced
	with the private key from step 1.		with the private key from step 1.
	3. The subject sends the CSR to the CA, and it gets back a signature		3. The subject sends the CSR to the CA, and it gets back a signature
	certificate. The signature certificate includes a key usage of		certificate. The signature certificate includes a key usage of
	digitalSignature, nonRepudiation, or both (see Section 4.2.1.3 of		digitalSignature, nonRepudiation, or both (see Section 4.2.1.3 of
	skipping to change at page 5, line 22 ¶		skipping to change at line 200 ¶
	If subject alternative names are present in the certificate request,		If subject alternative names are present in the certificate request,
	they SHOULD match subject alternative names in the signature		they SHOULD match subject alternative names in the signature
	certificate. If they are different, the certificate policy MUST		certificate. If they are different, the certificate policy MUST
	describe how the CA can determine that the two subject alternative		describe how the CA can determine that the two subject alternative
	names identify the same entity. If the CA is unable to determine		names identify the same entity. If the CA is unable to determine
	that each of subject alternative names identifies the same entity as		that each of subject alternative names identifies the same entity as
	is named in the signature certificate, then the CA MUST reject the		is named in the signature certificate, then the CA MUST reject the
	certificate request.		certificate request.
	When the CA rejects a certificate request for any of the reasons		When the CA rejects a certificate request for any of the reasons
	listed above, the CA should provide information to the requester		listed above, the CA should provide information to the requestor
	about the reason for the rejection to aid with diagnostic efforts.		about the reason for the rejection to aid with diagnostic efforts.
	Likewise, the CA should log the rejection events.		Likewise, the CA should log the rejection events.
	The attribute for statement of possession of a private key has the		The attribute for statement of possession of a private key has the
	following structure:		following structure:
	id-at-statementOfPossession OBJECT IDENTIFIER ::=		id-at-statementOfPossession OBJECT IDENTIFIER ::=
	{ 1 3 6 1 4 1 22112 2 1 }		{ 1 3 6 1 4 1 22112 2 1 }
	privateKeyPossessionStatement ATTRIBUTE ::= {		privateKeyPossessionStatement ATTRIBUTE ::= {
	TYPE PrivateKeyPossessionStatement		TYPE PrivateKeyPossessionStatement
	IDENTIFIED BY id-at-statementOfPossession }		IDENTIFIED BY id-at-statementOfPossession }
	PrivateKeyPossessionStatement ::= SEQUENCE {		PrivateKeyPossessionStatement ::= SEQUENCE {
	signer IssuerAndSerialNumber,		signer IssuerAndSerialNumber,
	cert Certificate OPTIONAL }		cert Certificate OPTIONAL }
	The components of the PrivateKeyStatement SEQUENCE have the following		The components of the PrivateKeyStatement SEQUENCE have the following
	semantics:		semantics:
	signer: the issuer name and certificate serial number of the		signer: The issuer name and certificate serial number of the
	signature certificate.		signature certificate.
	cert: the signature certificate. If the issuer of the key		cert: The signature certificate. If the issuer of the key
	establishment certificate will be the same as the issuer of the		establishment certificate will be the same as the issuer of the
	signature certificate, then this component MAY be omitted.		signature certificate, then this component MAY be omitted. When
	When the signature certificate is omitted, the signer is		the signature certificate is omitted, the signer is assuming that
	assuming that the CA has a mechanism to obtain all valid		the CA has a mechanism to obtain all valid certificates that it
	certificates that it issued.		issued.
	4. Conventions for PKCS#10		4. Conventions for PKCS#10
	This section specifies the conventions for using the attribute for		This section specifies the conventions for using the attribute for
	statement of possession of a private key with PKCS#10 [RFC2986] when		statement of possession of a private key with PKCS#10 [RFC2986] when
	requesting a key establishment certificate.		requesting a key establishment certificate.
	The PKCS#10 CertificationRequest always has three components, as		The PKCS#10 CertificationRequest always has three components, as
	follows:		follows:
	certificationRequestInfo: the subject name SHOULD be the same as		certificationRequestInfo: The subject name SHOULD be the same as the
	the subject name in the signature certificate, the		subject name in the signature certificate, the subjectPKInfo MUST
	subjectPKInfo MUST contain the public key for the key		contain the public key for the key establishment algorithm, and
	establishment algorithm, and the attributes MUST include		the attributes MUST include privateKeyPossessionStatement
	privateKeyPossessionStatement attribute as specified in		attribute as specified in Section 3 of this document.
	Section 3 of this document.
	signatureAlgorithm: the signature algorithm MUST be one that can		signatureAlgorithm: The signature algorithm MUST be one that can be
	be validated with the public key in the signature certificate.		validated with the public key in the signature certificate.
	signature: the signature over certificationRequestInfo MUST		signature: The signature over certificationRequestInfo MUST validate
	validate with the public key in the signature certificate, and		with the public key in the signature certificate, and
	certification path validation for the signature certificate		certification path validation for the signature certificate MUST
	MUST be successful as specified in Section 6 of [RFC5280].		be successful as specified in Section 6 of [RFC5280].
	5. Conventions for CRMF		5. Conventions for CRMF
	This section specifies the conventions for using the attribute for		This section specifies the conventions for using the attribute for
	statement of possession of a private key with the CRMF [RFC4211] when		statement of possession of a private key with the CRMF [RFC4211] when
	requesting a key establishment certificate.		requesting a key establishment certificate.
	The following ASN.1 types are defined for use with CRMF. They have		The following ASN.1 types are defined for use with CRMF. They have
	exactly the same semantics and syntax as the attribute discussed		exactly the same semantics and syntax as the attribute discussed
	above, but they offer a similar naming convention to the Registration		above, but they offer a similar naming convention to the Registration
	skipping to change at page 6, line 49 ¶		skipping to change at line 274 ¶
	regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=		regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=
	privateKeyPossessionStatement		privateKeyPossessionStatement
	id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=		id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=
	id-at-statementOfPossession		id-at-statementOfPossession
	The CRMF CertificationRequest always has three components, as		The CRMF CertificationRequest always has three components, as
	follows:		follows:
	certReq: the certTemplate MUST include the subject and the		certReq: The certTemplate MUST include the subject and the publicKey
	publicKey components. The same subject name SHOULD match the		components. The same subject name SHOULD match the subject name
	subject name in the signature certificate, and publicKey MUST		in the signature certificate, and publicKey MUST contain the
	contain the public key for the key establishment algorithm.		public key for the key establishment algorithm.
	popo: the ProofOfPossession MUST use the signature CHOICE, the		popo: The ProofOfPossession MUST use the signature CHOICE, the
	poposkInput MUST be present, POPOSigningKeyInput.authInfo MUST		poposkInput MUST be present, POPOSigningKeyInput.authInfo MUST use
	use the sender CHOICE, the sender SHOULD be set to the subject		the sender CHOICE, the sender SHOULD be set to the subject name
	name that appears in the signature certificate, the publicKey		that appears in the signature certificate, the publicKey MUST
	MUST contain a copy of the public key from the certTemplate,		contain a copy of the public key from the certTemplate, the
	the algorithmIdentifier MUST identify a signature algorithm		algorithmIdentifier MUST identify a signature algorithm that can
	that can be validated with the public key in the signature		be validated with the public key in the signature certificate, the
	certificate, signature over the poposkInput MUST validate with		signature over the poposkInput MUST validate with the public key
	the public key in the signature certificate, and certification		in the signature certificate, and certification path validation
	path validation for the signature certificate MUST be		for the signature certificate MUST be successful as specified in
	successful as specified in Section 6 of [RFC5280].		Section 6 of [RFC5280].
	regInfo: the attributes MUST include		regInfo: The attributes MUST include the
	privateKeyPossessionStatement attribute as specified in		privateKeyPossessionStatement attribute as specified in Section 3
	Section 3 of this document.		of this document.
	6. Security Considerations		6. Security Considerations
	The privateKeyPossessionStatement attribute MUST NOT be used to		The privateKeyPossessionStatement attribute MUST NOT be used to
	obtain a signature certificate. Performing proof of possession of		obtain a signature certificate. Performing proof of possession of
	the signature private key is easily accomplished by signing the		the signature private key is easily accomplished by signing the
	certificate request.		certificate request.
	The subject is signing privateKeyPossessionStatement attribute to		The subject is signing the privateKeyPossessionStatement attribute to
	tell the CA that it has possession of the key establishment private		tell the CA that it has possession of the key establishment private
	key. This is being done instead of providing technical proof of		key. This is being done instead of providing technical proof of
	possession. If the subject has lost control of the signature private		possession. If the subject has lost control of the signature private
	key, then the signed privateKeyPossessionStatement attribute could be		key, then the signed privateKeyPossessionStatement attribute could be
	generated by some other party. Timely revocation of the compromised		generated by some other party. Timely revocation of the compromised
	signature certificate is the only protection against such loss of		signature certificate is the only protection against such loss of
	control.		control.
	If the CA revokes a compromised signature certificate, then the CA		If the CA revokes a compromised signature certificate, then the CA
	SHOULD also revoke all key establishment certificates that were		SHOULD also revoke all key establishment certificates that were
	obtained with privateKeyPossessionStatement attributes signed by that		obtained with privateKeyPossessionStatement attributes signed by that
	compromised signature certificate.		compromised signature certificate.
	The signature key pair and the key establishment key pair are		The signature key pair and the key establishment key pair are
	expected to have roughly the same security strength. To ensure that		expected to have roughly the same security strength. To ensure that
	the signature on the statement is not the weakest part of the		the signature on the statement is not the weakest part of the
	certificate enrollment, the signature key pair SHOULD be at least as		certificate enrollment, the signature key pair SHOULD be at least as
	strong as the key establishment key pair.		strong as the key establishment key pair.
	If a CA allows subject in the key establishment certificate to be		If a CA allows a subject in the key establishment certificate to be
	different than the subject name in the signature certificate, then		different than the subject name in the signature certificate, then
	certificate policy MUST describe how to determine that the two		certificate policy MUST describe how to determine that the two
	subject names identify the same entity. Likewise, if a CA allows		subject names identify the same entity. Likewise, if a CA allows
	subject alternative names in the key establishment certificate that		subject alternative names in the key establishment certificate that
	are not present in the signature certificate, then certificate policy		are not present in the signature certificate, then certificate policy
	MUST describe how to determine that the subject alternative names		MUST describe how to determine that the subject alternative names
	identify the same entity as is named in the signature certificate.		identify the same entity as is named in the signature certificate.
	7. IANA Considerations		7. IANA Considerations
	For the ASN.1 Module in the Appendix A of this document, IANA is		For the ASN.1 Module in Appendix A of this document, IANA has
	requested to assign an object identifier (OID) for the module		assigned an object identifier (OID) for the module identifier (118)
	identifier (TBD0) with a Description of "id-mod-private-key-		with a Description of "id-mod-private-key-possession-stmt-2025" in
	possession-stmt-2025". The OID for the module should be allocated in
	the "SMI Security for PKIX Module Identifier" registry		the "SMI Security for PKIX Module Identifier" registry
	(1.3.6.1.5.5.7.0).		(1.3.6.1.5.5.7.0).
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification		[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
	Request Syntax Specification Version 1.7", RFC 2986,		Request Syntax Specification Version 1.7", RFC 2986,
	DOI 10.17487/RFC2986, November 2000,		DOI 10.17487/RFC2986, November 2000,
	<https://www.rfc-editor.org/rfc/rfc2986>.		<https://www.rfc-editor.org/info/rfc2986>.
	[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure		[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
	Certificate Request Message Format (CRMF)", RFC 4211,		Certificate Request Message Format (CRMF)", RFC 4211,
	DOI 10.17487/RFC4211, September 2005,		DOI 10.17487/RFC4211, September 2005,
	<https://www.rfc-editor.org/rfc/rfc4211>.		<https://www.rfc-editor.org/info/rfc4211>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/rfc/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the		[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
	Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,		Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
	DOI 10.17487/RFC5912, June 2010,		DOI 10.17487/RFC5912, June 2010,
	<https://www.rfc-editor.org/rfc/rfc5912>.		<https://www.rfc-editor.org/info/rfc5912>.
	[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules		[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
	for the Cryptographic Message Syntax (CMS) and the Public		for the Cryptographic Message Syntax (CMS) and the Public
	Key Infrastructure Using X.509 (PKIX)", RFC 6268,		Key Infrastructure Using X.509 (PKIX)", RFC 6268,
	DOI 10.17487/RFC6268, July 2011,		DOI 10.17487/RFC6268, July 2011,
	<https://www.rfc-editor.org/rfc/rfc6268>.		<https://www.rfc-editor.org/info/rfc6268>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[X680] ITU-T, "Information technology -- Abstract Syntax Notation		[X680] ITU-T, "Information technology -- Abstract Syntax Notation
	One (ASN.1): Specification of basic notation", ITU-T		One (ASN.1): Specification of basic notation", ITU-T
	Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,		Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
	<https://www.itu.int/rec/T-REC-X.680>.		<https://www.itu.int/rec/T-REC-X.680>.
	[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>.
	8.2. Informative References		8.2. Informative References
	[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.		[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
	Wu, "Internet X.509 Public Key Infrastructure Certificate		Wu, "Internet X.509 Public Key Infrastructure Certificate
	Policy and Certification Practices Framework", RFC 3647,		Policy and Certification Practices Framework", RFC 3647,
	DOI 10.17487/RFC3647, November 2003,		DOI 10.17487/RFC3647, November 2003,
	<https://www.rfc-editor.org/rfc/rfc3647>.		<https://www.rfc-editor.org/info/rfc3647>.
	[RFC6955] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-		[RFC6955] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
	of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,		of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
	May 2013, <https://www.rfc-editor.org/rfc/rfc6955>.		May 2013, <https://www.rfc-editor.org/info/rfc6955>.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	This ASN.1 Module uses the conventions established by [RFC5912] and		This ASN.1 Module uses the conventions established by [RFC5912] and
	[RFC6268].		[RFC6268].
	<CODE BEGINS>		<CODE BEGINS>
	PrivateKeyPossessionStatement-2025		PrivateKeyPossessionStatement-2025
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-private-key-possession-stmt-2025(TBD0) }		id-mod-private-key-possession-stmt-2025(118) }
	DEFINITIONS IMPLICIT TAGS ::= BEGIN		DEFINITIONS IMPLICIT TAGS ::= BEGIN
	EXPORTS ALL;		EXPORTS ALL;
	IMPORTS		IMPORTS
	ATTRIBUTE		ATTRIBUTE
	FROM PKIX-CommonTypes-2009 -- in [RFC5912]		FROM PKIX-CommonTypes-2009 -- in [RFC5912]
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	skipping to change at page 10, line 48 ¶		skipping to change at line 467 ¶
	regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=		regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=
	privateKeyPossessionStatement		privateKeyPossessionStatement
	id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=		id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=
	id-at-statementOfPossession		id-at-statementOfPossession
	END		END
	<CODE ENDS>		<CODE ENDS>
	Appendix B. Example use of the privateKeyPossessionStatement Attribute		Appendix B. Example Use of the privateKeyPossessionStatement Attribute
	In this example, the self-signed certificate for the CA is:		In this example, the self-signed certificate for the CA is as
			follows:
	-----BEGIN CERTIFICATE-----		-----BEGIN CERTIFICATE-----
	MIIB7DCCAXKgAwIBAgIUL149AUxHunELBZMELEQm+isgKCQwCgYIKoZIzj0EAwMw		MIIB7DCCAXKgAwIBAgIUL149AUxHunELBZMELEQm+isgKCQwCgYIKoZIzj0EAwMw
	NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh		NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh
	LmV4YW1wbGUwHhcNMjUwMTAzMjAyNzA5WhcNMzUwMTAzMjAyNzA5WjA3MQswCQYD		LmV4YW1wbGUwHhcNMjUwMTAzMjAyNzA5WhcNMzUwMTAzMjAyNzA5WjA3MQswCQYD
	VQQGEwJVUzETMBEGA1UEChMKRXhhbXBsZSBDQTETMBEGA1UEAxMKY2EuZXhhbXBs		VQQGEwJVUzETMBEGA1UEChMKRXhhbXBsZSBDQTETMBEGA1UEAxMKY2EuZXhhbXBs
	ZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABDxZdB/Glcxdk1p6Jf1j5en6QfliY9OS		ZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABDxZdB/Glcxdk1p6Jf1j5en6QfliY9OS
	fjZbtje/w6M58PN8Sb3VFln1rPdvD17UXeazSG9Hr/Dq3enbsHHO0pPntcFOgb8n		fjZbtje/w6M58PN8Sb3VFln1rPdvD17UXeazSG9Hr/Dq3enbsHHO0pPntcFOgb8n
	r8R8LUGhxRzjlxkaEJN+pa6Nf7qk49JDeaM/MD0wDwYDVR0TAQH/BAUwAwEB/zAL		r8R8LUGhxRzjlxkaEJN+pa6Nf7qk49JDeaM/MD0wDwYDVR0TAQH/BAUwAwEB/zAL
	BgNVHQ8EBAMCAgQwHQYDVR0OBBYEFD6YvLLv3DQbvnGS0qP6bbzyZkCqMAoGCCqG		BgNVHQ8EBAMCAgQwHQYDVR0OBBYEFD6YvLLv3DQbvnGS0qP6bbzyZkCqMAoGCCqG
	SM49BAMDA2gAMGUCMGfb61IigoJ3QDnlsRdoktREHe0Dpm6DKw3qOyLL6A0cFK9Z		SM49BAMDA2gAMGUCMGfb61IigoJ3QDnlsRdoktREHe0Dpm6DKw3qOyLL6A0cFK9Z
	g8m11xIwvptlran52gIxAK1VrOjzRsFiHRptO+gFXstTXnQkKBb2/3WQz2SqcIS/		g8m11xIwvptlran52gIxAK1VrOjzRsFiHRptO+gFXstTXnQkKBb2/3WQz2SqcIS/
	BWEp+siJ19OXOlz6APDB7w==		BWEp+siJ19OXOlz6APDB7w==
	-----END CERTIFICATE-----		-----END CERTIFICATE-----
	Alice generates her ECDSA signature key pair. Then, Alice composes a		Alice generates her ECDSA signature key pair. Then, Alice composes a
	PKCS#10 Certificate Signing Request (CSR) in the usual manner as		PKCS#10 Certificate Signing Request (CSR) in the usual manner as
	specified in [RFC2986]. The CSR includes a signature that is		specified in [RFC2986]. The CSR includes a signature that is
	produced with her ECDSA private key. The CSR is:		produced with her ECDSA private key. The CSR is as follows:
	-----BEGIN CERTIFICATE REQUEST-----		-----BEGIN CERTIFICATE REQUEST-----
	MIIBhTCCAQsCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH		MIIBhTCCAQsCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH
	EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB2MBAGByqGSM49AgEGBSuBBAAiA2IA		EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB2MBAGByqGSM49AgEGBSuBBAAiA2IA
	BIAc+6lXN1MIM/82QeWNb55H0zr+lVgWVeF0bf4jzxCb5MCjVaM0eFEvcjXMV5p4		BIAc+6lXN1MIM/82QeWNb55H0zr+lVgWVeF0bf4jzxCb5MCjVaM0eFEvcjXMV5p4
	kzqiJTHC0V2JAoqYMX/DMFIcwZ7xP9uQd9ep6KZ+RXut211L8+W1QI1QJSDNxANR		kzqiJTHC0V2JAoqYMX/DMFIcwZ7xP9uQd9ep6KZ+RXut211L8+W1QI1QJSDNxANR
	saBQME4GCSqGSIb3DQEJDjFBMD8wDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCB4Aw		saBQME4GCSqGSIb3DQEJDjFBMD8wDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCB4Aw
	IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wCgYIKoZIzj0EAwMD		IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wCgYIKoZIzj0EAwMD
	aAAwZQIwPa2rOCe60edAF43C/t57IW8liyy+69FE04hMAFgw3Ga+nR+8zDuUsVLw		aAAwZQIwPa2rOCe60edAF43C/t57IW8liyy+69FE04hMAFgw3Ga+nR+8zDuUsVLw
	xXGAHtcDAjEA6LbvNkZjo6j2z5xRIjrHzEbGgiV4MF4xtnpfSSRI4dB0zT52bWkj		xXGAHtcDAjEA6LbvNkZjo6j2z5xRIjrHzEbGgiV4MF4xtnpfSSRI4dB0zT52bWkj
	skipping to change at page 12, line 4 ¶		skipping to change at line 519 ¶
	VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT		VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT
	BUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEgBz7qVc3Uwgz/zZB5Y1vnkfT		BUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEgBz7qVc3Uwgz/zZB5Y1vnkfT
	Ov6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxXmniTOqIlMcLRXYkCipgxf8MwUhzB		Ov6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxXmniTOqIlMcLRXYkCipgxf8MwUhzB
	nvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3EA1Gxo3YwdDAMBgNVHRMBAf8EAjAA		nvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3EA1Gxo3YwdDAMBgNVHRMBAf8EAjAA
	MAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A0f7tCzkQEZgYzH3NcM2L05IwHwYD		MAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A0f7tCzkQEZgYzH3NcM2L05IwHwYD
	VR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJmQKowFwYDVR0gBBAwDjAMBgpghkgB		VR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJmQKowFwYDVR0gBBAwDjAMBgpghkgB
	ZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/Uypd7BaVnUjB36UtX9m5ZmPi78y5		ZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/Uypd7BaVnUjB36UtX9m5ZmPi78y5
	1RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIwRJ6U91048NAb3nicHcrGFf1UYrhb		1RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIwRJ6U91048NAb3nicHcrGFf1UYrhb
	DlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u		DlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u
	-----END CERTIFICATE-----		-----END CERTIFICATE-----
	Alice generates her ECDH key establishment key pair. Then, Alice		Alice generates her ECDH key establishment key pair. Then, Alice
	composes a PKCS#10 CSR. The CSR attributes include the		composes a PKCS#10 CSR. The CSR attributes include the
	privateKeyPossessionStatement attribute, which points to her ECDSA		privateKeyPossessionStatement attribute, which points to her ECDSA
	signature certificate. The CSR includes her ECDH public key and a		signature certificate. The CSR includes her ECDH public key and a
	signature that is produced with her ECDSA private key. The CSR is:		signature that is produced with her ECDSA private key. The CSR is as
			follows:
	-----BEGIN CERTIFICATE REQUEST-----		-----BEGIN CERTIFICATE REQUEST-----
	MIIEMTCCA7gCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH		MIIEMTCCA7gCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH
	EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB0MA4GBSuBBAEMBgUrgQQAIgNiAAQB		EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB0MA4GBSuBBAEMBgUrgQQAIgNiAAQB
	RyQTH+cq1s5F94uFqFe7l1LqGdEC8Tm+e5VYBCfKAC8MJySQMj1GixEEXL+1Wjtg		RyQTH+cq1s5F94uFqFe7l1LqGdEC8Tm+e5VYBCfKAC8MJySQMj1GixEEXL+1Wjtg
	23XvnJouCDoxSpDCSMqf3kvp5+naM37uxa3ZYgD6DPY3me5EZvyZPvSRJTFl/Bag		23XvnJouCDoxSpDCSMqf3kvp5+naM37uxa3ZYgD6DPY3me5EZvyZPvSRJTFl/Bag
	ggL9MGcGCSqGSIb3DQEJDjFaMFgwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCAwgw		ggL9MGcGCSqGSIb3DQEJDjFaMFgwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCAwgw
	IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wFwYDVR0gBBAwDjAM		IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wFwYDVR0gBBAwDjAM
	BgpghkgBZQMCATAwMIICkAYKKwYBBAGBrGACATGCAoAwggJ8ME8wNzELMAkGA1UE		BgpghkgBZQMCATAwMIICkAYKKwYBBAGBrGACATGCAoAwggJ8ME8wNzELMAkGA1UE
	BhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUC		BhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUC
	skipping to change at page 12, line 36 ¶		skipping to change at line 553 ¶
	A1Gxo3YwdDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A		A1Gxo3YwdDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A
	0f7tCzkQEZgYzH3NcM2L05IwHwYDVR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJm		0f7tCzkQEZgYzH3NcM2L05IwHwYDVR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJm
	QKowFwYDVR0gBBAwDjAMBgpghkgBZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/		QKowFwYDVR0gBBAwDjAMBgpghkgBZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/
	Uypd7BaVnUjB36UtX9m5ZmPi78y51RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIw		Uypd7BaVnUjB36UtX9m5ZmPi78y51RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIw
	RJ6U91048NAb3nicHcrGFf1UYrhbDlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u		RJ6U91048NAb3nicHcrGFf1UYrhbDlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u
	MAoGCCqGSM49BAMDA2cAMGQCL2TNHPULWcCS2DqZCCiQeSwx2JPLMI14Vi977bzy		MAoGCCqGSM49BAMDA2cAMGQCL2TNHPULWcCS2DqZCCiQeSwx2JPLMI14Vi977bzy
	rImq5p0H3Bel6fAS8BnQ00WNAjEAhHDAlcbRuHhqdW6mOgDd5kWEGGqgixIuvEEc		rImq5p0H3Bel6fAS8BnQ00WNAjEAhHDAlcbRuHhqdW6mOgDd5kWEGGqgixIuvEEc
	fVbnNCEyEE4n0mQ99PHURnXoHwqF		fVbnNCEyEE4n0mQ99PHURnXoHwqF
	-----END CERTIFICATE REQUEST-----		-----END CERTIFICATE REQUEST-----
	The CSR decodes to:		The CSR decodes to the following:
	0 1073: SEQUENCE {		0 1073: SEQUENCE {
	4 952: SEQUENCE {		4 952: SEQUENCE {
	8 1: INTEGER 0		8 1: INTEGER 0
	11 60: SEQUENCE {		11 60: SEQUENCE {
	13 11: SET {		13 11: SET {
	15 9: SEQUENCE {		15 9: SEQUENCE {
	17 3: OBJECT IDENTIFIER countryName (2 5 4 6)		17 3: OBJECT IDENTIFIER countryName (2 5 4 6)
	22 2: PrintableString 'US'		22 2: PrintableString 'US'
	: }		: }
	skipping to change at page 19, line 30 ¶		skipping to change at line 878 ¶
	Acknowledgements		Acknowledgements
	Thanks to Sean Turner, Joe Mandel, Mike StJohns, Mike Ounsworth, John		Thanks to Sean Turner, Joe Mandel, Mike StJohns, Mike Ounsworth, John
	Gray, Carl Wallace, Corey Bonnell, Hani Ezzadeen, Deb Cooley, Mohamed		Gray, Carl Wallace, Corey Bonnell, Hani Ezzadeen, Deb Cooley, Mohamed
	Boucadair, and Bron Gondwana for their constructive comments.		Boucadair, and Bron Gondwana for their constructive comments.
	Author's Address		Author's Address
	Russ Housley		Russ Housley
	Vigil Security, LLC		Vigil Security, LLC
	Herndon, VA,		Herndon, VA
	United States of America		United States of America
	Email: housley@vigilsec.com		Email: housley@vigilsec.com
End of changes. 42 change blocks.
	110 lines changed or deleted		108 lines changed or added
This html diff was produced by rfcdiff 1.48.