[要約] この文書は、証明書の利用者が署名を検証する必要がない状況で使用できる、プレースホルダー X.509 署名アルゴリズムを定義しています。これにより、トラストアンカー（ルートCA）などの、発行者の署名を必要としないスタンドアロンのサブジェクト情報の記述が可能になります。本仕様の導入に伴い、RFC 5280 が更新されます。
Internet Engineering Task Force (IETF) D. Benjamin
Request for Comments: 9925 Google LLC
Updates: 5280 February 2026
Category: Standards Track
ISSN: 2070-1721
This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate is not expected to verify the signature. As part of this, it updates RFC 5280.
この文書は、証明書の利用者が署名を検証することが期待されていないコンテキストで使用できるプレースホルダー X.509 署名アルゴリズムを定義します。この一環として、RFC 5280 が更新されます。
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/rfc9925.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9925 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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
2. Requirements Language
3. Constructing Unsigned Certificates
3.1. Signature
3.2. Issuer
3.3. Extensions
4. Consuming Unsigned Certificates
5. Security Considerations
6. IANA Considerations
6.1. Module Identifier
6.2. Algorithm
6.3. Relative Distinguished Name Attribute
7. References
7.1. Normative References
7.2. Informative References
Appendix A. ASN.1 Module
Acknowledgements
Author's Address
An X.509 certificate [RFC5280] relates two entities in the PKI: information about a subject and a proof from an issuer. Viewing the PKI as a graph with entities as nodes, as in [RFC4158], a certificate is an edge between the subject and issuer.
X.509 証明書 [RFC5280] は、PKI 内の 2 つのエンティティ、つまりサブジェクトに関する情報と発行者からの証明を関連付けます。[RFC4158] のように、PKI をエンティティをノードとして持つグラフとして見ると、証明書はサブジェクトと発行者の間のエッジになります。
In some contexts, an application needs standalone subject information instead of a certificate. In the graph model, the application needs a node, not an edge. For example, certification path validation (Section 6 of [RFC5280]) begins at a trust anchor, sometimes referred to as a root certification authority (root CA). The application trusts this trust anchor information out-of-band and does not require an issuer's signature.
状況によっては、アプリケーションには証明書の代わりにスタンドアロンのサブジェクト情報が必要です。グラフ モデルでは、アプリケーションにはエッジではなくノードが必要です。たとえば、認証パスの検証 ([RFC5280] のセクション 6) は、ルート認証局 (ルート CA) とも呼ばれるトラスト アンカーから始まります。アプリケーションはこのトラスト アンカー情報を帯域外で信頼し、発行者の署名を必要としません。
X.509 does not define a structure for this scenario. Instead, X.509 trust anchors are often represented with "self-signed" certificates, where the subject's key signs over itself. Other formats, such as [RFC5914], exist to convey trust anchors, but self-signed certificates remain widely used.
X.509 では、このシナリオの構造は定義されていません。代わりに、X.509 トラスト アンカーは、サブジェクトのキーがそれ自体に署名する「自己署名」証明書で表されることがよくあります。トラストアンカーを伝達するために [RFC5914] などの他の形式も存在しますが、自己署名証明書は依然として広く使用されています。
Additionally, some TLS [RFC8446] server deployments use self-signed end entity certificates when they do not intend to present a CA-issued identity, instead expecting the relying party to authenticate the certificate out-of-band, e.g., via a known fingerprint.
さらに、一部の TLS [RFC8446] サーバー展開では、CA 発行の ID を提示するつもりがない場合に、自己署名エンド エンティティ証明書を使用し、代わりに、証明書利用者がアウトオブバンド (既知のフィンガープリントなど) で証明書を認証することを期待しています。
These self-signatures typically have no security value, aren't checked by the receiver, and only serve as placeholders to meet syntactic requirements of an X.509 certificate.
これらの自己署名には通常、セキュリティ上の価値はなく、受信側によってチェックされず、X.509 証明書の構文要件を満たすためのプレースホルダーとしてのみ機能します。
Computing signatures as placeholders has some drawbacks:
署名をプレースホルダーとして計算することにはいくつかの欠点があります。
* Post-quantum signature algorithms are large, so including a self-signature significantly increases the size of the payload.
* ポスト量子署名アルゴリズムは大きいため、自己署名を含めるとペイロードのサイズが大幅に増加します。
* If the subject is an end entity, rather than a CA, computing an X.509 signature risks cross-protocol attacks with the intended use of the key.
* サブジェクトが CA ではなくエンド エンティティである場合、X.509 署名を計算すると、キーの使用目的によるクロスプロトコル攻撃の危険があります。
* It is ambiguous whether such a self-signature requires the CA bit in basic constraints or keyCertSign in key usage. If the key is intended for a non-X.509 use, asserting those capabilities is an unnecessary risk.
* このような自己署名が基本的な制約で CA ビットを必要とするのか、鍵の使用法で keyCertSign を必要とするのかは曖昧です。キーが X.509 以外での使用を目的としている場合、それらの機能をアサートすることは不必要なリスクとなります。
* If the subject is an end entity, and the end entity's key is not a signing key (e.g., a Key Encapsulation Mechanism (KEM) key), there is no valid signature algorithm to use with the key.
* サブジェクトがエンド エンティティであり、エンド エンティティのキーが署名キー (キー カプセル化メカニズム (KEM) キーなど) ではない場合、そのキーで使用できる有効な署名アルゴリズムはありません。
This document defines a profile for unsigned X.509 certificates, which may be used when the certificate is used as a container for subject information, without any specific issuer.
この文書は、特定の発行者なしで、証明書がサブジェクト情報のコンテナとして使用される場合に使用できる、未署名の X.509 証明書のプロファイルを定義します。
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 describes how a sender constructs an unsigned certificate.
このセクションでは、送信者が署名されていない証明書を作成する方法について説明します。
To construct an unsigned X.509 certificate, the sender MUST set the Certificate's signatureAlgorithm and TBSCertificate's signature fields each to an AlgorithmIdentifier with algorithm id-alg-unsigned, defined below:
署名されていない X.509 証明書を構築するには、送信者は、証明書の SignatureAlgorithm フィールドと TBSCertificate の署名フィールドをそれぞれ、以下に定義されているアルゴリズム id-alg-unsigned を持つ AlgorithmIdentifier に設定しなければなりません。
id-alg-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 6 36}
The parameters for id-alg-unsigned MUST be omitted. The Certificate's signatureValue field MUST be a BIT STRING of length zero.
id-alg-unsigned のパラメータは省略しなければなりません。証明書のsignatureValueフィールドは長さ0のビット文字列でなければなりません。
An unsigned certificate takes the place of a self-signed certificate in scenarios where the application only requires subject information. It has no issuer, so some requirements in the profile defined in [RFC5280] cannot meaningfully be applied. However, the application may have pre-existing requirements derived from [X.509] and [RFC5280], so senders MAY construct the certificate as if it were a self-signed certificate, if needed for interoperability.
アプリケーションがサブジェクト情報のみを必要とするシナリオでは、未署名の証明書が自己署名証明書の代わりになります。発行者が存在しないため、[RFC5280] で定義されているプロファイルの一部の要件を意味のある形で適用することはできません。ただし、アプリケーションには [X.509] および [RFC5280] に由来する既存の要件がある可能性があるため、相互運用性のために必要な場合、送信者は自己署名証明書であるかのように証明書を構築してもよい(MAY)。
In particular, the following fields describe a certificate's issuer:
特に、次のフィールドでは証明書の発行者が説明されます。
* issuer (Section 4.1.2.4 of [RFC5280])
* 発行者 ([RFC5280] のセクション 4.1.2.4)
* issuerUniqueID (Section 4.1.2.8 of [RFC5280])
* issuerUniqueID ([RFC5280] のセクション 4.1.2.8)
The issuer field is not optional, and both [X.509] and Section 4.1.2.4 of [RFC5280] forbid empty issuers, so such a value may not be interoperable with existing applications.
発行者フィールドはオプションではなく、[X.509] と [RFC5280] のセクション 4.1.2.4 の両方で空の発行者を禁止しているため、そのような値は既存のアプリケーションと相互運用できない可能性があります。
If the subject is not empty, senders MAY set the issuer to the subject, similar to how they would construct a self-signed certificate. This may be useful in applications that, for example, expect trust anchors to have a matching issuer and subject. This is, however, a placeholder value. The unsigned certificate is not considered self-signed or self-issued.
件名が空でない場合、送信者は自己署名証明書を作成する方法と同様に、発行者を件名に設定してもよい(MAY)。これは、たとえば、トラストアンカーが発行者とサブジェクトを一致させることを期待するアプリケーションで役立つ場合があります。ただし、これはプレースホルダー値です。署名されていない証明書は、自己署名または自己発行とは見なされません。
Senders MAY alternatively use a short placeholder issuer consisting of a single relative distinguished name that has a single attribute with a type of id-rdna-unsigned and value of a zero-length UTF8String. id-rdna-unsigned is defined as follows:
送信者は、代わりに、id-rdna-unsigned のタイプと長さ 0 の UTF8String の値を持つ単一の属性を持つ単一の相対識別名で構成される短いプレースホルダー発行者を使用してもよい(MAY)。id-rdna-unsigned は次のように定義されます。
id-rdna-unsigned OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 25 1}
This placeholder name, in the string representation of [RFC4514], is:
このプレースホルダー名は、[RFC4514] の文字列表現では次のようになります。
1.3.6.1.5.5.7.25.1=#0C00
Senders MUST omit the issuerUniqueID field, as it is optional, not applicable, and already forbidden by Section 4.1.2.8 of [RFC5280].
送信者は、issuerUniqueID フィールドを省略しなければなりません (MUST)。これはオプションであり、適用されず、[RFC5280] のセクション 4.1.2.8 ですでに禁止されています。
Some X.509 extensions also describe the certificate issuer and thus are not meaningful for an unsigned certificate:
一部の X.509 拡張機能には証明書の発行者も記述されているため、未署名の証明書には意味がありません。
* authority key identifier (Section 4.2.1.1 of [RFC5280])
* 権限キー識別子 ([RFC5280] のセクション 4.2.1.1)
* issuer alternative name (Section 4.2.1.7 of [RFC5280])
* 発行者の代替名 ([RFC5280] のセクション 4.2.1.7)
Senders SHOULD omit the authority key identifier and issuer alternative name extensions. Section 4.2.1.1 of [RFC5280] requires certificates to include the authority key identifier, but it permits an exception for self-signed certificates used when distributing a public key. This document updates [RFC5280] to also permit omitting the authority key identifier in unsigned certificates.
送信者は、権限キー識別子と発行者の代替名拡張子を省略すべきです(SHOULD)。[RFC5280] のセクション 4.2.1.1 では、証明書に認証局鍵識別子を含めることが要求されていますが、公開鍵を配布するときに使用される自己署名証明書については例外が認められています。この文書は [RFC5280] を更新し、未署名の証明書の認証局キー識別子の省略も許可します。
Some extensions reflect whether the subject is a CA or an end entity:
一部の拡張子は、サブジェクトが CA であるかエンド エンティティであるかを反映します。
* key usage (Section 4.2.1.3 of [RFC5280])
* 鍵の使用法 ([RFC5280] のセクション 4.2.1.3)
* basic constraints (Section 4.2.1.9 of [RFC5280])
* 基本的な制約 ([RFC5280] のセクション 4.2.1.9)
Senders SHOULD fill in these values to reflect the subject. That is:
送信者は件名を反映するためにこれらの値を入力する必要があります。つまり:
* If the subject is a CA, it SHOULD assert the keyCertSign key usage bit and SHOULD include a basic constraints extension that sets the cA boolean to TRUE.
* サブジェクトが CA の場合、keyCertSign 鍵使用ビットをアサートすべきであり、cA ブール値を TRUE に設定する基本的な制約拡張を含めるべきです。
* If the subject is an end entity, it SHOULD NOT assert the keyCertSign key usage bit, and it SHOULD either omit the basic constraints extension or set the cA boolean to FALSE. Unlike a self-signed certificate, an unsigned certificate does not issue itself, so there is no need to accommodate a self-signature in either extension.
* サブジェクトがエンドエンティティである場合、keyCertSign キー使用ビットをアサートすべきではなく、基本制約拡張を省略するか、cA ブール値を FALSE に設定すべきです。自己署名証明書とは異なり、未署名証明書はそれ自体を発行しないため、どちらの拡張にも自己署名を含める必要はありません。
X.509 signatures of type id-alg-unsigned are always invalid:
id-alg-unsigned タイプの X.509 署名は常に無効です。
* When processing X.509 certificates without verifying signatures, receivers MAY accept id-alg-unsigned.
* 署名を検証せずに X.509 証明書を処理する場合、受信者は id-alg-unsigned を受け入れてもよい(MAY)。
* When verifying X.509 signatures, receivers MUST reject id-alg-unsigned.
* X.509 署名を検証する場合、受信者は id-alg-unsigned を拒否しなければなりません (MUST)。
In particular, X.509 validators MUST NOT accept id-alg-unsigned in the place of a signature in the certification path.
特に、X.509 バリデーターは、証明書パスの署名の代わりに id-alg-unsigned を受け入れてはなりません (MUST NOT)。
It is expected that most unmodified X.509 applications will already be compliant with this guidance. X.509 applications are thus RECOMMENDED to satisfy these requirements by ignoring this document and instead treating id-alg-unsigned as the same as an unrecognized signature algorithm. An unmodified X.509 validator will be unable to verify the signature (Step (a.1) of Section 6.1.3 of [RFC5280]) and thus reject the certification path. Conversely, in contexts where an X.509 application was ignoring the self-signature, id-alg-unsigned will also be ignored but more efficiently.
ほとんどの未変更の X.509 アプリケーションはすでにこのガイダンスに準拠していることが予想されます。したがって、X.509 アプリケーションは、この文書を無視し、代わりに id-alg-unsigned を認識されない署名アルゴリズムと同じものとして扱うことによって、これらの要件を満たすことが推奨されます。修正されていない X.509 バリデータは署名を検証できず ([RFC5280] セクション 6.1.3 のステップ (a.1))、証明書パスを拒否します。逆に、X.509 アプリケーションが自己署名を無視していたコンテキストでは、id-alg-unsigned も無視されますが、より効率的になります。
In other contexts, an application may require modifications or limit itself to particular forms of unsigned certificates. For example, an application might check self-signedness to classify locally configured certificates as trust anchors or untrusted intermediates. Such an application may need to modify its configuration model or user interface before using an unsigned certificate as a trust anchor.
他のコンテキストでは、アプリケーションに変更が必要な場合や、アプリケーション自体を特定の形式の未署名証明書に制限する場合があります。たとえば、アプリケーションは自己署名をチェックして、ローカルに構成された証明書をトラスト アンカーまたは信頼できない中間証明書として分類する場合があります。このようなアプリケーションでは、署名されていない証明書をトラスト アンカーとして使用する前に、その構成モデルまたはユーザー インターフェイスを変更する必要がある場合があります。
It is best practice to limit cryptographic keys to a single purpose each. If a key is reused across contexts, applications risk cross-protocol attacks when the two uses collide. However, in applications that use self-signed end entity certificates, the subject's key is necessarily used in two ways: the X.509 self-signature and the end entity protocol. Unsigned certificates fix this key reuse by removing the X.509 self-signature.
暗号キーをそれぞれ 1 つの目的に限定することがベスト プラクティスです。キーがコンテキスト間で再利用される場合、2 つの使用法が衝突すると、アプリケーションはクロスプロトコル攻撃の危険にさらされます。ただし、自己署名エンド エンティティ証明書を使用するアプリケーションでは、サブジェクトのキーは必ず 2 つの方法 (X.509 自己署名とエンド エンティティ プロトコル) で使用されます。未署名の証明書は、X.509 自己署名を削除することで、このキーの再利用を修正します。
If an application accepts id-alg-unsigned as part of a certification path, or in any other context where it is necessary to verify the X.509 signature, the signature check would be bypassed. Thus, Section 4 prohibits this and recommends that applications treat id-alg-unsigned the same as any other previously unrecognized signature algorithm. Non-compliant applications risk vulnerabilities analogous to those described in [JWT] and Section 1.1 of [JOSE].
アプリケーションが証明書パスの一部として、または X.509 署名を検証する必要があるその他のコンテキストで id-alg-unsigned を受け入れる場合、署名チェックはバイパスされます。したがって、セクション 4 ではこれを禁止し、アプリケーションが id-alg-unsigned をこれまで認識されていなかった他の署名アルゴリズムと同様に扱うことを推奨しています。非準拠のアプリケーションには、[JWT] および [JOSE] のセクション 1.1 で説明されているものと同様の脆弱性が存在するリスクがあります。
The signature in a self-signed certificate is self-derived and thus of limited use to convey trust. However, some applications might, for example, use it as an integrity check to guard against accidental storage corruption. An unsigned certificate does not provide any integrity check. Applications checking self-signature for integrity SHOULD instead use some other mechanism, such as an external hash that is verified out-of-band.
自己署名証明書の署名は自己派生であるため、信頼を伝えるためには限定的に使用されます。ただし、一部のアプリケーションでは、たとえば、ストレージの偶発的な破損を防ぐための整合性チェックとしてこれを使用する場合があります。署名されていない証明書は整合性チェックを行いません。自己署名の整合性をチェックするアプリケーションは、代わりに、帯域外で検証される外部ハッシュなど、他のメカニズムを使用する必要があります (SHOULD)。
IANA has added the following entry in the "SMI Security for PKIX Module Identifier" registry, defined by [RFC7299]:
IANA は、[RFC7299] で定義されている「SMI Security for PKIX Module Identifier」レジストリに次のエントリを追加しました。
+=========+=========================+===========+
| Decimal | Description | Reference |
+=========+=========================+===========+
| 122 | id-mod-algUnsigned-2025 | RFC 9925 |
+---------+-------------------------+-----------+
Table 1
IANA has added the following entry to the "SMI Security for PKIX Algorithms" registry [RFC7299]:
IANA は、「SMI Security for PKIX Algorithms」レジストリ [RFC7299] に次のエントリを追加しました。
+=========+=================+===========+
| Decimal | Description | Reference |
+=========+=================+===========+
| 36 | id-alg-unsigned | RFC 9925 |
+---------+-----------------+-----------+
Table 2
To allocate id-rdna-unsigned, this document introduces a new PKIX OID arc for relative distinguished name attributes:
id-rdna-unsigned を割り当てるために、このドキュメントでは相対識別名属性用の新しい PKIX OID アークを導入します。
IANA has added the following entry to the "SMI Security for PKIX" registry [RFC7299]:
IANA は、「SMI Security for PKIX」レジストリ [RFC7299] に次のエントリを追加しました。
+=========+=======================================+===========+
| Decimal | Description | Reference |
+=========+=======================================+===========+
| 25 | Relative Distinguished Name Attribute | RFC 9925 |
+---------+---------------------------------------+-----------+
Table 3
IANA has created the "SMI Security for PKIX Relative Distinguished Name Attribute" registry within the "Structure of Management Information (SMI) Numbers (MIB Module Registrations)" registry group.
IANA は、「Structure of Management Information (SMI) Numbers (MIB Module Registrations)」レジストリ グループ内に「SMI Security for PKIX Relative Distinguished Name Attribute」レジストリを作成しました。
The new registry's description is "iso.org.dod.internet.security.mechanisms.pkix.rdna (1.3.6.1.5.5.7.25)".
新しいレジストリの説明は「iso.org.dod.internet.security.mechanisms.pkix.rdna (1.3.6.1.5.5.7.25)」です。
The new registry has three columns and is initialized with the following values:
新しいレジストリには 3 つの列があり、次の値で初期化されます。
+=========+==================+===========+
| Decimal | Description | Reference |
+=========+==================+===========+
| 1 | id-rdna-unsigned | RFC 9925 |
+---------+------------------+-----------+
Table 4
Future updates to this table are to be made according to the Specification Required policy as defined in [RFC8126].
このテーブルの将来の更新は、[RFC8126] で定義されている仕様要求ポリシーに従って行われます。
[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>.
[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>.
[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>.
[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>.
[JOSE] Madden, N., "JOSE: Deprecate 'none' and 'RSA1_5'", Work in
Progress, Internet-Draft, draft-ietf-jose-deprecate-none-
rsa15-03, 19 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-jose-
deprecate-none-rsa15-03>.
[JWT] Sanderson, J., "How Many Days Has It Been Since a JWT
alg:none Vulnerability?",
<https://www.howmanydayssinceajwtalgnonevuln.com/>.
[RFC4158] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., and R.
Nicholas, "Internet X.509 Public Key Infrastructure:
Certification Path Building", RFC 4158,
DOI 10.17487/RFC4158, September 2005,
<https://www.rfc-editor.org/info/rfc4158>.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, DOI 10.17487/RFC4514, June 2006,
<https://www.rfc-editor.org/info/rfc4514>.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Format", RFC 5914, DOI 10.17487/RFC5914, June 2010,
<https://www.rfc-editor.org/info/rfc5914>.
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX
Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
<https://www.rfc-editor.org/info/rfc7299>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[X.509] ITU-T, "Information technology - Open Systems
Interconnection - The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509, ISO/
IEC 9594-8:2020, October 2019,
<https://www.itu.int/rec/t-rec-x.509/en>.
This ASN.1 module uses the conventions established by [RFC5912].
この ASN.1 モジュールは、[RFC5912] によって確立された規則を使用します。
SignatureAlgorithmNone
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algUnsigned-2025(122) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
SIGNATURE-ALGORITHM
FROM AlgorithmInformation-2009 -- in [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
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) } ;
-- Unsigned Signature Algorithm
id-alg-unsigned OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) alg(6) 36 }
sa-unsigned SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-unsigned
PARAMS ARE absent
}
id-rdna-unsigned OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) rdna(25) 1 }
at-unsigned ATTRIBUTE ::= {
TYPE UTF8String (SIZE (0))
IDENTIFIED BY id-rdna-unsigned
}
END
Thanks to Bob Beck, Nick Harper, and Sophie Schmieg for reviewing an early iteration of this document. Thanks to Alex Gaynor for providing a link to cite for [JWT]. Thanks to Russ Housley for additional input.
このドキュメントの初期版をレビューしてくれた Bob Beck、Nick Harper、Sophie Schmieg に感謝します。[JWT] の引用リンクを提供してくれた Alex Gaynor に感謝します。追加の意見を提供してくれた Russ Housley に感謝します。
David Benjamin
Google LLC
Email: davidben@google.com