Network Working Group S. Farrell
Request for Comments: 5697 Trinity College Dublin
Category: Experimental November 2009
Other Certificates Extension
Abstract
抽象
Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit.
公開鍵証明書との自由連合情報は、道の恩恵を受けることができるいくつかのアプリケーションが同じエンドエンティティに属している証明書のセットを一緒にリンクすると、それは安全にそのアプリケーションの状態情報を参照する目的のために互いに同等とみなすことができます。このメモは、アプリケーションは、新しいアプリケーション・プロトコル・データ・ユニットを導入することなく、必要な結合を確立することを可能にする証明書の拡張機能を定義します。
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. A Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Other Certificates Extension . . . . . . . . . . . . . . . . . 3
4. Another Approach Using Permanent Identifiers . . . . . . . . . 5
5. A Possible Optimisation . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 8
RFC 5280 [RFC5280] defines a profile for the use of public key certificates for Internet applications. If an application associates application-state information with a public key certificate, then that association may be disrupted if the end entity changes its public key certificate. Such disruption can occur due to renewals or if the end entity changes its certificate issuer. Similarly, if the end entity is actually a distributed system, where each instance has a different private key, then the relying party (RP) has no way to associate the different public key certificates with the relevant application-state information.
RFC 5280 [RFC5280]はインターネットアプリケーションのための公開鍵証明書を使用するためのプロファイルを定義します。公開鍵証明書を使用してアプリケーションを関連付けるアプリケーション状態情報場合、エンドエンティティは、その公開鍵証明書を変更した場合、その関連付けが破壊されてもよいです。そのような破壊が原因更新またはエンドエンティティは、その証明書発行者を変更した場合に発生することができます。エンドエンティティは、実際に各インスタンスは異なる秘密鍵を有する分散システムであれば同様に、次いで、依拠当事者（RP）は、関連するアプリケーションの状態情報と異なる公開鍵証明書を関連付ける方法がありません。
For example, assume a web browser retains state information (perhaps passwords) about a web site, indexed (possibly indirectly) via values contained in the web server's public key certificate (perhaps a DNS name). When the web server certificate expires and a new certificate is acquired (perhaps with a different DNS name), then the browser cannot safely map the new certificate to the relevant state information.
たとえば、WebブラウザがWebサーバの公開鍵証明書に含まれる値を経由して（おそらく間接的に）インデックス付きのウェブサイト、（おそらくDNS名）についての状態情報（おそらくパスワード）を保持を前提としています。 Webサーバ証明書の有効期限が切れると、新しい証明書が（おそらく別のDNS名で）取得した場合、ブラウザは安全に関連する状態情報に新しい証明書をマッピングすることはできません。
This memo defines a new public key certificate extension that supports such linkage, allowing the certificate issuer to attest that the end entity that holds the private key for the certificate in question also holds other private keys corresponding to other identified certificates.
このメモは、証明書発行者が問題の証明書の秘密鍵を保持しているエンドエンティティは、他の特定された証明書に対応する他の秘密鍵を保持していることを証明することができ、そのような連携をサポートする新しい公開鍵証明書の拡張機能を定義します。
Other than the issuer asserting that the set of certificates belongs to the same end entity for use with the same application, the fine detail of the semantics of the linkage of certificates is not defined here, since that is a matter for application developers and the operators of certification authorities (CAs). In particular, we do not define how a CA can validate that the same end entity is the holder of the various private keys, nor how the application should make use of this information. Nor do we define what kinds of state information may be shared.
証明書のセットは、同じアプリケーションで使用するために、同じエンドエンティティに属していることが、アプリケーション開発者と事業者のための問題であることから、証明書の結合のセマンティクスの細部は、ここで定義されていないことを主張する発行者以外の証明機関（CA）の。特に、我々は、CAが同じエンドエンティティは、様々な秘密鍵の所有者であることを検証する方法を定義していない、またアプリケーションがこの情報を利用する必要がありますか。 NOR我々は共有することができる状態情報の種類を定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Public key certificates expire, typically about a year after they are created. Some applications might need to know that the same entity is the subject of the current certificate and a previously used certificate.
公開鍵証明書は、一般的に、彼らが作成された後約一年、期限が切れます。一部のアプリケーションでは、同じエンティティが現在の証明書と、以前に使用される証明書の対象であることを知っておく必要があるかもしれません。
For example, if a web server certificate expires, it could be useful for a web browser to know that the server currently presenting a certificate in a Transport Layer Security (TLS) [RFC5246] handshake represents the same web server that previously presented a certificate. This could be used, for example, to allow the browser to automatically fill in form fields for the server in question, even if the server certificate has been replaced. While the same effect can be achieved based on the use of the same issuer and subject fields in a certificate, there could be security issues involved in such comparisons, e.g., if the subject name includes a DNS name and the ownership of that DNS domain has changed.
、Webサーバ証明書の有効期限が切れた場合例えば、サーバが現在トランスポート層セキュリティ（TLS）[RFC5246]ハンドシェイクで証明書を提示することを知るために、ウェブブラウザのために有用である可能性があり、以前に証明書を提示し、同じWebサーバーを表します。これは、例えば、サーバ証明書が交換された場合でも、ブラウザが自動的に問題のサーバー用のフォームフィールドに入力できるようにするために、使用することができます。同じ効果は、同じ発行者と証明書のサブジェクトフィールドの使用に基づいて、サブジェクト名はDNS名が含まれており、そのDNSドメインの所有権を持っている場合、例えば、このような比較に関わるセキュリティ上の問題がある可能性が実現することができるが、かわった。
The use of the new extension provides a way for the CA to signal to the application that the same end entity is involved, regardless of name changes. The new extension could also allow the web site operator to more easily change the CA when replacing its certificate.
新しい拡張機能を使用するには、CAが同じエンドエンティティは関係なく、名前の変更、関与しているアプリケーションに合図するための方法を提供します。新しい拡張もその証明書を交換する際にWebサイト運営者は、より簡単にCAを変更する可能性があります。
This section defines the syntax for the other certificates extension.
このセクションでは、他の証明書の拡張のための構文を定義します。
The new extension is simply a list of references to the linked certificates. The references make use of the SCVPCertID structure from the Server-Based Certificate Validation Protocol (SCVP) [RFC5055], which contains a hash over the relevant certificate and the certificate's issuer and serial number.
新しい拡張機能は、単純にリンクされた証明書への参照のリストです。参照は、関連する証明書と証明書の発行者とシリアル番号の上にハッシュが含まれているサーバーベースの証明書の検証プロトコル（SCVP）[RFC5055]、からSCVPCertID構造を利用します。
When this extension is present, the CA is asserting that the same end entity is the subject of the relevant certificates.
この拡張が存在する場合、CAは、同じエンドエンティティは、関連する証明書の主題であることが主張されています。
This extension MUST NOT be marked critical.
この拡張は、クリティカルマークされてはなりません。
id-pe-otherCerts OBJECT IDENTIFIER ::= { id-pe 19 }
OtherCertificates ::= SEQUENCE OF SCVPCertID
CAs MUST only issue certificates containing this extension where the links created are such that the relevant consumers of the certificates can safely make use of those links. This will typically be the case where the certificates are only used by a single application. CAs MUST NOT issue certificates that link to certificates issued for a different purpose, for example, a CA SHOULD NOT link a web server certificate to a VPN gateway certificate (unless those can be the same, which might occur for some embedded devices). The purpose for which the certificate is intended may be determined by certificate policy or other means (e.g., extended key usage object identifiers) that are out of the scope of this specification.
CAはのみ作成されたリンクは、証明書の関連する消費者が安全にこれらのリンクを利用できるようになっているこの拡張を含む証明書を発行しなければなりません。これは、典型的には、証明書は、単一のアプリケーションで使用される場合であろう。 CAは異なる目的のために発行された証明書にリンク証明書を発行してはならない（これらは、いくつかの組み込みデバイスで発生する可能性のある、同じにすることができない限り）、例えば、CAは、VPNゲートウェイの証明書へのWebサーバー証明書をリンクすべきではありません。証明書が意図する目的は、本明細書の範囲外であること（例えば、拡張鍵使用のオブジェクト識別子）証明書ポリシーまたは他の手段によって決定することができます。
CAs MUST NOT issue certificates containing this extension unless they have validated that the end entity is the holder of all of the relevant private keys.
彼らは、エンドエンティティは、関連する秘密鍵のすべての所有者であることを検証していない限り、CAは、この拡張を含む証明書を発行してはなりません。
Applications MUST validate certificates according to the rules specified in RFC 5280 [RFC5280] and MUST NOT assume that because certificates are linked that they are therefore valid. This means, of course, that both certificates must chain up to some local trust point(s).
アプリケーションは、RFC 5280 [RFC5280]で指定されたルールに従って証明書を検証しなければならないと仮定してはいけません証明書が、彼らはそのため有効であることをリンクされているので、その。これは、両方の証明書は、いくつかの地元の信頼ポイント（複数可）にチェーンアップしなければならないことを、当然のことながら、意味します。
If an application imposes further checks on certificate validity (e.g., as is done in RFC 2818 [RFC2818] for web server certificates), then both certificates MUST be valid according to those application-specific rules.
アプリケーションは、証明書の有効性にさらにチェックする（Webサーバ証明書の例えば、RFC 2818で行われるように[RFC2818]）を課す場合には、両方の証明書は、これらのアプリケーション固有の規則に従って有効でなければなりません。
It is not required that two linked certificates be simultaneously valid. For example, an application can validate certificate1 and cache that information. When the application is subsequently presented with certificate2 (linked back to certificate1), if it considers the cached information about certificate1 trustworthy, then it can validate certificate2 and use the linkage to associate certificate2 with the relevant application-state information (just as it would have done had certificate1 been re-presented). As a second example, if certificate1 has expired but would otherwise be valid, then the linkage from certificate2 can also be used once certificate2 has been validated.
2つのリンクされた証明書が同時に有効である必要はありません。たとえば、アプリケーションが証書を検証し、その情報をキャッシュすることができます。アプリケーションは、その後証書を提示された場合、それが信頼できる証書についてのキャッシュされた情報を考慮した場合、（バック証書にリンクされ）、それは証書を検証し、それが持っているのと同じように、関連するアプリケーションの状態情報（と証書関連付けるためにリンクを使用することができます行っていた証書は再提示されて）。証書の有効期限が切れているが、それ以外は有効であるかどう証書が検証された後、第2の例として、その後、証書からのリンクも使用することができます。
If the application checks certificate status for the certificates in question, and any of the certificates concerned has been revoked, then the linkage MUST NOT be used.
問題の証明書、および関係する証明書のいずれかのアプリケーションを確認証明書のステータスが取り消された場合は、リンクを使用してはいけません。
Note that there are no constraints on the contents of the certificate to which the link points. The consequence is that the CA issuing the new certificate can link back to legacy certificates of all kinds, once the relevant RP supports this extension.
リンクポイントに証明書の内容に制約がないことに注意してください。その結果は、関連するRPは、この拡張機能をサポートしていたら、新しい証明書を発行するCAは、すべての種類のレガシー証明書にリンクすることができますということです。
This extension MUST only be used in end-entity certificates, that is, it MUST NOT be used in CA certificates or other similar certificates. Since CA certificates are only used for certificate validation and this extension has no effect on the validation procedure, this extension would generally be meaningless in a CA certificate. In addition, it may be wise to gain some deployment experience with this extension before using it for more security-sensitive certificates, like CA certificates.
この拡張はつまり、それはCA証明書または他の同様の証明書に使用してはいけません、エンドエンティティ証明書に使用しなければなりません。 CA証明書のみ証明書の検証に使用されており、この拡張は、検証手順には影響しませんので、この拡張機能は、一般的にCA証明書で意味がありません。また、CA証明書のように、より多くのセキュリティに敏感な証明書のためにそれを使用する前に、この拡張子を持ついくつかの展開の経験を積むのが賢明かもしれません。
RFC 4043 [RFC4043] defines a new name form (a "Permanent Identifier" or PI) for public key certificates that supports similar functionality to the new extension defined here. If two certificates have the same PI and that PI form is globally unique, then the end entities involved can be considered to be the same.
RFC 4043 [RFC4043]は、ここで定義された新しい拡張機能と同様の機能をサポートしている公開鍵証明書の新しい名前のフォーム（「永久識別子」またはPI）を定義します。 2つの証明書が同じPIを持っており、そのPIフォームがグローバルに一意である場合には、関係するエンドエンティティが同じであると考えることができます。
The main difference between the PI and the other certificates extension is that (when more than one CA is involved) PI requires a globally unique identifier, whereas the other certificates extension only requires that the issuer of the new certificate be able to link back to the old certificate(s).
PIと他の証明書の拡張機能の主な違いは、（複数のCAが含まれている場合）他の証明書の拡張子が唯一の新しい証明書の発行者がリンクに戻ることができることを要求に対し、PIは、グローバルに一意の識別子を必要とすることです古い証明書（複数可）。
As a consequence, the other certificates extension can be deployed "reactively" to link certificates that may not match "ideal" application-naming requirements. If the old certificate did make use of PI, then presumably application-naming issues have already been handled, and then the new certificate can contain the same PI. In this latter case, there would be no need for the other certificates extension.
その結果、他の証明書の拡張子は「理想的な」アプリケーションの命名要件と一致しない場合があり、リンク証明書に「反応的」に展開することができます。古い証明書は、PIを利用していた場合は、おそらくアプリケーションの命名の問題は、すでに処理されているし、新しい証明書が同じPIを含むことができます。この後者の場合には、他の証明書の延長は必要ないでしょう。
The SCVPCertID structure used here contains the issuer name for the CA of the linked certificate. It may happen that this issuer is also the issuer of the certificate containing the other certificates extension. If a new certificate were linked back to a number of old certificates from that same CA, then there would be considerable redundancy since there would be many copies of the same issuer name.
ここで使用SCVPCertID構造は、リンクされた証明書のCAの発行者名が含まれています。この発行者はまた、他の証明書拡張を含む証明書の発行人であることが起こり得ます。新しい証明書は、同じCAから古い証明書の数に戻ってリンクされていた場合は、同じ発行者名の多くのコピーが存在することになるため、その後、かなりの冗長性が存在することになります。
One suggestion raised was to have a convention where if the X.500 Name in the SCVPCertID is an "empty" DN (see RFC5280), then that would indicate that the same CA issued both the current and the linked certificates. However, that scheme is not adopted in this version. A future, Standards Track version of this specification might adopt that optimisation.
上げ1つの提案は、SCVPCertIDでX.500名前は「空」DN（RFC5280を参照）である場合、それは同じCAが現在とリンクされた証明書の両方を発行したことを示すことになる規則を持っていることでした。しかし、そのスキームは、このバージョンで採用されていません。将来的には、この仕様の標準化過程のバージョンは、その最適化を採用することがあります。
The use case motivating this was contributed to the W3C web security context (WSC) working group by Tyler Close. See http://www.w3.org/2006/WSC/wiki/SafeWebFormEditor for details.
これをやる気にユースケースは、タイラー閉じるによるワーキンググループW3C Webセキュリティコンテキスト（WSC）に貢献しました。詳細については、http://www.w3.org/2006/WSC/wiki/SafeWebFormEditorを参照してください。
Denis Pinkas pointed out that the PI extension is an alternative to this one.
デニスピンカスは、PIの拡張子はこの1つの代替であることを指摘しました。
James Manger suggested the optimisation to reduce the number of copies of the issuer name.
ジェームズ・マネージャは、発行者名のコピーの数を減らすために最適化を示唆しました。
As stated above, relying parties MUST validate any certificates per the algorithm given in RFC 5280 [RFC5280] before making any use of those certificates.
上述したように、依拠当事者は、それらの証明書のいずれかを利用する前に、RFC 5280 [RFC5280]で与えられたアルゴリズムごとに任意の証明書を検証しなければなりません。
Relying parties similarly MUST NOT assume that any other fields in the relevant certificates have common values. For example, linked certificates might have non-overlapping key usage extensions.
依拠当事者は、同様に、関連する証明書のいずれかの他のフィールドは、共通の価値観を持っていると仮定してはいけません。例えば、リンクされた証明書が重複しないキー使用拡張を持っているかもしれません。
Since the issuer of the new certificate (or some superior CA) is trusted by the RP, and the RP has validated the new certificate, the RP is basically as reliant on the proper operation of that CA as always -- if the CA wished to "cheat" on the RP, the other certificates extension simply provides a new way to do that, but one that is equivalent to existing vulnerabilities. In many cases, such a bad CA could simply issue a new certificate that is identical in all respects (other than the key pair) and the RP would accept the identity contained in that new certificate.
新しい証明書（またはいくつかの優れたCA）の発行者は、RPから信頼され、RPは、新しい証明書を検証した、RPは、基本的にはいつものようにそのCAの適切な動作に依存しているようにしているので - CAが望んだ場合に他の証明書の拡張機能は、単にそれを行うための新しい方法を提供し、RP上の「カンニング」が、既存の脆弱性と同等である1。多くの場合、そのような悪いCAは、単に（鍵ペアを除く）全ての点で同一である新しい証明書を発行する可能性があり、RPはその新しい証明書に含まれているアイデンティティを受け入れるだろう。
However, if the issuer of the new certificate is limited in some way (e.g., via a name constraint in a superior CA certificate), and if the old certificate doesn't match those limitations (e.g., the subject of the old certificate doesn't fit under the name constraints of the issuer of the new certificate), then the new certificate could be linked back to an identity that doesn't meet the constraints intended to be imposed on the issuer of the new certificate. Applications for which this is an unacceptable risk SHOULD NOT make use of the other certificates extension.
古い証明書は、これらの制限に一致しない場合は、新しい証明書の発行者は、（優れたCA証明書に名前制約を経由して、例えば）何らかの方法で制限され、されている場合（例えば、古い証明書のサブジェクトは」doesnの新しい証明書の発行者の名前制約の下でトンフィット）は、新しい証明書が新しい証明書の発行者に課されることを意図した制約を満たしていないアイデンティティに戻ってリンクすることができます。これは容認できないリスクであるためアプリケーションは、他の証明書の拡張機能を使用するべきではありません。
Since the SCVPCertID structure includes a hash of the other certificate and hash algorithm weaknesses that produce collisions are becoming more of an issue, CAs and relying parties MUST ensure that currently acceptable hash functions are used. In particular, the default use of SHA-1 for SCVPCertID may or may not currently be considered acceptable. CAs might be wise to use SHA-256 instead, but will typically use whatever hash function they use as part of certificate signing.
SCVPCertID構造は、衝突を生成する他の証明書とハッシュアルゴリズムの弱点のハッシュが含まれているので、現在、許容されるハッシュ関数が使用されるようにする必要があり、問題のより多くなってCAと依拠当事者れます。特に、SCVPCertIDためのSHA-1の既定の使用は、あるいは現在許容されると考えられてもしなくてもよいです。 CAは、代わりに、SHA-256を使用するのが賢明かもしれませんが、一般的に、彼らは証明書の署名の一部として使用するものは何でも、ハッシュ関数を使用します。
In some application contexts, if the old certificate has expired (and perhaps any associated certificate revocation list (CRL) entries are no longer on the latest CRL), it may be unsafe to link the new and old certificates. Application developers SHOULD carefully consider whether to make use of the other certificates extension in such contexts.
古い証明書の有効期限が切れている場合、一部のアプリケーション・コンテキストでは、（そしておそらく、関連する証明書失効リスト（CRL）のエントリーはもはや最新のCRLである）、新しいものと古い証明書をリンクする安全でない可能性があります。アプリケーション開発者は慎重に、このような状況で他の証明書の拡張機能を利用するかどうかを検討すべきです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055]フリーマン、T.、Housley氏、R.、Malpani、A.、クーパー、D.、およびW.ポーク、 "サーバーベースの証明書の検証プロトコル（SCVP）"、RFC 5055、2007年12月。
[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, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public Key Infrastructure Permanent Identifier", RFC 4043, May 2005.
[RFC4043]ピンカス、D.とT. Gindin、 "インターネットX.509公開鍵インフラストラクチャ永久識別子"、RFC 4043、2005年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
Appendix A. ASN.1 Module
付録A. ASN.1モジュール
PKIX OID registrations may be viewed at: http://www.imc.org/ietf-pkix/pkix-oid.asn
http://www.imc.org/ietf-pkix/pkix-oid.asn：PKIX OID登録がで見ることができます
PKIXOtherCertsModule { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 44 }
PKIXOtherCertsModule {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）44}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL
- すべてのエクスポート
IMPORTS
輸入
-- From [RFC5055] SCVPCertID FROM SCVP { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 21 } ;
- から[RFC5055] SCVPCertID SCVP FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）21}。
-- The one and only new thing, a new certificate extension
- 唯一の新しいもの、新しい証明書拡張
id-pe-otherCerts OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 19 }
-- The value is a sequence of cert ids.
OtherCertificates ::= SEQUENCE OF SCVPCertID
END
終わり
Author's Address
著者のアドレス
Stephen Farrell Trinity College Dublin Department of Computer Science Trinity College Dublin, 2 Ireland
コンピュータサイエンストリニティ・カレッジ・ダブリン、アイルランドのステファン・ファレルトリニティ・カレッジ・ダブリン科
Phone: +353-1-896-2354 EMail: stephen.farrell@cs.tcd.ie
電話：+ 353-1-896-2354 Eメール：stephen.farrell@cs.tcd.ie