Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 9608 Vigil Security
Updates: 5280 T. Okubo
Category: Standards Track DigiCert
ISSN: 2070-1721 J. Mandel
AKAYLA, Inc.
June 2024
X.509v3 public key certificates are profiled in RFC 5280. Short-lived certificates are seeing greater use in the Internet. The Certification Authority (CA) that issues these short-lived certificates do not publish revocation information because the certificate lifespan that is shorter than the time needed to detect, report, and distribute revocation information. Some long-lived X.509v3 public key certificates never expire, and they are never revoked. This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate, and it updates the certification path validation algorithm defined in RFC 5280 so that revocation checking is skipped when the noRevAvail certificate extension is present.
X.509V3公開キー証明書はRFC 5280で紹介されています。短命の証明書は、インターネットでより多くの使用を見ています。これらの短命の証明書を発行する認証機関（CA）は、取消情報を検出、報告、および配布するのに必要な時間よりも短い証明書寿命があるため、取消情報を公開しません。一部の長寿命X.509V3公開キー証明書は期限切れになることはなく、取り消されることはありません。この仕様では、Norevavail証明書延長を定義しているため、CAが証明書の取り消し情報を公開しないことを容易に判断し、RFC 5280で定義された認定パス検証アルゴリズムを更新して、NoreVavail証明書拡張拡張のときに取り消しチェックがスキップされるようになります。存在します。
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/rfc9608.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9608で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Terminology
1.2. ASN.1
1.3. History
2. The noRevAvail Certificate Extension
3. Other X.509 Certificate Extensions
4. Certification Path Validation
5. ASN.1 Module
6. Security Considerations
6.1. Short-Lived Certificates
6.2. Long-Lived Certificates
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
X.509v3 public key certificates [RFC5280] with short validity periods are seeing greater use in the Internet. For example, Automatic Certificate Management Environment (ACME) [RFC8555] provides a straightforward way to obtain short-lived certificates. In many cases, no revocation information is made available for short-lived certificates by the Certification Authority (CA). This is because short-lived certificates have a validity period that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking a short-lived certificate that is used for authentication or key management is unnecessary and pointless. On the other hand, revoking a certificate associated with a long-lived signature, such as document signing or code signing, provides some important information about when a compromise was discovered.
X.509V3公開キー証明書[RFC5280]は、妥当性期間が短いため、インターネットでより多くの使用が見られています。たとえば、自動証明書管理環境（ACME）[RFC8555]は、短命の証明書を取得するための簡単な方法を提供します。多くの場合、認定機関（CA）が短命の証明書には取り消し情報は利用できません。これは、短命の証明書の有効期間があり、失効情報を検出、報告、配布するのに必要な時間よりも短いためです。その結果、認証または主要な管理に使用される短命の証明書を取り消すことは不要で無意味です。一方、ドキュメントの署名やコード署名など、長命の署名に関連する証明書を取り消すと、妥協が発見された時期に関する重要な情報が提供されます。
Some long-lived X.509v3 public key certificates never expire, and they are never revoked. For example, a factory might include an IDevID certificate [IEEE802.1AR] to bind the factory-assigned device identity to a factory-installed public key. This identity might include the manufacturer, model, and serial number of the device, which never change. To indicate that a certificate has no well-defined expiration date, the notAfter date in the certificate validity period is set to "99991231235959Z" [RFC5280].
一部の長寿命X.509V3公開キー証明書は期限切れになることはなく、取り消されることはありません。たとえば、工場には、工場で割り当てられたデバイスのIDを工場で取り付けた公開キーに結合するためのIDEVID証明書[IEEE802.1AR]が含まれる場合があります。このアイデンティティには、デバイスのメーカー、モデル、およびシリアル番号が含まれる場合がありますが、これは変更されません。証明書に明確に定義された有効期限がないことを示すために、証明書の有効性期間のNOTAFTER日は「9991231235959Z」[RFC5280]に設定されています。
This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the end-entity certificate, and it updates the certification path validation algorithm defined in [RFC5280] so that revocation checking is skipped when the noRevAvail certificate extension is present.
この仕様では、Norevavailの証明書延長を定義しているため、頼りになる当事者は、CAがエンドエンティティ証明書の失効情報を公開していないことを容易に判断し、[RFC5280]で定義された認定パス検証アルゴリズムを更新して、取り消しチェックがスキップされるときにスキップされるようになります。Norevavail証明書拡張機能が存在します。
Note that the noRevAvail certificate extension provides similar functionality to the ocsp-nocheck certificate extension [RFC6960]. The ocsp-nocheck certificate extension is appropriate for inclusion only in certificates issued to Online Certificate Status Protocol (OCSP) responders, whereas the noRevAvail certificate extension is appropriate in any end-entity certificate for which the CA will not publish revocation information. To avoid disruption to the OCSP ecosystem, implementers should not think of the noRevAvail certificate extension a substitute for the ocsp-nocheck certificate extension; however, the noRevAvail certificate extension could be included in certificates issued to OCSP responders in addition to the ocsp-nocheck certificate extension.
NoreVavail証明書拡張は、OCSP-Nocheck証明書拡張[RFC6960]と同様の機能を提供することに注意してください。OCSP-Nocheck証明書延長は、オンライン証明書ステータスプロトコル（OCSP）レスポンダーに発行された証明書のみにのみを含めるのに適していますが、Norevavail証明書延長は、CAが失効情報を公開しないエンドエンティティ証明書で適切です。OCSPエコシステムの混乱を避けるために、実装者はnorevavail証明書拡張がOCSP-nocheck証明書延長の代替品であると考えるべきではありません。ただし、Norevavail証明書延長は、OCSP-Nocheck証明書延長に加えて、OCSP応答者に発行された証明書に含めることができます。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
X.509 certificates are generated using ASN.1 [X.680], using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X.690].
X.509証明書は、基本的なエンコーディングルール（BER）と識別式エンコードルール（der）[x.690]を使用して、asn.1 [x.680]を使用して生成されます。
In 1988, CCITT defined the X.509v1 certificate [X.509-1988].
1988年、CCITTはX.509V1証明書[X.509-1988]を定義しました。
In 1997, ITU-T defined the X.509v3 certificate and the attribute certificate [X.509-1997].
1997年、ITU-TはX.509V3証明書と属性証明書[X.509-1997]を定義しました。
In 1999, the IETF first profiled the X.509v3 certificate for use in the Internet [RFC2459].
1999年、IETFは最初にインターネットで使用するX.509V3証明書をプロファイリングしました[RFC2459]。
In 2000, ITU-T defined the noRevAvail certificate extension for use with attribute certificates [X.509-2000].
2000年に、ITU-Tは、属性証明書[X.509-2000]で使用するためにNoreVavail証明書延長を定義しました。
In 2002, the IETF first profiled the attribute certificate for use in the Internet [RFC3281], and this profile included support for the noRevAvail certificate extension.
2002年、IETFは最初にインターネットで使用する属性証明書[RFC3281]をプロファイルし、このプロファイルにはNorevavail証明書延長のサポートが含まれていました。
In 2019, ITU-T published an update to ITU-T Recommendation X.509 [X.509-2019].
2019年、ITU-TはITU-T推奨X.509 [X.509-2019]のアップデートを公開しました。
With greater use of short-lived certificates in the Internet, the recent Technical Corrigendum to ITU-T Recommendation X.509 [X.509-2019-TC2] allows the noRevAvail certificate extension to be used with public key certificates as well as attribute certificates.
インターネットでの短命の証明書をより多く使用することで、最近の技術的なコンリゲンダムからITU-T推奨X.509 [X.509-2019-TC2]により、Norevavailの証明書延長を公開キー証明書と属性証明書で使用することができます。
The noRevAvail extension, defined in [X.509-2019-TC2], allows a CA to indicate that no revocation information will be made available for this certificate.
[X.509-2019-TC2]で定義されているNorevavail拡張機能により、CAはこの証明書に失効情報が利用できないことを示すことができます。
This extension MUST NOT be present in CA public key certificates.
この拡張機能は、CA公開キー証明書に存在してはなりません。
Conforming CAs MUST include this extension in certificates for which no revocation information will be published. When present, conforming CAs MUST mark this extension as non-critical.
適合CASは、取り消し情報が公開されない証明書にこの拡張機能を含める必要があります。存在する場合、適合CASはこの拡張を非批判的であるとマークする必要があります。
name id-ce-noRevAvail
OID { id-ce 56 }
syntax NULL (i.e. '0500'H is the DER encoding)
criticality MUST be FALSE
A relying party that does not understand this extension might be able to find a Certificate Revocation List (CRL) from the CA, but the CRL will never include an entry for the certificate containing this extension.
この拡張機能を理解していない頼りの当事者は、CAから証明書の取り消しリスト（CRL）を見つけることができるかもしれませんが、CRLにはこの拡張機能を含む証明書のエントリは決して含まれません。
Certificates for CAs MUST NOT include the noRevAvail extension. Certificates that include the noRevAvail extension MUST NOT include certificate extensions that point to CRL repositories or provide locations of OCSP responders. If the noRevAvail extension is present in a certificate, then:
CASの証明書には、Norevavail拡張機能を含めてはなりません。Norevavail拡張機能を含む証明書は、CRLリポジトリを指す証明書拡張機能を含めてはなりません。Norevavail拡張機能が証明書に存在する場合、次のことです。
* The certificate MUST NOT also include the basic constraints certificate extension with the cA BOOLEAN set to TRUE; see Section 4.2.1.9 of [RFC5280].
* 証明書には、CA BooleanセットがTrueに設定された基本的な制約証明書延長も含めてはなりません。[RFC5280]のセクション4.2.1.9を参照してください。
* The certificate MUST NOT also include the CRL Distribution Points certificate extension; see Section 4.2.1.13 of [RFC5280].
* 証明書には、CRL配布ポイント証明書延長も含めてはなりません。[RFC5280]のセクション4.2.1.13を参照してください。
* The certificate MUST NOT also include the Freshest CRL certificate extension; see Section 4.2.1.15 of [RFC5280].
* 証明書には、最新のCRL証明書延長も含めてはなりません。[RFC5280]のセクション4.2.1.15を参照してください。
* The Authority Information Access certificate extension, if present, MUST NOT include an id-ad-ocsp accessMethod; see Section 4.2.2.1 of [RFC5280].
* 権限情報アクセス証明書拡張には、存在する場合は、ID-AD-OCSP AccessMethodを含めてはなりません。[RFC5280]のセクション4.2.2.1を参照してください。
If any of the above are violated in a certificate, then the relying party MUST consider the certificate invalid.
上記のいずれかが証明書に違反されている場合、頼る当事者は証明書が無効であると考える必要があります。
Section 6.1.3 of [RFC5280] describes basic certificate processing within the certification path validation procedures. In particular, Step (a)(3) says:
[RFC5280]のセクション6.1.3では、認定パス検証手順内の基本的な証明書処理について説明します。特に、ステップ（a）（3）は次のように述べています。
At the current time, the certificate is not revoked. This may be determined by obtaining the appropriate CRL (Section 6.3), by status information, or by out-of-band mechanisms.
現時点では、証明書は取り消されません。これは、適切なCRL（セクション6.3）、ステータス情報、または帯域外のメカニズムを取得することによって決定される場合があります。
If the noRevAvail certificate extension specified in this document is present or the ocsp-nocheck certificate extension [RFC6960] is present, then Step (a)(3) is skipped. Otherwise, revocation status determination of the certificate is performed.
このドキュメントで指定されたNoreVail証明書拡張が存在するか、OCSP-Nocheck証明書拡張[RFC6960]が存在する場合、ステップ（a）（3）がスキップされます。それ以外の場合、証明書の取り消しステータス決定が実行されます。
This section provides an ASN.1 module [X.680] for the noRevAvail certificate extension, and it follows the conventions established in [RFC5912] and [RFC6268].
このセクションでは、Norevavail証明書拡張のASN.1モジュール[X.680]を提供し、[RFC5912]および[RFC6268]で確立された規則に従います。
NoRevAvailExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-noRevAvail(110) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
EXTENSION
FROM PKIX-CommonTypes-2009 -- 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) } ;
-- noRevAvail Certificate Extension
ext-noRevAvail EXTENSION ::= {
SYNTAX NULL
IDENTIFIED BY id-ce-noRevAvail
CRITICALITY { FALSE } }
-- noRevAvail Certificate Extension OID
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
id-ce-noRevAvail OBJECT IDENTIFIER ::= { id-ce 56 }
END
The Security Considerations in [RFC5280] are relevant.
[RFC5280]のセキュリティ上の考慮事項は関連しています。
When the noRevAvail certificate extension is included in a certificate, all revocation checking is bypassed. CA policies and practices MUST ensure that the noRevAvail certificate extension is included only when appropriate, as any misuse or misconfiguration could result in a relying party continuing to trust a revoked certificate. When such misuse is discovered, the only possible remediation is the revocation of the CA.
Norevavailの証明書延長が証明書に含まれている場合、すべての失効チェックがバイパスされます。CAのポリシーと慣行は、誤用や誤解が依存している当事者が取り消された証明書を信頼し続ける可能性があるため、適切な場合にのみNorevavail証明書延長が含まれることを保証する必要があります。そのような誤用が発見されると、唯一の可能な修復はCAの取り消しです。
Some applications may have dependencies on revocation information or assume its availability. The absence of revocation information may require modifications or alternative configuration settings to ensure proper application security and functionality.
一部のアプリケーションは、取り消し情報に依存関係がある場合や、その可用性を想定する場合があります。取り消し情報がないため、適切なアプリケーションのセキュリティと機能を確保するために、変更または代替構成設定が必要になる場合があります。
The absence of revocation information limits the ability of relying parties to detect compromise of end-entity keying material or malicious certificates. It also limits their ability to detect CAs that are not following the security practices, certificate issuance policies, and operational controls that are specified in the Certificate Policy (CP) or the Certification Practices Statement (CPS) [RFC3647].
取り消し情報がないことは、エンドエンティティキーイングマテリアルまたは悪意のある証明書の妥協を検出する当事者に依存する能力を制限します。また、セキュリティ慣行、証明書発行ポリシー、および証明書ポリシー（CP）または認定慣行声明（CPS）[RFC3647]で指定されている運用管理に従わないCAを検出する能力も制限します。
Since the absence of revocation information may limit the ability to detect compromised keying material or malicious certificates, relying parties need confidence that the CA is following security practices, implementing certificate issuance policies, and properly using operational controls. Relying parties may evaluate CA reliability, monitor CA performance, and observe CA incident response capabilities.
取り消し情報がないと、侵害されたキーイングマテリアルまたは悪意のある証明書を検出する能力が制限される可能性があるため、当事者は、CAがセキュリティ慣行に従っているという自信、証明書の発行ポリシーの実施、および運用管理を適切に使用する必要があります。頼る当事者は、CAの信頼性を評価し、CAのパフォーマンスを監視し、CAインシデント応答能力を観察することができます。
No revocation information is made available for short-lived certificates because the certificate validity period is shorter than the time needed to detect, report, and distribute revocation information. If the noRevAvail certificate extension is incorrectly used for a certificate validity period that is not adequately short, it creates a window of opportunity for attackers to exploit a compromised private key. Therefore, it is crucial to carefully assess and set an appropriate certificate validity period before implementing the noRevAvail certificate extension.
証明書の有効性期間は、失効情報を検出、報告、および配布するのに必要な時間よりも短いため、短命の証明書には取り消し情報が利用できません。NoreVavailの証明書延長が、適切に短くない証明書の有効期間に誤って使用されている場合、攻撃者が侵害された秘密鍵を悪用する機会の窓を作成します。したがって、Norevavail証明書延長を実装する前に、適切な証明書の有効性期間を慎重に評価および設定することが重要です。
No revocation information is made available for some long-lived certificates that contain information that never changes. For example, IDevID certificates [IEEE802.1AR] are included in devices at the factory, and they are used to obtain LDevID certificates [IEEE802.1AR] in an operational environment. In this case, cryptographic algorithms that are expected to remain secure for the expected lifetime of the device need to be chosen. If the noRevAvail certificate extension is used, the CA has no means of notifying the relying party about compromise of the factory-installed keying material.
変更されない情報を含むいくつかの長命の証明書については、取り消し情報は利用できません。たとえば、IDEVID証明書[IEEE802.1AR]は工場のデバイスに含まれており、運用環境でLDEVID証明書[IEEE802.1AR]を取得するために使用されます。この場合、デバイスの予想される寿命のために安全なままであると予想される暗号化アルゴリズムを選択する必要があります。Norevavail証明書延長が使用されている場合、CAは、工場でインストールされたキーイング材料の妥協について頼る当事者に通知する手段を持っていません。
IANA has assigned the following object identifier (OID) for the ASN.1 module (see Section 5) within the "SMI Security for PKIX Module Identifier" (1.3.6.1.5.5.7.0) registry:
IANAは、「PKIXモジュール識別子のSMIセキュリティ」（1.3.6.1.1.5.5.7.0）レジストリ内で、ASN.1モジュール（セクション5を参照）に次のオブジェクト識別子（OID）を割り当てました。
+=========+===================+
| Decimal | Description |
+=========+===================+
| 110 | id-mod-noRevAvail |
+---------+-------------------+
Table 1
[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>.
[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>.
[X.509-2019-TC2]
ITU-T, "Information Technology -- Open Systems
Interconnection -- The Directory: Public-key and attribute
certificate frameworks -- Technical Corrigendum 2", ITU-T
Recommendation X.509-2019/Cor.2-2023, October 2023,
<https://www.itu.int/rec/T-REC-X.509-202310-I!Cor2>.
[X.680] 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>.
[X.690] 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>.
[IEEE802.1AR]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Secure Device Identity", IEEE 802.1AR-2018,
DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018,
<https://ieeexplore.ieee.org/document/8423794>.
[RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, DOI 10.17487/RFC2459, January 1999,
<https://www.rfc-editor.org/info/rfc2459>.
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281,
DOI 10.17487/RFC3281, April 2002,
<https://www.rfc-editor.org/info/rfc3281>.
[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>.
[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>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[X.509-1988]
CCITT, "The Directory - Authentication Framework", CCITT
Recommendation X.509-1988, November 1988,
<https://www.itu.int/rec/T-REC-X.509-198811-S>.
[X.509-1997]
ITU-T, "Information technology -- Open Systems
Interconnection -- The Directory: Authentication
framework", ITU-T Recommendation X.509-1997, August 1997,
<https://www.itu.int/rec/T-REC-X.509-199708-S>.
[X.509-2000]
ITU-T, "Information Technology -- Open Systems
Interconnection -- The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509-2000,
March 2000,
<https://www.itu.int/rec/T-REC-X.509-200003-S>.
[X.509-2019]
ITU-T, "Information Technology -- Open Systems
Interconnection -- The Directory: Public-key and attribute
certificate frameworks", ITU-T Recommendation X.509-2019,
October 2019,
<https://www.itu.int/rec/T-REC-X.509-201910-I>.
Many thanks to Erik Anderson for his efforts to make the noRevAvail certificate extension available for use with public key end-entity certificates as well as attribute certificates.
Erik Andersonに、Norevavailの証明書拡張機能を公開キーエンドエンティティ証明書と属性証明書で使用できるようにしてくれたことに感謝します。
Many thanks to (in alphabetical order) Corey Bonnell, Hendrik Brockhaus, Tim Hollebeek, Mike Ounsworth, Seo Suchan, Carl Wallace, Éric Vyncke, and Paul Wouters for their review and insightful comments.
（アルファベット順）Corey Bonnell、Hendrik Brockhaus、Tim Hollebeek、Mike Ounsworth、Seo Sutan、Carl Wallace、Eric Vyncke、およびPaul Woutersにレビューと洞察に満ちたコメントに感謝します。
Russ Housley
Vigil Security, LLC
Herndon, Virginia
United States of America
Email: housley@vigilsec.com
Tomofumi Okubo
DigiCert, Inc.
Fairfax, Virginia
United States of America
Email: tomofumi.okubo+ietf@gmail.com
Joseph Mandel
AKAYLA, Inc.
Tacoma, Washington
United States of America
Email: joe@akayla.com