Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 9883 Vigil Security
Category: Standards Track October 2025
ISSN: 2070-1721
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 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.
この文書は、証明書サブジェクトによる秘密キーの所有を宣言するための属性を指定します。X.509 証明書の登録の一環として、認証局 (CA) は通常、認証される公開キーに対応する秘密キーをサブジェクトが所有しているという証明を要求します。場合によっては、CA が証明書サブジェクトからの署名付きステートメントを受け入れる場合があります。たとえば、証明書サブジェクトが署名とキーの確立に別個の証明書を必要とする場合、同じサブジェクトに対して以前に発行された署名証明書で検証できるステートメントは、その後のキー確立証明書の発行には適切である可能性があります。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
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.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9883 で入手できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. ASN.1
1.2. Terminology
2. Overview
3. Attribute for Statement of Possession of a Private Key
4. Conventions for PKCS#10
5. Conventions for CRMF
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. ASN.1 Module
Appendix B. Example Use of the privateKeyPossessionStatement
Attribute
Acknowledgements
Author's Address
This document specifies an attribute for a statement of possession of a private key by a certificate subject. X.509 certificate [RFC5280] enrollment often depends on PKCS#10 [RFC2986] or the Certificate Request Message Format (CRMF) [RFC4211]. As part of enrollment, a Certification Authority (CA) typically demands proof that the subject possesses the private key that corresponds to the to-be-certified public key. Alternatively, a CA may accept a signed statement from the certificate subject claiming knowledge of that private key. 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.
この文書は、証明書サブジェクトによる秘密キーの所有を宣言するための属性を指定します。X.509 証明書 [RFC5280] の登録は、多くの場合、PKCS#10 [RFC2986] または証明書要求メッセージ形式 (CRMF) [RFC4211] に依存します。登録の一環として、認証局 (CA) は通常、認証対象の公開キーに対応する秘密キーをサブジェクトが所有しているという証明を要求します。あるいは、CA は、その秘密鍵の知識を主張する証明書主体からの署名付きステートメントを受け入れることもできます。証明書サブジェクトが署名と鍵の確立に別個の証明書を必要とする場合、同じサブジェクトに対して以前に発行された署名証明書で検証できる署名付きステートメントは、その後の鍵確立証明書の発行に適している可能性があります。
For example, a subject may need a signature certificate that contains an ML-DSA (Module-Lattice-Based Digital Signature Algorithm) public key and a key establishment certificate that contains an ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) public key. For another example, a subject may need a signature certificate that contains an ECDSA (Elliptic Curve Digital Signature Algorithm) public key and a key establishment certificate that contains an ECDH (Elliptic Curve Diffie-Hellman) public key.
たとえば、サブジェクトは、ML-DSA (モジュール格子ベースのデジタル署名アルゴリズム) 公開キーを含む署名証明書と、ML-KEM (モジュール格子ベースのキーカプセル化メカニズム) 公開キーを含むキー確立証明書を必要とする場合があります。別の例として、サブジェクトは、ECDSA (楕円曲線デジタル署名アルゴリズム) 公開鍵を含む署名証明書と、ECDH (楕円曲線ディフィーヘルマン) 公開鍵を含む鍵確立証明書を必要とする場合があります。
A statement of possession may be used in lieu of the usual proof-of-possession mechanisms. The statement is simply a signed assertion that the requestor of a key establishment certificate has possession of the key establishment private key and that statement is signed using a signature private key that was previously shown to be in the possession of the same certificate subject. If allowed by the Certificate Policy [RFC3647], the CA is permitted to accept this statement in lieu of proof that the requestor has possession of the private key, such as [RFC6955].
通常の所有証明メカニズムの代わりに所有声明が使用される場合があります。このステートメントは、キー確立証明書の要求者がキー確立秘密キーを所有しており、そのステートメントは、同じ証明書サブジェクトが所有していることが以前に示されている署名秘密キーを使用して署名されているという署名付きアサーションにすぎません。証明書ポリシー [RFC3647] で許可されている場合、CA は、[RFC6955] など、要求者が秘密鍵を所有していることを証明する代わりに、このステートメントを受け入れることが許可されます。
Note that [RFC6955] offers some algorithms that provide proof of possession for Diffie-Hellman private keys; however, these algorithms are not suitable for use with PKCS#10 [RFC2986]. In addition, the algorithms in [RFC6955] do not support key encapsulation mechanism algorithms, such as ML-KEM. The attribute specified in this document, on the other hand, is suitable for use with both PKCS#10 and the CRMF [RFC4211].
[RFC6955] は、Diffie-Hellman 秘密鍵の所有証明を提供するいくつかのアルゴリズムを提供していることに注意してください。ただし、これらのアルゴリズムは PKCS#10 [RFC2986] での使用には適していません。さらに、[RFC6955] のアルゴリズムは、ML-KEM などの鍵カプセル化メカニズムのアルゴリズムをサポートしていません。一方、この文書で指定された属性は、PKCS#10 と CRMF [RFC4211] の両方での使用に適しています。
The attribute defined in this document is generated using ASN.1 [X680], using the Distinguished Encoding Rules (DER) [X690].
この文書で定義される属性は、ASN.1 [X680]、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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
When using the attribute defined in this document to make a statement about the possession of the key establishment private key, the process to obtain two certificates with PKCS#10 is as follows:
この文書で定義されている属性を使用して鍵確立秘密鍵の所有についてステートメントを作成する場合、PKCS#10 で 2 つの証明書を取得するプロセスは次のとおりです。
1. The subject generates the signature key pair.
1. サブジェクトは署名鍵ペアを生成します。
2. 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.
2. サブジェクトは通常の方法で PKCS#10 証明書署名要求 (CSR) を作成します。これには、手順 1 の秘密キーを使用して生成された署名が含まれています。
3. 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 (see Section 4.2.1.3 of [RFC5280]).
3. サブジェクトは CSR を CA に送信し、CA は署名証明書を返します。署名証明書には、digitalSignature、nonRepudiation、またはその両方の鍵の使用法が含まれています（[RFC5280] のセクション 4.2.1.3 を参照）。
4. The subject generates the key establishment key pair.
4. サブジェクトは鍵確立鍵ペアを生成します。
5. The subject composes a PKCS#10 CSR containing the key establishment public key. The CSR attributes include the attribute specified in Section 3 of this document. The subject name matches the one from step 3. The CSR includes a signature that is produced with the private key from step 1.
5. サブジェクトは、鍵確立公開鍵を含む PKCS#10 CSR を作成します。CSR 属性には、この文書のセクション 3 で指定された属性が含まれます。サブジェクト名はステップ 3 の名前と一致します。CSR には、ステップ 1 の秘密キーを使用して生成された署名が含まれています。
6. 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 (see Section 4.2.1.3 of [RFC5280]).
6. サブジェクトは CSR を CA に送信し、CA はキー確立証明書を返します。鍵確立証明書には、keyEncipherment または keyAgreement の鍵使用法が含まれます ([RFC5280] のセクション 4.2.1.3 を参照)。
In general, the issuer of the key establishment certificate will be the same as the issuer of the signature certificate. If the issuers of the two certificates will be different, then the certificate policy of the issuer of the key establishment certificate MUST explain the procedure that is used to verify the subject and subject alternative names.
一般に、鍵確立証明書の発行者は署名証明書の発行者と同じになります。2 つの証明書の発行者が異なる場合、鍵確立証明書の発行者の証明書ポリシーで、サブジェクトとサブジェクトの代替名の検証に使用される手順を説明しなければなりません (MUST)。
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 states, without providing proof, that it 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 request for the key establishment certificate.
CA は、[RFC5280] のセクション 6 に規定されているように、署名証明書の証明書パス検証を実行しなければなりません (MUST)。認証パスが有効でない場合、CA は鍵確立証明書の要求を拒否しなければなりません (MUST)。
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.
CA は、署名証明書の公開鍵を使用して、証明書リクエストの署名を検証しなければなりません (MUST)。署名が有効でない場合、CA は証明書要求を拒否しなければなりません (MUST)。
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.
署名証明書のサブジェクトは、証明書リクエストのサブジェクト名と同じである必要があります (SHOULD)。それらが異なる場合、証明書ポリシーは、CA が 2 つのサブジェクト名が同じエンティティを識別していることをどのように判断できるかを記述しなければなりません (MUST)。CA が 2 つのサブジェクト名が同じエンティティを識別していると判断できない場合、CA は証明書要求を拒否しなければなりません (MUST)。
If subject alternative names are present in the certificate request, they SHOULD match subject alternative names in the signature certificate. If they are different, the certificate policy MUST describe how the CA can determine that the two subject alternative names identify the same entity. 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.
証明書リクエストにサブジェクト代替名が存在する場合、それらは署名証明書内のサブジェクト代替名と一致する必要があります(SHOULD)。それらが異なる場合、証明書ポリシーは、CA が 2 つのサブジェクト代替名が同じエンティティを識別していることをどのように判断できるかを記述しなければなりません (MUST)。CA が、各サブジェクト代替名が署名証明書で指定されているのと同じエンティティを識別していると判断できない場合、CA は証明書要求を拒否しなければなりません (MUST)。
When the CA rejects a certificate request for any of the reasons listed above, the CA should provide information to the requestor about the reason for the rejection to aid with diagnostic efforts. Likewise, the CA should log the rejection events.
CA が上記のいずれかの理由で証明書要求を拒否した場合、CA は診断作業を支援するために、拒否の理由に関する情報を要求者に提供する必要があります。同様に、CA は拒否イベントをログに記録する必要があります。
The attribute for statement of possession of a private key has the following structure:
秘密鍵の所有を宣言するための属性は次の構造になっています。
id-at-statementOfPossession OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 22112 2 1 }
privateKeyPossessionStatement ATTRIBUTE ::= {
TYPE PrivateKeyPossessionStatement
IDENTIFIED BY id-at-statementOfPossession }
PrivateKeyPossessionStatement ::= SEQUENCE {
signer IssuerAndSerialNumber,
cert Certificate OPTIONAL }
The components of the PrivateKeyStatement SEQUENCE have the following semantics:
PrivateKeyStatement SEQUENCE のコンポーネントには次のセマンティクスがあります。
signer:
署名者:
The issuer name and certificate serial number of the signature certificate.
署名証明書の発行者名と証明書のシリアル番号。
cert:
証明書:
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.
署名証明書。鍵確立証明書の発行者が署名証明書の発行者と同じである場合、このコンポーネントは省略してもよい(MAY)。署名証明書が省略された場合、署名者は、CA が発行したすべての有効な証明書を取得するメカニズムを備えていると想定します。
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.
このセクションでは、鍵確立証明書を要求する際に、PKCS#10 [RFC2986] で秘密鍵の所有を宣言するための属性を使用するための規則を指定します。
The PKCS#10 CertificationRequest always has three components, as follows:
PKCS#10 CertificationRequest には、次の 3 つのコンポーネントが常に含まれます。
certificationRequestInfo:
認証要求情報:
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 privateKeyPossessionStatement attribute as specified in Section 3 of this document.
サブジェクト名は署名証明書のサブジェクト名と同じである必要があり (SHOULD)、subjectPKInfo には鍵確立アルゴリズムの公開鍵が含まれなければならず、属性にはこの文書のセクション 3 で指定されている privateKeyPossessionStatement 属性が含まれなければなりません (MUST)。
signatureAlgorithm:
署名アルゴリズム:
The signature algorithm MUST be one that can be validated with the public key in the signature certificate.
署名アルゴリズムは、署名証明書内の公開キーを使用して検証できるものでなければなりません。
signature:
サイン：
The signature over certificationRequestInfo 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].
[RFC5280] のセクション 6 に規定されているように、certificationRequestInfo に対する署名は署名証明書内の公開鍵を使用して検証しなければならず (MUST)、署名証明書の証明書パスの検証は成功しなければなりません (MUST)。
This section specifies the conventions for using the attribute for statement of possession of a private key with the CRMF [RFC4211] when requesting a key establishment certificate.
このセクションでは、鍵確立証明書を要求する際に、CRMF [RFC4211] で秘密鍵の所有を宣言するための属性を使用するための規則を指定します。
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].
次の ASN.1 タイプは、CRMF で使用するために定義されています。これらは、上で説明した属性とまったく同じセマンティクスと構文を持ちますが、[RFC4211] の登録コントロールと同様の命名規則を提供します。
regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=
privateKeyPossessionStatement
id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=
id-at-statementOfPossession
The CRMF CertificationRequest always has three components, as follows:
CRMF CertificationRequest には、次の 3 つのコンポーネントが常に含まれます。
certReq:
証明書要求:
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.
certTemplate には、件名と publicKey コンポーネントが含まれなければなりません。同じサブジェクト名が署名証明書内のサブジェクト名と一致する必要があり (SHOULD)、publicKey には鍵確立アルゴリズムの公開鍵が含まれなければなりません (MUST)。
popo:
ポポ:
The ProofOfPossession MUST use the signature CHOICE, the poposkInput MUST be present, POPOSigningKeyInput.authInfo MUST use the sender CHOICE, the sender SHOULD be 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 signature algorithm that can be validated with the public key in the signature certificate, the 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].
ProofOfPossession は署名 CHOICE を使用しなければならず、poposkInput が存在しなければならず、POPOSigningKeyInput.authInfo は送信者 CHOICE を使用しなければならず、送信者は署名証明書に表示されるサブジェクト名に設定される必要があり、publicKey には certTemplate からの公開鍵のコピーが含まれなければならず、algorithmIdentifier は署名証明書内の公開鍵で検証できる署名アルゴリズムを識別しなければなりません。署名終了
PoposkInput は、署名証明書内の公開鍵を使用して検証しなければならず (MUST)、[RFC5280] のセクション 6 に規定されているように、署名証明書の証明書パスの検証が成功しなければなりません (MUST)。
regInfo:
登録情報:
The attributes MUST include the privateKeyPossessionStatement attribute as specified in Section 3 of this document.
このドキュメントのセクション 3 で指定されているように、属性には privateKeyPossessionStatement 属性を含める必要があります。
The privateKeyPossessionStatement attribute MUST NOT be used to obtain a signature certificate. Performing proof of possession of the signature private key is easily accomplished by signing the certificate request.
privateKeyPossessionStatement 属性を署名証明書の取得に使用してはなりません (MUST NOT)。署名秘密キーの所有証明は、証明書要求に署名することで簡単に実行できます。
The subject is signing the privateKeyPossessionStatement attribute to tell the CA that it has possession of the key establishment private key. This is being done instead of providing technical proof of possession. If the subject has lost control of the signature private key, then the signed privateKeyPossessionStatement attribute could be generated by some other party. Timely revocation of the compromised signature certificate is the only protection against such loss of control.
サブジェクトは、privateKeyPossessionStatement 属性に署名して、キー確立秘密キーを所有していることを CA に伝えます。これは、所有の技術的証拠を提供する代わりに行われます。サブジェクトが署名秘密キーの制御を失った場合、署名された privateKeyPossessionStatement 属性が他の当事者によって生成される可能性があります。侵害された署名証明書を適時に取り消すことが、このような制御の喪失を防ぐ唯一の方法です。
If the CA revokes a compromised signature certificate, then the CA SHOULD also revoke all key establishment certificates that were obtained with privateKeyPossessionStatement attributes signed by that compromised signature certificate.
CA が侵害された署名証明書を取り消す場合、CA は、その侵害された署名証明書によって署名された privateKeyPossessionStatement 属性を使用して取得されたすべての鍵確立証明書も取り消す必要があります (SHOULD)。
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 statement is not the weakest part of the certificate enrollment, the signature key pair SHOULD be at least as strong as the key establishment key pair.
署名キー ペアとキー確立キー ペアは、ほぼ同じセキュリティ強度を持つことが期待されます。ステートメントの署名が証明書登録の最も弱い部分にならないようにするには、署名キー ペアは少なくともキー確立キー ペアと同じくらい強力である必要があります (SHOULD)。
If a CA allows a 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.
CA が鍵確立証明書のサブジェクトが署名証明書のサブジェクト名と異なることを許可する場合、証明書ポリシーは、2 つのサブジェクト名が同じエンティティを識別することを判断する方法を記述しなければなりません (MUST)。同様に、CA が署名証明書に存在しないサブジェクト代替名を鍵確立証明書で許可する場合、証明書ポリシーは、サブジェクト代替名が署名証明書に指定されているものと同じエンティティを識別することを決定する方法を記述しなければなりません (MUST)。
For the ASN.1 Module in Appendix A of this document, IANA has assigned an object identifier (OID) for the module identifier (118) with a Description of "id-mod-private-key-possession-stmt-2025" in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).
この文書の付録 A の ASN.1 モジュールについて、IANA は、「SMI Security for PKIX Module Identifier」レジストリ (1.3.6.1.5.5.7.0) 内の「id-mod-private-key-possession-stmt-2025」の説明を持つモジュール識別子 (118) にオブジェクト識別子 (OID) を割り当てました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/info/rfc2986>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/info/rfc4211>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/info/rfc5912>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>.
[X690] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>.
[RFC6955] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
May 2013, <https://www.rfc-editor.org/info/rfc6955>.
This ASN.1 Module uses the conventions established by [RFC5912] and [RFC6268].
この ASN.1 モジュールは、[RFC5912] および [RFC6268] によって確立された規則を使用します。
PrivateKeyPossessionStatement-2025
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-private-key-possession-stmt-2025(118) }
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 Possession Statement Attribute
--
id-at-statementOfPossession OBJECT IDENTIFIER ::=
{ 1 3 6 1 4 1 22112 2 1 }
privateKeyPossessionStatement ATTRIBUTE ::= {
TYPE PrivateKeyPossessionStatement
IDENTIFIED BY id-at-statementOfPossession }
PrivateKeyPossessionStatement ::= SEQUENCE {
signer IssuerAndSerialNumber,
cert Certificate OPTIONAL }
--
-- Registration Control Support
--
RegControlSet ATTRIBUTE ::=
{ regCtrl-privateKeyPossessionStatement, ... }
regCtrl-privateKeyPossessionStatement ATTRIBUTE ::=
privateKeyPossessionStatement
id-regCtrl-statementOfPossession OBJECT IDENTIFIER ::=
id-at-statementOfPossession
END
In this example, the self-signed certificate for the CA is as follows:
この例では、CA の自己署名証明書は次のとおりです。
-----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 as follows:
アリスは ECDSA 署名鍵ペアを生成します。次に、アリスは [RFC2986] で指定されている通常の方法で PKCS#10 証明書署名要求 (CSR) を作成します。CSR には、彼女の ECDSA 秘密キーを使用して生成された署名が含まれています。CSRは以下の通りです。
-----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:
CA は、アリスに署名証明書を発行します。
-----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 privateKeyPossessionStatement 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 as follows:
アリスは、ECDH 鍵確立鍵ペアを生成します。次に、アリスは PKCS#10 CSR を作成します。CSR 属性には、ECDSA 署名証明書を指す privateKeyPossessionStatement 属性が含まれます。CSR には、彼女の ECDH 公開キーと、ECDSA 秘密キーを使用して生成された署名が含まれています。CSRは以下の通りです。
-----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 the following:
CSR は次のようにデコードされます。
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
: statementOfPossession (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:
CA は鍵確立証明書をアリスに発行します。
-----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, John Gray, Carl Wallace, Corey Bonnell, Hani Ezzadeen, Deb Cooley, Mohamed Boucadair, and Bron Gondwana for their constructive comments.
Sean Turner、Joe Mandel、Mike StJohns、Mike Ounsworth、John Gray、Carl Wallace、Corey Bonnell、Hani Ezzadeen、Deb Cooley、Mohamed Boucadair、Bron Gondwana の建設的なコメントに感謝します。
Russ Housley
Vigil Security, LLC
Herndon, VA
United States of America
Email: housley@vigilsec.com