Internet Engineering Task Force (IETF) A. Becker
Request for Comments: 9763 R. Guthrie
Category: Standards Track M. Jenkins
ISSN: 2070-1721 NSA
June 2025
This document defines a new Certificate Signing Request (CSR) attribute, relatedCertRequest, and a new X.509 certificate extension, RelatedCertificate. The use of the relatedCertRequest attribute in a CSR and the inclusion of the RelatedCertificate extension in the resulting certificate together provide additional assurance that two certificates each belong to the same end entity. This mechanism is particularly useful in the context of non-composite hybrid authentication, which enables users to employ the same certificates in hybrid authentication as in authentication done with only traditional or post-quantum algorithms.
このドキュメントでは、新しい証明書署名要求（CSR）属性、関連するCerterTrequest、および新しいX.509証明書拡張機能、関連項目を定義します。CSRでの関連する関連属性の使用と、結果の証明書に関連する認証拡張拡張機能を一緒に含めることは、それぞれ2つの証明書が同じ最終エンティティに属するという追加の保証を提供します。このメカニズムは、非コンポジットハイブリッド認証のコンテキストで特に役立ちます。これにより、ユーザーは、従来のアルゴリズムまたは測量後のアルゴリズムのみで行われた認証と同じハイブリッド認証で同じ証明書を使用できます。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9763.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9763で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Overview
2. Requirements Language
3. CSR and Related Certificates
3.1. The relatedCertRequest Attribute
3.2. CSR Processing
4. Related Certificate
4.1. The RelatedCertificate Extension
4.2. Endpoint Protocol Multiple Authentication Processing
5. Use Case
6. CA Organization Considerations
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. ASN.1 Module
Authors' Addresses
The goal of this document is to define a method for providing assurance that two X.509 (aka PKIX) end-entity certificates are owned by the same entity, in order to perform multiple authentications where each certificate corresponds to a distinct digital signature. This method aims to facilitate the use of two certificates for authentication in a secure protocol while minimizing changes to the certificate format [RFC5280] and to current PKI best practices.
このドキュメントの目標は、各証明書が異なるデジタル署名に対応する複数の認証を実行するために、2つのX.509（別名PKIX）エンドエンティティ証明書が同じエンティティによって所有されているという保証を提供する方法を定義することです。この方法は、証明書形式[RFC5280]および現在のPKIのベストプラクティスの変更を最小限に抑えながら、安全なプロトコルでの認証のために2つの証明書を使用することを促進することを目的としています。
When using non-composite hybrid public key mechanisms, the party relying on a certificate (an authentication verifier or a key-establishment initiator) will want assurance that the private keys associated with each certificate are under the control of the same entity. This document defines a certificate extension, RelatedCertificate, that signals that the certificate containing the extension is able to be used in combination with the other specified certificate.
非コンポジットハイブリッド公開キーメカニズムを使用する場合、証明書（認証検証者またはキー確立イニシエーター）に依存する当事者は、各証明書に関連付けられたプライベートキーが同じエンティティの管理下にあることを保証します。このドキュメントでは、拡張子を含む証明書を他の指定された証明書と組み合わせて使用できることを示す証明書拡張拡張機能を定義します。
A certification authority (CA) organization (defined here as the entity or organization that runs a CA and determines the policies and tools the CA will use) that is asked to issue a certificate with such an extension may want assurance from a registration authority (RA) that the private keys (corresponding to, for example, two public keys: one in an extant certificate and one in a current request) belong to the same entity. To facilitate this, a CSR attribute, called relatedCertRequest, is defined to permit an RA to make such an assertion.
認定機関（CA）組織（ここでは、ここではCAを実行し、CAが使用するポリシーとツールを決定するエンティティまたは組織として定義されます）。このような拡張機能で証明書を発行するよう求められます。たとえば、プライベートキー（たとえば、2つのパブリックキーに対応する登録機関（RA）から保証を必要とする場合があります。これを容易にするために、RALESCERTREQUESTと呼ばれるCSR属性は、RAがそのようなアサーションを行うことを許可するように定義されています。
The general roadmap of this design is best illustrated via an entity (e.g., a device, service, user token) that has an existing certificate (Cert A) and requests a new certificate (Cert B), perhaps as part of an organization's transition strategy to migrate their PKI from traditional cryptography to post-quantum cryptography (PQC).
このデザインの一般的なロードマップは、既存の証明書（CERT A）を持ち、おそらく従来の暗号化からPKIを移行する組織の移行戦略の一部として、既存の証明書（CERT A）（CERT B）を要求するエンティティ（例：デバイス、サービス、ユーザートークン）を介して最もよく示されています。
* For protocols where authentication is not negotiated but instead is limited by what the signer offers, such as in Cryptographic Message Syntax (CMS) and S/MIME, either Cert A's signing key, Cert B's signing key, or both signing keys may be invoked, according to which verifiers the signer anticipates.
* 認証が交渉されず、代わりに、暗号化メッセージの構文（CMS）やS/MIMEなど、署名者が提供するものによって制限されるプロトコルの場合、CERT Aの署名キー、CERT Bの署名キー、または両方の署名キーが呼び出される場合があります。
* For protocols where authentication is negotiated in-protocol, such as TLS and Internet Key Exchange Protocol Version 2 (IKEv2), either Cert A or Cert B's signing key may be invoked, according to the preference of the verifier. If the protocol is enabled to do so, peers may request that both Cert A and Cert B are used for authentication.
* Verifierの好みに応じて、TLSやInternet Key Exchange Protocolバージョン2（IKEV2）などの認証がプロトコル内で交渉されるプロトコルの場合、CERT AまたはCERT Bの署名キーのいずれかが呼び出される場合があります。プロトコルが可能になった場合、ピアは認証にCERT AとCERT Bの両方が使用されるように要求する場合があります。
A verifier that prefers multiple authentication types may be assisted by the inclusion of relevant information in one of the signer's certificates; that is, information that indicates the existence of a related certificate, and some assurance that those certificates have been issued to the same entity. This document describes a certificate request attribute and certificate extension that provide such assurance.
複数の認証タイプを好む検証者は、署名者の証明書のいずれかに関連情報を含めることにより支援される場合があります。つまり、関連する証明書の存在を示す情報、およびそれらの証明書が同じエンティティに発行されたというある程度の保証です。このドキュメントでは、そのような保証を提供する証明書要求属性と証明書延長について説明します。
To support this concept, this document defines a new CSR attribute, relatedCertRequest, which contains information on how to locate a previously issued certificate (Cert A) and provides evidence that the requesting entity owns that certificate. When the RA makes the request to the CA, the CA uses the given information to locate Cert A and then verifies ownership before generating the new certificate, Cert B.
この概念をサポートするために、このドキュメントでは、以前に発行された証明書（CERT A）を見つける方法に関する情報を含む新しいCSR属性、関連するCSR属性を定義し、要求エンティティがその証明書を所有しているという証拠を提供します。RAがCAにリクエストを行うと、CAは指定された情報を使用してCERT Aを見つけてから、新しい証明書Bを生成する前に所有権を検証します。
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] で説明されているように解釈されます。
This section defines a new CSR attribute designed to allow the RA to attest that the owner of the public key in the CSR also owns the public key associated with the end-entity certificate identified in this attribute. The relatedCertRequest attribute indicates the location of a previously issued certificate that the end entity owns and wants identified in the new certificate requested through the CSR.
このセクションでは、RAがCSRの公開鍵の所有者がこの属性で特定されたエンドエンティティ証明書に関連する公開鍵も所有していることを証明できるように設計された新しいCSR属性を定義します。関連する属性は、CSRを通じて要求された新しい証明書でEnd Entityが所有し、特定したい以前に発行された証明書の場所を示します。
The relatedCertRequest attribute has the following syntax:
関連する属性には、次の構文があります。
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }
aa-relatedCertRequest ATTRIBUTE ::= {
TYPE RequesterCertificate
IDENTIFIED BY id-aa-relatedCertRequest}
RequesterCertificate ::= SEQUENCE {
certID IssuerAndSerialNumber,
requestTime BinaryTime,
locationInfo UniformResourceIdentifier,
signature BIT STRING }
The RequesterCertificate type has four fields:
RequesterCertificateタイプには4つのフィールドがあります。
* The certID field uses the IssuerAndSerialNumber type [RFC5652] to identify a previously issued end-entity certificate that the requesting entity also owns. IssuerAndSerialNumber is repeated here for convenience:
* CERTIDフィールドは、発行者と登場者のタイプ[RFC5652]を使用して、要求エンティティも所有する以前に発行された最終エンティティ証明書を特定します。ISSUERANDSERIALNUMBERは、便利なためにここで繰り返されます。
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
CertificateSerialNumber ::= INTEGER
* The requestTime field uses the BinaryTime type [RFC6019] in order to ensure freshness, such that the signed data can only be used at the time of the initial CSR. The means by which the CA and RA synchronize time is outside the scope of this document. BinaryTime is repeated here for convenience:
* Request -Timeフィールドは、新鮮さを確保するためにBinaryTimeタイプ[RFC6019]を使用して、署名されたデータを最初のCSRの時点でのみ使用できるようにします。CAとRAが時間を同期させる手段は、このドキュメントの範囲外であります。バイナリタイムは、便利なためにここで繰り返されます：
BinaryTime ::= INTEGER (0..MAX)
* The locationInfo field uses UniformResourceIdentifier to provide information on the location of the other certificate the requesting entity owns. UniformResourceIdentifier is defined as:
* LocationInfoフィールドは、unigleResourceIdentifierを使用して、要求エンティティが所有する他の証明書の場所に関する情報を提供します。UniformResourceIdentifierは次のように定義されています。
UniformResourceIdentifier ::= IA5String
The UniformResourceIdentifier is a pointer to a location via HTTP(S) or a data URL. This field can contain one of two acceptable values:
UniformResourceIdentifierは、HTTPまたはデータURLを介した場所へのポインターです。このフィールドには、2つの許容値のいずれかを含めることができます。
- If the request for (new) Cert B is to the CA organization that also issued (existing) Cert A, then the UniformResourceIdentifier value SHOULD be a URL that points to a file containing a certificate or certificate chain that the requesting entity owns, as detailed in [RFC5280]; the URL is made available via HTTP or HTTPS. The file must permit access to a CMS 'certs-only' message containing the end-entity certificate or the entire certificate chain. This option uses less data than a data URL. All certificates contained must be DER encoded.
- （新しい）証明書Bの要求が（既存の）証明書Aを発行したCA組織に対するものである場合、UniformResourceIdentifier値は、[RFC5280]で詳述されているように、リクエストエンティティが所有する証明書または証明書チェーンを含むファイルを指すURLでなければなりません。URLは、HTTPまたはHTTPSを介して利用可能になります。ファイルは、エンドエンティティ証明書または証明書チェーン全体を含むCMSの「証明書のみ」メッセージへのアクセスを許可する必要があります。このオプションは、データURLよりも少ないデータを使用します。含まれるすべての証明書は、derエンコードする必要があります。
- If the request for (new) Cert B is to a CA organization different than the CA organization that issued the certificate (existing) Cert A referenced in the CSR, then the UniformResourceIdentifier value SHOULD be a data URL [RFC2397] containing inline degenerate PKCS#7 (see Sections 3.2.1 and 3.8 of [RFC8551]) consisting of all the certificates and CRLs required to validate Cert A. This allows the CA to perform validation (as described in Section 3.2) without having to retrieve certificates/CRLs from another CA. Further discussion of requirements for this scenario is in Section 5.
- If the request for (new) Cert B is to a CA organization different than the CA organization that issued the certificate (existing) Cert A referenced in the CSR, then the UniformResourceIdentifier value SHOULD be a data URL [RFC2397] containing inline degenerate PKCS#7 (see Sections 3.2.1 and 3.8 of [RFC8551]) consisting of all the certificates and CRLs required to validate Cert A. This allows the別のCAから証明書/CRLを取得することなく、検証を実行する（セクション3.2で説明されているように）実行します。このシナリオの要件のさらなる議論は、セクション5にあります。
* The signature field provides evidence that the requesting entity owns the certificate indicated by the certID field. Specifically, the signature field contains a digital signature over the concatenation of DER-encoded IssuerAndSerialNumber and BinaryTime. The concatenated value is signed using the signature algorithm and private key associated with the certificate identified by the certID field.
* 署名フィールドは、要求エンティティがCertIDフィールドで示される証明書を所有しているという証拠を提供します。具体的には、署名フィールドには、derがエンコードされた発行者とバイナリタイムの連結に関するデジタル署名が含まれています。連結された値は、CertIDフィールドによって識別された証明書に関連付けられた署名アルゴリズムと秘密鍵を使用して署名されます。
- If the related certificate is a key establishment certificate (e.g., using RSA key transport or Elliptic Curve Cryptography (ECC) key agreement), the private key is used to sign one time for proof of possession (POP) (as detailed in Section 8.1.5.1.1.2 of [NIST-SP-800-57]).
- 関連する証明書がキー設立証明書（例：RSAキートランスポートまたは楕円曲線暗号化（ECC）キー契約を使用する）である場合、秘密鍵は、[NIST-SP-800-57]のセクション8.1.5.1.2で詳述されているように）所有証明（POP）の証明（POP）のために1回署名するために使用されます。
The verification of this signature by the CA ensures that the owner of the CSR also owns the certificate indicated in the relatedCertRequest attribute.
CAによるこの署名の検証により、CSRの所有者が関連する証明書を関連する証明書を所有していることが保証されます。
The information provided in the relatedCertRequest attribute allows the CA to locate a previously issued certificate that the requesting entity owns, and confirm ownership by using the public key in that certificate to verify the signature in the relatedCertRequest attribute.
関連する関連属性属性で提供される情報により、CAは要求エンティティが所有する以前に発行された証明書を見つけることができ、その証明書の公開キーを使用して、関連するCercertrEquest属性の署名を確認することで所有権を確認できます。
If a CA receives a CSR that includes the relatedCertRequest attribute and that CA supports the attribute, the CA:
CAが関連する関連属性を含むCSRを受信し、そのCAが属性をサポートする場合、CA：
* MUST retrieve the certificate identified in the relatedCertRequest attribute using the information provided in UniformResourceIdentifier, and validate it using certificate path validation rules defined in [RFC5280]. The CA then extracts the IssuerAndSerialNumber from the indicated certificate and compares this value against the IssuerAndSerialNumber provided in the certID field of relatedCertRequest.
* [RFC5280]で定義されている証明書パス検証ルールを使用して、UniformResourceIdentifierで提供された情報を使用して、関連する関連属性で識別された証明書を取得する必要があります。CAは、指定された証明書から発行者と保護者を抽出し、この値を関連するCertidフィールドで提供された発行者と登録担当者と比較します。
* MUST check that the BinaryTime indicated in the requestTime field is sufficiently fresh. Note that sufficient freshness is defined by local policy and is out of the scope of this document.
* リクエストタイムフィールドに示されているバイナリ時間が十分に新鮮であることを確認する必要があります。十分な新鮮さはローカルポリシーによって定義されており、このドキュメントの範囲外であることに注意してください。
* MUST verify the signature field of the relatedCertRequest attribute. The CA verifies the signature using the public key associated with the certificate identified by the relatedCertRequest attribute. The details of the verification process are outside the scope of this document.
* 関連する属性の署名フィールドを確認する必要があります。CAは、関連するCertifictest equest属性によって識別された証明書に関連付けられた公開キーを使用して署名を検証します。検証プロセスの詳細は、このドキュメントの範囲外です。
* SHOULD issue the new certificate containing the RelatedCertificate extension as specified in Section 4, which references the certificate indicated in the attribute's IssuerAndSerialNumber field. The CA may also apply local policy regarding the suitability of the related certificate, such as validity period remaining.
* セクション4で指定されている関連認証拡張機能を含む新しい証明書を発行する必要があります。セクション4では、属性の発行担当者フィールドに示されている証明書を参照しています。CAは、残りの有効期間など、関連する証明書の適合性に関するローカルポリシーを適用する場合があります。
The RA MUST only allow a previously issued certificate to be indicated in the relatedCertRequest attribute in order to enable the CA to perform the required signature verification.
RAは、CAが必要な署名検証を実行できるようにするために、以前に発行された証明書を関連する属性に示すことのみを許可する必要があります。
The RA MAY send the CA a CSR containing a relatedCertRequest attribute that includes the IssuerAndSerialNumber of a certificate that was issued by a different CA.
RAは、別のCAによって発行された証明書の発行者と保護者を含む関連する関連属性を含むCA A CSRを送信する場合があります。
This section specifies a new X.509 certificate extension, RelatedCertificate. RelatedCertificate creates an association between the certificate containing the RelatedCertificate extension (Cert B) and the certificate referenced within the extension (Cert A). When two end-entity certificates are used in a protocol, where one of the certificates contains a RelatedCertificate extension that references the other certificate, the authenticating entity is provided with additional assurance that both certificates belong to the same entity.
このセクションでは、新しいX.509証明書拡張機能、関連項目を指定します。関連項目は、関連する拡張機能（CERT B）を含む証明書と延長内で参照される証明書（CERT A）との間に関連性を作成します。2つのエンドエンティティ証明書がプロトコルで使用されている場合、証明書の1つに他の証明書を参照する関連認証拡張機能が含まれている場合、認証エンティティには両方の証明書が同じエンティティに属するという追加の保証が提供されます。
The RelatedCertificate extension contains the hash of a single end-entity certificate.
関連する拡張機能には、単一のエンドエンティティ証明書のハッシュが含まれています。
The RelatedCertificate extension has the following syntax:
関連するcertificate拡張子には次の構文があります。
-- Object Identifier for certificate extension
id-relatedCert OBJECT IDENTIFIER ::= { 36 }
-- X.509 Certificate extension
RelatedCertificate ::= SEQUENCE {
hashAlgorithm DigestAlgorithmIdentifier,
hashValue OCTET STRING }
The extension is a SEQUENCE of two fields. The hashAlgorithm field identifies the hash algorithm used to compute hashValue, which is the digest value obtained from hashing the entire related certificate identified in the relatedCertRequest CSR attribute defined above. If there is a hash algorithm explicitly indicated by the related certificate's signature OID (e.g., ecdsa-with-SHA512), that hash algorithm SHOULD also be used for this extension.
拡張機能は、2つのフィールドのシーケンスです。Hashalgorithmフィールドは、上記の関連するCSR属性で特定された関連する証明書全体をハッシュすることから得られたダイジェスト値であるハッシュバルーを計算するために使用されるハッシュアルゴリズムを識別します。関連証明書の署名OID（例：ECDSA-with-Sha512）で明示的に示されているハッシュアルゴリズムがある場合、この拡張機能にはハッシュアルゴリズムも使用する必要があります。
This extension SHOULD NOT be marked critical. Marking this extension critical would severely impact interoperability.
この拡張機能は重要ではありません。この拡張機能が重要になると、相互運用性に深刻な影響を与えます。
For certificate chains, this extension MUST only be included in the end-entity certificate.
証明書チェーンの場合、この拡張機能はエンドエンティティ証明書にのみ含める必要があります。
For the RelatedCertificate extension to be meaningful, a CA that issues a certificate with this extension:
関連することを意味するために、この拡張子で証明書を発行するCAは次のとおりです。
* MUST only include a certificate in the extension that is listed in the relatedCertRequest attribute of the CSR submitted by the requesting entity.
* 要求エンティティが提出したCSRの関連する関連属性にリストされている拡張子に証明書のみを含める必要があります。
* MUST ensure that the related certificate contains the key usage (KU) bits and extended key usage (EKU) OIDs [RFC5280] being asserted in the certificate being issued.
* 関連する証明書に、発行されている証明書に主張されている主要な使用法（KU）ビットと拡張キー使用量（EKU）OID [RFC5280]が含まれていることを確認する必要があります。
* SHOULD determine that the related certificate is valid at the time of issuance. The usable overlap with the validity period of the newly issued certificate is a Subscriber concern.
* 関連証明書が発行時に有効であると判断する必要があります。新しく発行された証明書の有効期間との使用可能な重複は、加入者の懸念です。
When the preference to use a non-composite hybrid authentication mode is expressed by an endpoint through the protocol itself (e.g., during negotiation), the use of the RelatedCertificate extension and its enforcement are left to the protocol's existing authorization mechanism (along with other decisions endpoints make about whether to complete or drop a connection).
非複数のハイブリッド認証モードを使用することを好む場合、プロトコル自体（たとえば、交渉中）を介してエンドポイントによって表される場合、関連する拡張機能の使用とその施行は、プロトコルの既存の承認メカニズムに任されます（他の決定のエンドポイントは、接続を完了するかドロップするかについて）。
If an endpoint has indicated that it supports non-composite hybrid authentication and receives the appropriate authentication data, it should check end-entity certificates (Cert A and Cert B) for the RelatedCertificate extension. If present in one certificate (e.g., Cert B), it should:
エンドポイントが、非コンポジットハイブリッド認証をサポートし、適切な認証データを受信することを示した場合、関連認証拡張機能のエンドエンティティ証明書（CERT AおよびCERT B）を確認する必要があります。1つの証明書（例：証明書）に存在する場合、それは次のようにする必要があります。
* Compute the appropriate hash of Cert A, the other end-entity certificate received.
* CERT Aの適切なハッシュを計算します。
* Confirm that the hash value matches the hash entry in the RelatedCertificate extension of Cert B.
* ハッシュ値が、CERT Bの関連する拡張拡張のハッシュエントリと一致することを確認します
How to proceed with authentication based on the outcome of this process is outside the scope of this document. Different determinations may be made depending on each peer's policy regarding whether both or at least one authentication needs to succeed.
このプロセスの結果に基づいて認証を続行する方法は、このドキュメントの範囲外です。各または少なくとも1つの認証が成功する必要があるかどうかに関する各ピアのポリシーに応じて、異なる決定を行うことができます。
The general design of this method is best illustrated through specific use within a migration strategy to PQC via a non-composite hybrid authentication mechanism. The intent is for a CA issuing a new, post-quantum (PQ) certificate to add an X.509 extension that provides information about a previously issued, traditional certificate in which the private key is controlled by the same end entity as the PQ certificate.
この方法の一般的な設計は、非コンポジットハイブリッド認証メカニズムを介してPQCへの移行戦略内での特定の使用を通じて最もよく示されています。意図は、CAが新しい、Quantum（PQ）証明書を発行して、PQ証明書と同じENDエンティティによって秘密キーが制御される以前に発行された従来の証明書に関する情報を提供するX.509拡張機能を追加することです。
In the following scenario, an entity currently has a traditional certificate and requests that a new, PQ certificate be issued containing a RelatedCertificate extension, which references the entity's traditional certificate.
以下のシナリオでは、エンティティには現在、従来の証明書があり、エンティティの従来の証明書を参照する関連する認証拡張機能を含む新しいPQ証明書を発行するよう要求しています。
The RA receives a CSR for a PQ certificate, where the CSR includes the relatedCertRequest attribute detailed in this document. The relatedCertRequest attribute includes a certID field that identifies the entity's previously issued traditional certificate and a signature field in which the requesting entity produces a digital signature over the concatenation of the IssuerAndSerialNumber and BinaryTime, using the private key of the certificate identified by the IssuerAndSerialNumber.
RAは、PQ証明書のCSRを受信します。CSRには、このドキュメントに詳述されている関連する関連属性が含まれています。関連するセクタートレート属性には、以前に発行された従来の証明書を識別するCertIDフィールドと、発行担当者によって特定された証明書の秘密鍵を使用して、発行者とバイナリタイムの連結とバイナリタイムの連結に関するデジタル署名を要求する署名フィールドが含まれています。
The purpose of the relatedCertRequest attribute is to serve as a tool for the RA to provide assurance to the CA organization that the entity that controls the private key of the PQ certificate being requested also controls the private key of the referenced, previously issued traditional certificate.
関連する関連属性の目的は、要求されているPQ証明書の秘密鍵を制御するエンティティが、以前に発行された参照された従来の証明書の秘密鍵を制御することをCA組織に保証するためのツールとして機能することです。
Upon receipt and validation of the CSR, the CA issues a PQ certificate to the requesting entity that includes the RelatedCertificate extension detailed in this document; the extension includes a hash of the entire traditional certificate identified in the CSR. The X.509 extension creates an association between the PQ certificate and the traditional certificate via an assertion of end-entity ownership.
CSRの受領と検証時に、CAは、このドキュメントで詳述されている関連する拡張機能を含むリクエストエンティティにPQ証明書を発行します。拡張機能には、CSRで特定された従来の証明書全体のハッシュが含まれています。X.509拡張機能は、End-Entityの所有権のアサーションを介して、PQ証明書と従来の証明書との間に関連性を作成します。
The attribute and subsequent extension together provide assurance from the CA organization that the same end entity controls the private keys of both certificates. It is neither a requirement nor a mandate that either certificate be used with the other; it is simply an assurance that they can be used together, as they are under the control of the same entity.
属性とその後の拡張機能は、同じ最終エンティティが両方の証明書のプライベートキーを制御することをCA組織から保証します。どちらかの証明書を他の証明書とともに使用することは要件でも委任でもありません。同じエンティティの管理下にあるため、それらを一緒に使用できることは単に保証です。
The relatedCertRequest CSR attribute asserts end-entity control of the private key associated with a related certificate (Cert A) to the CA organization issuing a new certificate (Cert B). A public-facing CA organization may not be configured to validate certificates that have been issued by different CA organizations. In this case, recognition of the contents in the relatedCertRequest attribute may necessitate pre-arrangement, e.g., a contract with pre-configured trust anchors from another CA organization and agreements regarding policies concerning certificate application, issuance, and acceptance.
関連するCASR属性は、新しい証明書を発行するCA組織（CERT B）に関連する証明書（CERT A）に関連付けられている秘密鍵のエンドエンティティ制御を主張します。公開CA組織は、さまざまなCA組織によって発行された証明書を検証するように構成されていない場合があります。この場合、関連する関連属性の内容の認識は、例えば、別のCA組織からの事前に構成された信託アンカーとの契約と、証明書申請、発行、および受け入れに関するポリシーに関する契約との契約を必要とする場合があります。
Continuing with this scenario, in order for the CA organization to ensure that Cert B is issued under security parameters comparable to Cert A, the issuing CA organization should match the issued certification policies to the related ones. The issuing CA organization, as part of its validation of Cert A, ascertains what policies are asserted in Cert A's certification path and determines which of their own certification policies will best ensure that the protection of the private key associated with Cert B is comparable to that of Cert A. The relatedCertRequest attribute and subsequent RelatedCertificate certificate extension are solely intended to provide assurance that both private keys are controlled by the same end entity.
このシナリオを継続して、CA組織がCERT BがCERT Aに匹敵するセキュリティパラメーターの下で発行されることを保証するために、発行されるCA組織は、発行された認定ポリシーと関連するポリシーと一致する必要があります。CERT Aの検証の一環として発行されるCA組織は、CERT Aの認定パスで主張されているポリシーを確認し、CERT Bに関連する秘密鍵の保護がCERT Aに匹敵することを保証する独自の認定ポリシーが最もよくなることを決定します。
This document inherits security considerations identified in [RFC5280].
このドキュメントは、[RFC5280]で特定されたセキュリティ上の考慮事項を継承します。
The mechanisms described in this document provide only a means to express that multiple certificates are related. They are intended for the interpretation of the recipient of the data in which they are embedded (i.e., a CSR or certificate). They do not by themselves effect any security function.
このドキュメントで説明されているメカニズムは、複数の証明書が関連していることを表現する手段のみを提供します。それらは、埋め込まれているデータ（つまり、CSRまたは証明書）の受信者の解釈を目的としています。セキュリティ機能はそれ自体には影響しません。
Authentication, unlike key establishment, is necessarily a one-way arrangement. That is, authentication is an assertion made by a claimant to a verifier. The means and strength of the authentication mechanism have to be satisfactory to the verifier. A system security designer needs to be aware of what authentication assurances are needed in various parts of the system and how to achieve that assurance. In a closed system (e.g., Company X distributing firmware to its own devices), the approach may be implicit. In an online protocol like IPsec where the peers are generally known, any mechanism selected from a pre-established set may be sufficient. For more promiscuous online protocols like TLS, the ability for the verifier to express what is possible and what is preferred -- and to assess that its requirements were met -- is important.
認証は、重要な施設とは異なり、必然的に一方向の配置です。つまり、認証は、検証者の請求者によって行われたアサーションです。認証メカニズムの平均と強度は、検証者にとって満足のいくものでなければなりません。システムセキュリティデザイナーは、システムのさまざまな部分で認証保証が必要であることと、その保証を達成する方法を認識する必要があります。閉じたシステム（たとえば、ファームウェアを独自のデバイスに配布する会社X）では、アプローチは暗黙的である可能性があります。ピアが一般的に知られているIPSECのようなオンラインプロトコルでは、事前に確立されたセットから選択されたメカニズムで十分かもしれません。TLSのようなより乱雑なオンラインプロトコルのために、検証者が可能なことと好みのものを表現する能力、およびその要件が満たされたことを評価することが重要です。
A certificate is an assertion of binding between an identity and a public key. However, that assertion is based on several other assurances, especially that the identity belongs to a particular physical entity and that the physical entity has control over the private key corresponding to the public key. For any hybrid approach, it is important that there be evidence that the same entity controls all private keys at time of use (to the verifier) and at time of registration (to the CA).
証明書は、身元と公開鍵の間の拘束力のある主張です。ただし、そのアサーションは、特にアイデンティティが特定の物理的実体に属し、物理エンティティが公開鍵に対応する秘密鍵を制御していること、特に他のいくつかの保証に基づいています。ハイブリッドアプローチについては、同じエンティティが使用時（検証者）および登録時（CA）のすべてのプライベートキーを制御するという証拠があることが重要です。
All hybrid implementations are vulnerable to a downgrade attack in which a malicious peer does not express support for the stronger algorithm, resulting in an exchange that can only rely upon a weaker algorithm for security.
すべてのハイブリッド実装は、悪意のあるピアがより強力なアルゴリズムのサポートを表明しないダウングレード攻撃に対して脆弱であり、セキュリティのために弱いアルゴリズムにのみ依存できる交換をもたらします。
Implementors should be aware of risks that arise from the retrieval of a related certificate via the UniformResourceIdentifier provided in the relatedCertRequest CSR attribute, as a URL can point to malicious code. Implementors should ensure the data is properly formed and validate the retrieved data fully.
実装者は、URLが悪意のあるコードを指すことができるため、関連するCORESTESTEST CSR属性で提供されるUniformResourceIdentifierを介して関連する証明書の取得から生じるリスクを認識する必要があります。実装者は、データが適切に形成されていることを確認し、取得したデータを完全に検証する必要があります。
CAs should be aware that retrieval of existing certificates may be subject to observation; if this is a concern, it is advisable to use the data URL option described in Section 3.1.
CASは、既存の証明書の検索が観察の対象となる可能性があることに注意する必要があります。これが懸念事項である場合、セクション3.1で説明したデータURLオプションを使用することをお勧めします。
This document defines an extension for use with X.509 certificates. IANA has registered the following OID in the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1):
このドキュメントでは、X.509証明書で使用するための拡張機能を定義します。IANAは、「PKIX証明書拡張のSMIセキュリティ」レジストリ（1.3.6.1.1.5.5.7.1）に次のOIDを登録しました。
+=========+===================+============+
| Decimal | Description | References |
+=========+===================+============+
| 36 | id-pe-relatedCert | RFC 9763 |
+---------+-------------------+------------+
Table 1
The registration procedure is Specification Required [RFC8126].
登録手順は、必要な仕様です[RFC8126]。
This document defines a CSR attribute. IANA has registered the following OID in the "SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2)" registry:
このドキュメントは、CSR属性を定義します。IANAは、次のOIDを「S/MIME属性のSMIセキュリティ（1.2.840.113549.1.9.16.2）」に登録しました。
+=========+==========================+============+
| Decimal | Description | References |
+=========+==========================+============+
| 60 | id-aa-relatedCertRequest | RFC 9763 |
+---------+--------------------------+------------+
Table 2
This document defines an ASN.1 module in Appendix A. IANA has registered the following OID for the module identifier in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0):
このドキュメントでは、付録AのASN.1モジュールを定義しています。IANAは、「PKIXモジュール識別子のSMIセキュリティ」レジストリ（1.3.6.1.1.5.5.7.0）のモジュール識別子に次のOIDを登録しています。
+=========+==========================+============+
| Decimal | Description | References |
+=========+==========================+============+
| 115 | id-mod-related-cert-2023 | RFC 9763 |
+---------+--------------------------+------------+
Table 3
[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>.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
DOI 10.17487/RFC2397, August 1998,
<https://www.rfc-editor.org/info/rfc2397>.
[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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 6019,
DOI 10.17487/RFC6019, September 2010,
<https://www.rfc-editor.org/info/rfc6019>.
[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>.
[NIST-SP-800-57]
Barker, E., "Recommendation for Key Management: Part 1 -
General", National Institute of Standards and Technology,
NIST SP 800-57pt1r5, DOI 10.6028/NIST.SP.800-57pt1r5, May
2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-57pt1r5.pdf>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", RFC 8551, DOI 10.17487/RFC8551,
April 2019, <https://www.rfc-editor.org/info/rfc8551>.
The following RelatedCertificate ASN.1 module describes the RequesterCertificate type found in the relatedCertAttribute. It pulls definitions from modules defined in [RFC5912] and [RFC6268] for the IssuerAndSerialNumber type and in [RFC6019] for the BinaryTime type.
以下の関連項asn.1モジュールは、関連するcertattributeで見つかったrequestercertificateタイプを説明します。発行型型の[RFC5912]および[RFC6268]および[RFC6019]で[RFC6268]とバイナリタイムタイプの[RFC6268]から定義されたモジュールから定義を引き出します。
RelatedCertificate { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-related-cert-2023(115)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
ATTRIBUTE, EXTENSION
FROM PKIX-CommonTypes-2009 -- in RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
IssuerAndSerialNumber, DigestAlgorithmIdentifier
FROM CryptographicMessageSyntax-2010 -- in RFC 6268
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2009(58) }
BinaryTime
FROM BinarySigningTimeModule -- in RFC 6019
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-binarySigningTime(27) } ;
-- Object identifier arcs
id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 }
id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2 }
-- relatedCertificate Extension
id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 36 }
RelatedCertificate ::= SEQUENCE {
hashAlgorithm DigestAlgorithmIdentifier,
hashValue OCTET STRING }
ext-relatedCertificate EXTENSION ::= {
SYNTAX RelatedCertificate
IDENTIFIED BY id-pe-relatedCert }
-- relatedCertRequest Attribute
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 }
RequesterCertificate ::= SEQUENCE {
certID IssuerAndSerialNumber,
requestTime BinaryTime,
locationInfo UniformResourceIdentifiers,
signature BIT STRING }
UniformResourceIdentifiers ::= SEQUENCE SIZE (1..MAX) OF URI
URI ::= IA5String
aa-relatedCertRequest ATTRIBUTE ::= {
TYPE RequesterCertificate
IDENTIFIED BY id-aa-relatedCertRequest }
END
Alison Becker
National Security Agency
Email: aebecke@uwe.nsa.gov
Rebecca Guthrie
National Security Agency
Email: rmguthr@uwe.nsa.gov
Michael Jenkins
National Security Agency
Email: mjjenki@cyber.nsa.gov