| Internet-Draft | Statement of Private Key Possession | January 2025 |
| Housley | Expires 13 July 2025 | [Page] |
This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate enrollment, a Certification Authority (CA) typically demands proof that the subject possesses of the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate.¶
This Internet-Draft is submitted in full conformance with the 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 13 July 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document specifies an attribute for a statement of possession of a private key by a certificate subject. As part of X.509 certificate [RFC5280] enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. In some cases, a CA might accept a signed statement from the certificate subject. For example, when a certificate subject needs separate certificates for signature and key establishment, a signed statement that can be validated with the previously issued signature certificate for the same subject might be adequate for subsequent issuance of the key establishment certificate. Note that [RFC6955] offers some algorithms to provide proof of possession for Diffie-Hellman private keys. However, these algorithms are not suitable for use with PKCS#10 [RFC2986]. On the other hand, the the attribute specified in this document is suitable for use with PKCS#10.¶
In many situations a subject needs two certificates, one for digiatal signatures, and a separate one for key establishment. For example, a subject may need a signature certificate that contains a ML-DSA public key and a key establishment certificate that contains a ML-KEM public key. For another example, a subject may need a signature certificate that contains a ECDSA public key and a key establishment certificate that contains a ECDH public key.¶
In this situation, a CA might accept a signed statement that can be validated with the previously issued signature certificate as adequate for subsequent issuance of the key establishment certificate.¶
When using the attribute defined in this document make a statement about the possession of the key establishment private key, the process for a subject to obtain two certificates is:¶
The subject generates the signature key pair.¶
The subject composes a PKCS#10 Certificate Signing Request (CSR) in the usual manner. It includes a signature that is produced with the private key from step 1.¶
The subject sends the CSR to the CA, and it gets back a signature certificate. The signature certificate includes a key usage of digitalSignature, nonRepudiation, or both Section 4.2.1.3 of [RFC5280].¶
The subject generates the key establishment key pair.¶
The subject composes a PKCS#10 CSR containing the key establishment public key. The CSR attributes include the attribute specified in Section 2 of this document. The subject name matches the one from step 2. The CSR includes a signature that is produced with the private key from step 1.¶
The subject sends the CSR to the CA, and it gets back a key establishment certificate. The key establishment certificate includes a key usage of keyEncipherment or keyAgreement Section 4.2.1.3 of [RFC5280].¶
The attestation attribute is generated using ASN.1 [X680], using the Distinguished Encoding Rules (DER) [X690].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The attribute for statement of possession of a private key is included in a certificate request to make the following statement:¶
"The subject of the signature certificate that is used to validate the signature on this certificate request also has possession of the private key that corresponds to the public key in the certificate request."¶
The CA MUST perform certification path validation for the signature certificate as specified in Section 6 of [RFC5280]. If the certification path is not valid, then the CA MUST reject the certificate request.¶
The CA MUST validate the signature on the certificate request using the public key from the signature certificate. If the signature is not valid, then the CA MUST reject the certificate request.¶
The subject in the signature certificate SHOULD be the same as the subject name in the certificate request. If they are different, the certificate policy MUST describe how the CA can determine that the two subject names identify the same entity. If the CA is unable to determine that the two subject names identify the same entity, then the CA MUST reject the certificate request.¶
If subject alternative names are present in the certificate request, they SHOULD match subject alternative names in the signature certificate. If the CA is unable to determine that each of subject alternative names identifies the same entity as is named in the signature certificate, then the CA MUST reject the certificate request.¶
The attribute for statement of possession of a private key has the following structure:¶
id-at-privateKeyStatement OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 22112 2 1 }
privateKeyStatement ATTRIBUTE ::= {
TYPE PrivateKeyStatement
IDENTIFIED BY id-at-privateKeyStatement }
PrivateKeyStatement ::= SEQUENCE {
signer IssuerAndSerialNumber,
cert Certificate OPTIONAL }
¶
The components of the PrivateKeyStatement SEQUENCE have the following semantics:¶
the issuer name and certificate serial number of the signature certificate.¶
the signature certificate. If the issuer of the key establishment certificate will be the same as the issuer of the signature certificate, then this component MAY be omitted. When the signature certificate is omitted, the signer is assuming that the CA has a mechanism to obtain all valid certificates that it issued.¶
This section specifies the conventions for using the attribute for statement of possession of a private key with PKCS#10 [RFC2986] when requesting a key establishment certificate.¶
The PKCS#10 CertificationRequest always has three components, as follows:¶
the subject name SHOULD be the same as the subject name in the signature certificate, the subjectPKInfo MUST contain the public key for the key establishment algorithm, and the attributes MUST include privateKeyStatement attribute as specified in Section 2 of this document.¶
the signature algorithm MUST be one that can be validated with the public key in the signature certificate.¶
This section specifies the conventions for using the attribute for statement of possession of a private key with the Certificate Request Message Format (CRMF) [RFC4211] when requesting a key establisment certificate.¶
The following ASN.1 types are defined for use with CRMF. They have exactly the same semantics and syntax as the attribute discussed above, but they offer a similar naming convention to the Registration Controls in [RFC4211].¶
regCtrl-privateKeyStatement ATTRIBUTE ::= privateKeyStatement
id-regCtrl-privateKeyStatement OBJECT IDENTIFIER ::=
id-at-privateKeyStatement
¶
The CRMF CertificationRequest always has three components, as follows:¶
the certTemplate MUST include the subject and the publicKey components. The same subject name SHOULD match the subject name in the signature certificate, and publicKey MUST contain the public key for the key establishment algorithm.¶
the ProofOfPossession MUST use the signature CHOICE, the poposkInput MUST be present, POPOSigningKeyInput.authInfo MUST use the sender CHOICE, the sender MUST set to the subject name that appears in the signature certificate, the publicKey MUST contain a copy of the public key from the certTemplate, the algorithmIdentifier MUST identify a signture algorithm that can be validated with the public key in the signature certificate, signature over the poposkInput MUST validate with the public key in the signature certificate, and certification path validation for the signature certificate MUST be successful as specified in Section 6 of [RFC5280].¶
The subject is signing privateKeyStatement attribute to tell the CA that it has possession of the key establishment private key. This is being done instead of providing some other form of proof of possession. If the subject has lost control of the signature private key, then the signed privateKeyStatement attribute could be generated by some other party. Timely revocation of the compromised signature certificate is the only protection against such loss of control.¶
The signature key pair and the key establishment key pair are expected to have roughly the same security strength. To ensure that the signature on the attestation is not the weak part of the certificate enrollment, the signature key pair SHOULD be at least as strong as the key establishment key pair.¶
If a CA allows subject in the key establishment certificate to be different than the subject name in the signature certificate, then certificate policy MUST describe how to determine that the two subject names identify the same entity. Likewise, if a CA allows subject alternative names in the key establishment certificate that are not present in the signature certificate, then certificate policy MUST describe how to determine that the subject alternative names identify the same entity as is named in the signature certificate.¶
For the ASN.1 Module in the Appendix A of this document, IANA is requested to assign an object identifier (OID) for the module identifier (TBD0) with a Description of "id-mod-private-key-stmt-2025". The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).¶
This ASN.1 Module builds upon the conventions established in [RFC5912].¶
<CODE STARTS>
PrivateKeyStatement-2025
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-private-key-stmt-2025(TBD0) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
ATTRIBUTE
FROM PKIX-CommonTypes-2009 -- in [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
Certificate
FROM PKIX1Explicit-2009 -- in [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) }
IssuerAndSerialNumber
FROM CryptographicMessageSyntax-2010 -- [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2009(58) } ;
--
-- Private Key Statement Attribute
--
id-at-privateKeyStatement OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 22112 2 1 }
privateKeyStatement ATTRIBUTE ::= {
TYPE PrivateKeyStatement
IDENTIFIED BY id-at-privateKeyStatement }
PrivateKeyStatement ::= SEQUENCE {
signer IssuerAndSerialNumber,
cert Certificate OPTIONAL }
--
-- Registration Control Support
--
RegControlSet ATTRIBUTE ::= { regCtrl-privateKeStatement, ... }
regCtrl-privateKeyStatement ATTRIBUTE ::= privateKeyStatement
id-regCtrl-privateKeyStatement OBJECT IDENTIFIER ::=
id-at-privateKeyStatement
END
<CODE ENDS>
¶
In this example, the self-signed certificate for the CA is:¶
-----BEGIN CERTIFICATE----- MIIB7DCCAXKgAwIBAgIUL149AUxHunELBZMELEQm+isgKCQwCgYIKoZIzj0EAwMw NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh LmV4YW1wbGUwHhcNMjUwMTAzMjAyNzA5WhcNMzUwMTAzMjAyNzA5WjA3MQswCQYD VQQGEwJVUzETMBEGA1UEChMKRXhhbXBsZSBDQTETMBEGA1UEAxMKY2EuZXhhbXBs ZTB2MBAGByqGSM49AgEGBSuBBAAiA2IABDxZdB/Glcxdk1p6Jf1j5en6QfliY9OS fjZbtje/w6M58PN8Sb3VFln1rPdvD17UXeazSG9Hr/Dq3enbsHHO0pPntcFOgb8n r8R8LUGhxRzjlxkaEJN+pa6Nf7qk49JDeaM/MD0wDwYDVR0TAQH/BAUwAwEB/zAL BgNVHQ8EBAMCAgQwHQYDVR0OBBYEFD6YvLLv3DQbvnGS0qP6bbzyZkCqMAoGCCqG SM49BAMDA2gAMGUCMGfb61IigoJ3QDnlsRdoktREHe0Dpm6DKw3qOyLL6A0cFK9Z g8m11xIwvptlran52gIxAK1VrOjzRsFiHRptO+gFXstTXnQkKBb2/3WQz2SqcIS/ BWEp+siJ19OXOlz6APDB7w== -----END CERTIFICATE-----¶
Alice generates her ECDSA signature key pair. Then, Alice composes a PKCS#10 Certificate Signing Request (CSR) in the usual manner as specified in [RFC2986]. The CSR includes a signature that is produced with her ECDSA private key. The CSR is:¶
-----BEGIN CERTIFICATE REQUEST----- MIIBhTCCAQsCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB2MBAGByqGSM49AgEGBSuBBAAiA2IA BIAc+6lXN1MIM/82QeWNb55H0zr+lVgWVeF0bf4jzxCb5MCjVaM0eFEvcjXMV5p4 kzqiJTHC0V2JAoqYMX/DMFIcwZ7xP9uQd9ep6KZ+RXut211L8+W1QI1QJSDNxANR saBQME4GCSqGSIb3DQEJDjFBMD8wDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCB4Aw IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wCgYIKoZIzj0EAwMD aAAwZQIwPa2rOCe60edAF43C/t57IW8liyy+69FE04hMAFgw3Ga+nR+8zDuUsVLw xXGAHtcDAjEA6LbvNkZjo6j2z5xRIjrHzEbGgiV4MF4xtnpfSSRI4dB0zT52bWkj TZsuS1YWIkjt -----END CERTIFICATE REQUEST-----¶
The CA issues a signature certificate to Alice:¶
-----BEGIN CERTIFICATE----- MIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHkwCgYIKoZIzj0EAwMw NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh LmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcNMjYwMTA5MTcwMzQ4WjA8MQswCQYD VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT BUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEgBz7qVc3Uwgz/zZB5Y1vnkfT Ov6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxXmniTOqIlMcLRXYkCipgxf8MwUhzB nvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3EA1Gxo3YwdDAMBgNVHRMBAf8EAjAA MAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A0f7tCzkQEZgYzH3NcM2L05IwHwYD VR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJmQKowFwYDVR0gBBAwDjAMBgpghkgB ZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/Uypd7BaVnUjB36UtX9m5ZmPi78y5 1RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIwRJ6U91048NAb3nicHcrGFf1UYrhb DlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u -----END CERTIFICATE-----¶
Alice generates her ECDH key establishment key pair. Then, Alice composes a PKCS#10 CSR. The CSR attributes include the privateKeyStatement attribute, which points to her ECDSA signature certificate. The CSR includes her ECDH public key and a signature that is produced with her ECDSA private key. The CSR is:¶
-----BEGIN CERTIFICATE REQUEST----- MIIEMTCCA7gCAQAwPDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlZBMRAwDgYDVQQH EwdIZXJuZG9uMQ4wDAYDVQQDEwVBbGljZTB0MA4GBSuBBAEMBgUrgQQAIgNiAAQB RyQTH+cq1s5F94uFqFe7l1LqGdEC8Tm+e5VYBCfKAC8MJySQMj1GixEEXL+1Wjtg 23XvnJouCDoxSpDCSMqf3kvp5+naM37uxa3ZYgD6DPY3me5EZvyZPvSRJTFl/Bag ggL9MGcGCSqGSIb3DQEJDjFaMFgwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCAwgw IgYDVR0RBBswGYEXYWxpY2VAZW1haWwuZXhhbXBsZS5jb20wFwYDVR0gBBAwDjAM BgpghkgBZQMCATAwMIICkAYKKwYBBAGBrGACATGCAoAwggJ8ME8wNzELMAkGA1UE BhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUC FH90o/wDbOIUeFxZYU5vjfJMR6h5MIICJzCCAa6gAwIBAgIUf3Sj/ANs4hR4XFlh Tm+N8kxHqHkwCgYIKoZIzj0EAwMwNzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4 YW1wbGUgQ0ExEzARBgNVBAMTCmNhLmV4YW1wbGUwHhcNMjUwMTA5MTcwMzQ4WhcN MjYwMTA5MTcwMzQ4WjA8MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNV BAcTB0hlcm5kb24xDjAMBgNVBAMTBUFsaWNlMHYwEAYHKoZIzj0CAQYFK4EEACID YgAEgBz7qVc3Uwgz/zZB5Y1vnkfTOv6VWBZV4XRt/iPPEJvkwKNVozR4US9yNcxX mniTOqIlMcLRXYkCipgxf8MwUhzBnvE/25B316nopn5Fe63bXUvz5bVAjVAlIM3E A1Gxo3YwdDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQUIx0A 0f7tCzkQEZgYzH3NcM2L05IwHwYDVR0jBBgwFoAUPpi8su/cNBu+cZLSo/ptvPJm QKowFwYDVR0gBBAwDjAMBgpghkgBZQMCATAwMAoGCCqGSM49BAMDA2cAMGQCMGu/ Uypd7BaVnUjB36UtX9m5ZmPi78y51RA8WhbOv0KQVrcYtj4qOdiMVKBcoVceyAIw RJ6U91048NAb3nicHcrGFf1UYrhbDlytK4tCa5HBxD/qAgy4/eUzA5NZwVaLK78u MAoGCCqGSM49BAMDA2cAMGQCL2TNHPULWcCS2DqZCCiQeSwx2JPLMI14Vi977bzy rImq5p0H3Bel6fAS8BnQ00WNAjEAhHDAlcbRuHhqdW6mOgDd5kWEGGqgixIuvEEc fVbnNCEyEE4n0mQ99PHURnXoHwqF -----END CERTIFICATE REQUEST-----¶
The CSR decodes to:¶
0 1073: SEQUENCE {
4 952: SEQUENCE {
8 1: INTEGER 0
11 60: SEQUENCE {
13 11: SET {
15 9: SEQUENCE {
17 3: OBJECT IDENTIFIER countryName (2 5 4 6)
22 2: PrintableString 'US'
: }
: }
26 11: SET {
28 9: SEQUENCE {
30 3: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
35 2: PrintableString 'VA'
: }
: }
39 16: SET {
41 14: SEQUENCE {
43 3: OBJECT IDENTIFIER localityName (2 5 4 7)
48 7: PrintableString 'Herndon'
: }
: }
57 14: SET {
59 12: SEQUENCE {
61 3: OBJECT IDENTIFIER commonName (2 5 4 3)
66 5: PrintableString 'Alice'
: }
: }
: }
73 116: SEQUENCE {
75 14: SEQUENCE {
77 5: OBJECT IDENTIFIER ECDH (1 3 132 1 12)
84 5: OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
: }
91 98: BIT STRING
: 04 01 47 24 13 1F E7 2A D6 CE 45 F7 8B 85 A8 57
: BB 97 52 EA 19 D1 02 F1 39 BE 7B 95 58 04 27 CA
: 00 2F 0C 27 24 90 32 3D 46 8B 11 04 5C BF B5 5A
: 3B 60 DB 75 EF 9C 9A 2E 08 3A 31 4A 90 C2 48 CA
: 9F DE 4B E9 E7 E9 DA 33 7E EE C5 AD D9 62 00 FA
: 0C F6 37 99 EE 44 66 FC 99 3E F4 91 25 31 65 FC
: 16
: }
191 765: [0] {
195 103: SEQUENCE {
197 9: OBJECT IDENTIFIER
: extensionRequest (1 2 840 113549 1 9 14)
208 90: SET {
210 88: SEQUENCE {
212 12: SEQUENCE {
214 3: OBJECT IDENTIFIER
: basicConstraints (2 5 29 19)
219 1: BOOLEAN TRUE
222 2: OCTET STRING, encapsulates {
224 0: SEQUENCE {}
: }
: }
226 11: SEQUENCE {
228 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
233 4: OCTET STRING, encapsulates {
235 2: BIT STRING 3 unused bits
: '10000'B (bit 4)
: }
: }
239 34: SEQUENCE {
241 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
246 27: OCTET STRING, encapsulates {
248 25: SEQUENCE {
250 23: [1] 'alice@email.example.com'
: }
: }
: }
275 23: SEQUENCE {
277 3: OBJECT IDENTIFIER
: certificatePolicies (2 5 29 32)
282 16: OCTET STRING, encapsulates {
284 14: SEQUENCE {
286 12: SEQUENCE {
288 10: OBJECT IDENTIFIER
: testCertPolicy (2 16 840 1 101 3 2 1 48 48)
: }
: }
: }
: }
: }
: }
: }
300 656: SEQUENCE {
304 10: OBJECT IDENTIFIER
: privateKeyAttest (1 3 6 1 4 1 22112 2 1)
316 640: SET {
320 636: SEQUENCE {
324 79: SEQUENCE {
326 55: SEQUENCE {
328 11: SET {
330 9: SEQUENCE {
332 3: OBJECT IDENTIFIER countryName (2 5 4 6)
337 2: PrintableString 'US'
: }
: }
341 19: SET {
343 17: SEQUENCE {
345 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
350 10: PrintableString 'Example CA'
: }
: }
362 19: SET {
364 17: SEQUENCE {
366 3: OBJECT IDENTIFIER commonName (2 5 4 3)
371 10: PrintableString 'ca.example'
: }
: }
: }
383 20: INTEGER
: 7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2
: 4C 47 A8 79
: }
405 551: SEQUENCE {
409 430: SEQUENCE {
413 3: [0] {
415 1: INTEGER 2
: }
418 20: INTEGER
: 7F 74 A3 FC 03 6C E2 14 78 5C 59 61 4E 6F 8D F2
: 4C 47 A8 79
440 10: SEQUENCE {
442 8: OBJECT IDENTIFIER
: ecdsaWithSHA384 (1 2 840 10045 4 3 3)
: }
452 55: SEQUENCE {
454 11: SET {
456 9: SEQUENCE {
458 3: OBJECT IDENTIFIER
: countryName (2 5 4 6)
463 2: PrintableString 'US'
: }
: }
467 19: SET {
469 17: SEQUENCE {
471 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
476 10: PrintableString 'Example CA'
: }
: }
488 19: SET {
490 17: SEQUENCE {
492 3: OBJECT IDENTIFIER
: commonName (2 5 4 3)
497 10: PrintableString 'ca.example'
: }
: }
: }
509 30: SEQUENCE {
511 13: UTCTime 09/01/2025 17:03:48 GMT
526 13: UTCTime 09/01/2026 17:03:48 GMT
: }
541 60: SEQUENCE {
543 11: SET {
545 9: SEQUENCE {
547 3: OBJECT IDENTIFIER
: countryName (2 5 4 6)
552 2: PrintableString 'US'
: }
: }
556 11: SET {
558 9: SEQUENCE {
560 3: OBJECT IDENTIFIER
: stateOrProvinceName (2 5 4 8)
565 2: PrintableString 'VA'
: }
: }
569 16: SET {
571 14: SEQUENCE {
573 3: OBJECT IDENTIFIER
: localityName (2 5 4 7)
578 7: PrintableString 'Herndon'
: }
: }
587 14: SET {
589 12: SEQUENCE {
591 3: OBJECT IDENTIFIER
: commonName (2 5 4 3)
596 5: PrintableString 'Alice'
: }
: }
: }
603 118: SEQUENCE {
605 16: SEQUENCE {
607 7: OBJECT IDENTIFIER
: ecPublicKey (1 2 840 10045 2 1)
616 5: OBJECT IDENTIFIER
: secp384r1 (1 3 132 0 34)
: }
623 98: BIT STRING
: 04 80 1C FB A9 57 37 53 08 33 FF 36 41 E5 8D 6F
: 9E 47 D3 3A FE 95 58 16 55 E1 74 6D FE 23 CF 10
: 9B E4 C0 A3 55 A3 34 78 51 2F 72 35 CC 57 9A 78
: 93 3A A2 25 31 C2 D1 5D 89 02 8A 98 31 7F C3 30
: 52 1C C1 9E F1 3F DB 90 77 D7 A9 E8 A6 7E 45 7B
: AD DB 5D 4B F3 E5 B5 40 8D 50 25 20 CD C4 03 51
: B1
: }
723 118: [3] {
725 116: SEQUENCE {
727 12: SEQUENCE {
729 3: OBJECT IDENTIFIER
: basicConstraints (2 5 29 19)
734 1: BOOLEAN TRUE
737 2: OCTET STRING, encapsulates {
739 0: SEQUENCE {}
: }
: }
741 11: SEQUENCE {
743 3: OBJECT IDENTIFIER
: keyUsage (2 5 29 15)
748 4: OCTET STRING, encapsulates {
750 2: BIT STRING 7 unused bits
: '1'B (bit 0)
: }
: }
754 29: SEQUENCE {
756 3: OBJECT IDENTIFIER
: subjectKeyIdentifier (2 5 29 14)
761 22: OCTET STRING, encapsulates {
763 20: OCTET STRING
: 23 1D 00 D1 FE ED 0B 39 10 11 98 18 CC 7D CD 70
: CD 8B D3 92
: }
: }
785 31: SEQUENCE {
787 3: OBJECT IDENTIFIER
: authorityKeyIdentifier (2 5 29 35)
792 24: OCTET STRING, encapsulates {
794 22: SEQUENCE {
796 20: [0]
: 3E 98 BC B2 EF DC 34 1B BE 71 92 D2 A3 FA 6D BC
: F2 66 40 AA
: }
: }
: }
818 23: SEQUENCE {
820 3: OBJECT IDENTIFIER
: certificatePolicies (2 5 29 32)
825 16: OCTET STRING, encapsulates {
827 14: SEQUENCE {
829 12: SEQUENCE {
831 10: OBJECT IDENTIFIER
: testCertPolicy (2 16 840 1 101 3 2 1 48 48)
: }
: }
: }
: }
: }
: }
: }
843 10: SEQUENCE {
845 8: OBJECT IDENTIFIER
: ecdsaWithSHA384 (1 2 840 10045 4 3 3)
: }
855 103: BIT STRING, encapsulates {
858 100: SEQUENCE {
860 48: INTEGER
: 6B BF 53 2A 5D EC 16 95 9D 48 C1 DF A5 2D 5F D9
: B9 66 63 E2 EF CC B9 D5 10 3C 5A 16 CE BF 42 90
: 56 B7 18 B6 3E 2A 39 D8 8C 54 A0 5C A1 57 1E C8
910 48: INTEGER
: 44 9E 94 F7 5D 38 F0 D0 1B DE 78 9C 1D CA C6 15
: FD 54 62 B8 5B 0E 5C AD 2B 8B 42 6B 91 C1 C4 3F
: EA 02 0C B8 FD E5 33 03 93 59 C1 56 8B 2B BF 2E
: }
: }
: }
: }
: }
: }
: }
: }
960 10: SEQUENCE {
962 8: OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
: }
972 103: BIT STRING, encapsulates {
975 100: SEQUENCE {
977 47: INTEGER
: 64 CD 1C F5 0B 59 C0 92 D8 3A 99 08 28 90 79 2C
: 31 D8 93 CB 30 8D 78 56 2F 7B ED BC F2 AC 89 AA
: E6 9D 07 DC 17 A5 E9 F0 12 F0 19 D0 D3 45 8D
1026 49: INTEGER
: 00 84 70 C0 95 C6 D1 B8 78 6A 75 6E A6 3A 00 DD
: E6 45 84 18 6A A0 8B 12 2E BC 41 1C 7D 56 E7 34
: 21 32 10 4E 27 D2 64 3D F4 F1 D4 46 75 E8 1F 0A
: 85
: }
: }
: }
¶
The CA issues a key establishment certificate to Alice:¶
-----BEGIN CERTIFICATE----- MIICJTCCAaygAwIBAgIUf3Sj/ANs4hR4XFlhTm+N8kxHqHowCgYIKoZIzj0EAwMw NzELMAkGA1UEBhMCVVMxEzARBgNVBAoTCkV4YW1wbGUgQ0ExEzARBgNVBAMTCmNh LmV4YW1wbGUwHhcNMjUwMTA5MTcwNTAwWhcNMjYwMTA5MTcwNTAwWjA8MQswCQYD VQQGEwJVUzELMAkGA1UECBMCVkExEDAOBgNVBAcTB0hlcm5kb24xDjAMBgNVBAMT BUFsaWNlMHQwDgYFK4EEAQwGBSuBBAAiA2IABAFHJBMf5yrWzkX3i4WoV7uXUuoZ 0QLxOb57lVgEJ8oALwwnJJAyPUaLEQRcv7VaO2Dbde+cmi4IOjFKkMJIyp/eS+nn 6dozfu7FrdliAPoM9jeZ7kRm/Jk+9JElMWX8FqN2MHQwDAYDVR0TAQH/BAIwADAL BgNVHQ8EBAMCAwgwHQYDVR0OBBYEFAnLfJvnEUcvLXaPUDZMZlQ/zZ3WMB8GA1Ud IwQYMBaAFD6YvLLv3DQbvnGS0qP6bbzyZkCqMBcGA1UdIAQQMA4wDAYKYIZIAWUD AgEwMDAKBggqhkjOPQQDAwNnADBkAjARQ5LuV6yz8A5DZCll1S/gfxZ+QSJl/pKc cTL6Sdr1IS18U/zY8VUJeB2H0nBamLwCMBRQ6sEWpNoeeR8Bonpoot/zYD2luQ1V 2jevmYsnBihKF0debgfhGvh8WIgBR69DZg== -----END CERTIFICATE-----¶
Thanks to Sean Turner, Joe Mandel, Mike StJohns, Mike Ounsworth, Carl Wallace, and Corey Bonnell for their constructive comments.¶