Internet Engineering Task Force (IETF) T. Heer
Request for Comments: 6253 COMSYS, RWTH Aachen University
Updates: 5201 S. Varjonen
Category: Experimental Helsinki Institute for Information Technology
ISSN: 2070-1721 May 2011
Host Identity Protocol Certificates
Abstract
抽象
The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the CERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and Simple Public Key Infrastructure (SPKI) certificates.
証明書（CERT）のパラメータは、デジタル証明書のコンテナです。これは、ホスト識別プロトコル（HIP）制御パケットにこれらの証明書を実施するために使用されます。この文書は、CERTパラメータと失敗した検証の場合のエラー通知を指定します。また、このドキュメントでは、X.509バージョン3（v3）と簡易公開鍵基盤（SPKI）証明書でホスト識別タグの表現を指定します。
The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter.
証明書は、取得要求、およびそのアクションが成功したか失敗したか、検証時に取られている方法などの証明書の具体的な使用は、証明書が使用されるシナリオに固有のものです。したがって、これらのシナリオ固有の側面の定義は、CERTのパラメータを使用する文書に残されています。
This document updates RFC 5201.
この文書は、RFC 5201に更新します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6253.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6253で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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 Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Digital certificates bind pieces of information to a public key by means of a digital signature and thus enable the holder of a private key to generate cryptographically verifiable statements. The Host Identity Protocol (HIP) [RFC5201] defines a new cryptographic namespace based on asymmetric cryptography. The identity of each host is derived from a public key, allowing hosts to digitally sign data and issue certificates with their private key. This document specifies the CERT parameter, which is used to transmit digital certificates in HIP. It fills the placeholder specified in Section 5.2 of [RFC5201] and thus updates [RFC5201].
デジタル証明書は、デジタル署名により公開鍵への情報の断片を結合し、したがって、暗号的に検証可能な文を生成するために、秘密鍵の所有者を有効にします。ホスト識別プロトコル（HIP）[RFC5201]は非対称暗号に基づく新しい暗号化の名前空間を定義します。各ホストのIDは、ホストがデジタルで自分の秘密鍵でデータと発行証明書に署名することができ、公開鍵から導出されます。この文書では、HIPでデジタル証明書を送信するために使用されたCERTパラメータを、指定します。これは[RFC5201]及び従ってアップデート[RFC5201]のセクション5.2で指定されたプレースホルダを充填します。
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 RFC 2119 [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL RFC 2119 [RFC2119]に記載されているように「この文書に解釈されるべきです。
The CERT parameter is a container for certain types of digital certificates. It does not specify any certificate semantics. However, it defines supplementary parameters that help HIP hosts to transmit semantically grouped CERT parameters in a more systematic way. The specific use of the CERT parameter for different use cases is intentionally not discussed in this document, because it is specific to a concrete use case. Hence, the use of the CERT parameter will be defined in the documents that use the CERT parameter.
CERTパラメータは、デジタル証明書の特定の種類のコンテナです。これは、任意の証明書のセマンティクスを指定していません。しかし、それは、より体系的な方法で意味的にグループ化されたCERTパラメータを送信するためにHIPホストを助ける補助的なパラメータを定義します。それは、具体的なユースケースに固有であるため、異なるユースケースのためのCERTパラメータの特定の使用を意図的に、本書で議論されていません。したがって、CERTパラメータの使用は、CERTパラメータを使用した文書で定義されます。
The CERT parameter is covered and protected, when present, by the HIP SIGNATURE field and is a non-critical parameter.
CERTパラメータが覆われて保護、存在する場合、HIPの署名フィールドによると、非重要なパラメータです。
The CERT parameter can be used in all HIP packets. However, using it in the first Initiator (I1) packet is NOT RECOMMENDED, because it can increase the processing times of I1s, which can be problematic when processing storms of I1s. Each HIP control packet MAY contain multiple CERT parameters. These parameters MAY be related or unrelated. Related certificates are managed in Cert groups. A Cert group specifies a group of related CERT parameters that SHOULD be interpreted in a certain order (e.g., for expressing certificate chains). For grouping CERT parameters, the Cert group and the Cert count field MUST be set. Ungrouped certificates exhibit a unique Cert group field and set the Cert count to 1. CERT parameters with the same Cert group number in the group field indicate a logical grouping. The Cert count field indicates the number of CERT parameters in the group.
CERTのパラメータは、すべてのHIPパケットで使用することができます。それはI1sの嵐を処理する際に問題となり得るI1sの処理時間を増加させることができるのでしかし、第一のイニシエータ（I1）パケットでそれを使用することは、推奨されません。各HIP制御パケットは、複数のCERTパラメータを含むかもしれません。これらのパラメータは、関連するまたは関連しないかもしれません。関連の証明書は、証明書のグループで管理されています。証明書のグループ（例えば、証明書チェーンを発現させるため）特定の順序で解釈されるべき関連CERTパラメータのグループを指定します。 CERTパラメータをグループ化するために、証明書グループと証明書カウントフィールドには、設定しなければなりません。グループ化されていない証明書は、独自の証明書グループフィールドを示し、論理グループを示すグループのフィールドに同じ証明書グループ番号を1 CERTパラメータにカウント証明書を設定します。証明書カウントフィールドは、グループ内のCERTパラメータの数を示します。
CERT parameters that belong to the same Cert group MAY be contained in multiple sequential HIP control packets. This is indicated by a higher Cert count than the amount of CERT parameters with matching Cert group fields in a HIP control packet. The CERT parameters MUST be placed in ascending order, within a HIP control packet, according to their Cert group field. Cert groups MAY only span multiple packets if the Cert group does not fit the packet. A HIP packet MUST NOT contain more than one incomplete Cert group that continues in the next HIP control packet.
同じ証明書グループに属するCERTパラメータは、複数の連続HIP制御パケットに含まれていてもよいです。これは、HIP制御パケットに一致する証明書グループのフィールドを持つCERTパラメータの量よりも証明書の数によって示されます。 CERTパラメータは、それらの証明書のグループフィールドに従って、HIP制御パケット内に、昇順に配置する必要があります。証明書グループは、パケットに適合しない場合は証明書グループにのみ複数のパケットにまたがること。 HIPパケットは、次のHIP制御パケットに続く複数の不完全な証明書グループを含めることはできません。
The Cert ID acts as a sequence number to identify the certificates in a Cert group. The numbers in the Cert ID field MUST start from 1 up to Cert count.
証明書IDは、証明書グループ内の証明書を識別するためのシーケンス番号として働きます。証明書IDフィールド内の数字は、証明書の数まで1から開始する必要があります。
The Cert group and Cert ID namespaces are managed locally by each host that sends CERT parameters in HIP control packets.
証明書グループと証明書のIDの名前空間は、HIP制御パケットにCERTパラメータを送信する各ホストによってローカルで管理されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert group | Cert count | Cert ID | Cert type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 768 Length Length in octets, excluding Type, Length, and Padding. Cert group Group ID grouping multiple related CERT parameters. Cert count Total count of certificates that are sent, possibly in several consecutive HIP control packets. Cert ID The sequence number for this certificate. Cert Type Indicates the type of the certificate. Padding Any Padding, if necessary, to make the TLV a multiple of 8 bytes.
タイプ、長さ、およびパディングを除く、オクテット768の長さの長さを入力します。証明書グループのグループIDは、複数の関連CERTパラメータをグループ化します。 CERTは、おそらくいくつかの連続したHIP制御パケットに、送信された証明書の合計数をカウントします。証明書IDこの証明書のシーケンス番号。証明書の種類は、証明書の種類を示します。必要であれば、TLV 8バイトの倍数にするために、任意のパディングをパディング。
The certificates MUST use the algorithms defined in [RFC5201] as the signature and hash algorithms.
証明書は、署名と、ハッシュアルゴリズムのように[RFC5201]で定義されたアルゴリズムを使用しなければなりません。
The following certificate types are defined:
次の証明書の種類が定義されています。
+--------------------------------+-------------+
| Cert format | Type number |
+--------------------------------+-------------+
| Reserved | 0 |
| X.509 v3 | 1 |
| SPKI | 2 |
| Hash and URL of X.509 v3 | 3 |
| Hash and URL of SPKI | 4 |
| LDAP URL of X.509 v3 | 5 |
| LDAP URL of SPKI | 6 |
| Distinguished Name of X.509 v3 | 7 |
| Distinguished Name of SPKI | 8 |
+--------------------------------+-------------+
The next sections outline the use of Host Identity Tags (HITs) in X.509 v3 and in Simple Public Key Infrastructure (SPKI) certificates. X.509 v3 certificates and the handling procedures are defined in [RFC5280]. The wire format for X.509 v3 is the Distinguished Encoding Rules format as defined in [X.690]. The SPKI, the handling procedures, and the formats are defined in [RFC2693].
次のセクションでは、X.509 v3ではおよび簡易公開鍵基盤（SPKI）証明書にホスト識別タグ（ヒット）の使用を概説します。 X.509 v3証明書や取り扱い方法は、[RFC5280]で定義されています。 X.509 v3のためのワイヤ形式は[X.690]で定義されるように識別符号化規則の形式です。 SPKI、処理手順、及びフォーマットは、[RFC2693]で定義されています。
Hash and Uniform Resource Locator (URL) encodings (3 and 4) are used as defined in Section 3.6 of [RFC5996]. Using hash and URL encodings results in smaller HIP control packets than by including the certificate(s), but requires the receiver to resolve the URL or check a local cache against the hash.
[RFC5996]のセクション3.6で定義されたハッシュとユニフォームリソースロケータ（URL）エンコーディング（3及び4）が使用されています。証明書（複数可）を含むことにより、より小さなHIP制御パケット内のハッシュとURLエンコーディングの結果を使用しますが、URLを解決するか、ハッシュに対するローカルキャッシュをチェックするために受信機を必要とします。
Lightweight Directory Access Protocol (LDAP) URL encodings (5 and 6) are used as defined in [RFC4516]. Using LDAP URL encoding results in smaller HIP control packets but requires the receiver to retrieve the certificate or check a local cache against the URL.
[RFC4516]で定義されているのLDAP（Lightweight Directory Access Protocol）URLエンコーディング（5と6）が使用されています。小さなHIP制御パケットでLDAPのURLエンコードの結果を使用しますが、証明書を取得したり、URLに対するローカルキャッシュをチェックするために受信機を必要とします。
Distinguished Name (DN) encodings (7 and 8) are represented by the string representation of the certificate's subject DN as defined in [RFC4514]. Using the DN encoding results in smaller HIP control packets, but requires the receiver to retrieve the certificate or check a local cache against the DN.
[RFC4514]で定義されるように識別名（DN）エンコーディング（7,8）は、証明書のサブジェクトDNの文字列表現で表されます。小さなHIP制御パケットにDNエンコーディング結果を使用しますが、証明書を取得またはDNに対してローカルキャッシュをチェックするために受信機を必要とします。
If needed, HITs can represent an issuer, a subject, or both in X.509 v3. HITs are represented as IPv6 addresses as defined in [RFC4843]. When the Host Identifier (HI) is used to sign the certificate, the respective HIT MUST be placed into the Issuer Alternative Name (IAN) extension using the GeneralName form iPAddress as defined in [RFC5280]. When the certificate is issued for a HIP host, identified by a HIT and HI, the respective HIT MUST be placed into the Subject Alternative Name (SAN) extension using the GeneralName form iPAddress, and the full HI is presented as the subject's public key info as defined in [RFC5280].
必要であれば、ヒットはX.509 v3では、発行者、件名、またはその両方を表すことができます。 [RFC4843]で定義されるようにヒットは、IPv6アドレスとして表されます。ホスト識別子（HI）証明書に署名するために使用される場合、それぞれのHITは[RFC5280]で定義されるよういるGeneralNameフォームIPアドレスを使用して発行者の別名（IAN）拡張に入れなければなりません。証明書は、HIPホストに対して発行されたHITで識別し、HIされている場合、それぞれのHITは、サブジェクトの別名（SAN）の中に置かなければなりません延長のGeneralNameフォームIPアドレスを使用して、そして完全なHIは、対象の公開鍵情報として提示され[RFC5280]で定義されます。
The following examples illustrate how HITs are presented as issuer and subject in the X.509 v3 extension alternative names.
以下の実施例は、ヒットがX.509 v3の拡張代替名に発行者と被写体として提示される方法を示します。
Format of X509v3 extensions:
X509v3 Issuer Alternative Name:
IP Address:hit-of-issuer
X509v3 Subject Alternative Name:
IP Address:hit-of-subject
Example X509v3 extensions: X509v3 Issuer Alternative Name: IP Address:2001:14:6cf:fae7:bb79:bf78:7d64:c056 X509v3 Subject Alternative Name: IP Address:2001:1c:5a14:26de:a07c:385b:de35:60e3
例書X509v3拡張子：書X509v3発行者代替名：IPアドレス：2001：14：6cf：fae7：bb79：bf78：7d64：書X509v3サブジェクトの別名c056：IPアドレス：2001：1C：5a14：26de：a07c：385B：de35：60E3
Appendix B shows a full example of an X.509 v3 certificate with HIP content.
付録Bは、HIP含量のX.509 v3証明書の完全な例を示しています。
As another example, consider a managed Public Key Infrastructure (PKI) environment in which the peers have certificates that are anchored in (potentially different) managed trust chains. In this scenario, the certificates issued to HIP hosts are signed by intermediate Certification Authorities (CAs) up to a root CA. In this example, the managed PKI environment is neither HIP aware, nor can it be configured to compute HITs and include them in the certificates.
別の例として、ピアが信頼チェーンを管理する（潜在的に異なる）に固定されている証明書を持っている管理公開鍵基盤（PKI）環境を考えます。このシナリオでは、HIPホストに発行された証明書は、ルートCAまでの中間証明機関（CA）によって署名されていますこの例では、マネージドPKI環境はどちらもHIP認識しており、またヒットを計算し、証明書に含めるように構成することができます。
When HIP communications are established, the HIP hosts not only need to send their identity certificates (or pointers to their certificates), but also the chain of intermediate CAs (or pointers to the CAs) up to the root CA, or to a CA that is trusted by the remote peer. This chain of certificates MUST be sent in a Cert group as specified in Section 2. The HIP peers validate each other's certificates and compute peer HITs based on the certificate public keys.
HIP通信が確立されると、HIPホストは（自分の証明書またはポインタ）自分のアイデンティティ証明書を送信する必要がなく、中間CA（またはCASへのポインタ）のチェーンだけでなく、ルートCAまで、またはそのCAへリモートピアによって信頼されています。指定された証明書のこの鎖はHIPピアが互いの証明書を検証し、証明書の公開鍵に基づいてピア・ヒットを計算する第2の証明書グループに送信されなければなりません。
When using SPKI certificates to transmit information related to HIP hosts, HITs need to be enclosed within the certificates. HITs can represent an issuer, a subject, or both. In the following, we define the representation of those identifiers for SPKI given as S-expressions. Note that the S-expressions are only the human-readable representation of SPKI certificates. Full HIs are presented in the public key sequences of SPKI certificates.
HIPホストに関連した情報を送信するSPKI証明書を使用する場合、ヒットは、証明書内に封入される必要があります。ヒットは、発行者、件名、またはその両方を表すことができます。以下では、我々はS式として与えられたSPKIのためのこれらの識別子の表現を定義します。 S-式はSPKI証明書の唯一の人間が読める表現であることに注意してください。完全な彼は、SPKI証明書の公開キーシーケンスに提示されています。
As an example, the Host Identity Tag of a host is expressed as follows:
次のように例として、ホストのホスト識別タグが表現されています。
Format: (hash hit hit-of-host)
Example: (hash hit 2001:13:724d:f3c0:6ff0:33c2:15d8:5f50)
Appendix A shows a full example of a SPKI certificate with HIP content.
付録Aは、HIPコンテンツとSPKI証明書の完全な例を示します。
Revocation of X.509 v3 certificates is handled as defined in Section 5 of [RFC5280]. Revocation of SPKI certificates is handled as defined in Section 5 of [RFC2693].
[RFC5280]のセクション5で定義されるようにX.509 v3証明書の失効は、処理されます。 [RFC2693]のセクション5で定義されるようにSPKI証明書の失効は、処理されます。
If the Initiator does not send the certificate that the Responder requires, the Responder may take actions (e.g., reject the connection). The Responder MAY signal this to the Initiator by sending a HIP NOTIFY message with NOTIFICATION parameter error type CREDENTIALS_REQUIRED.
イニシエータは、レスポンダが必要であることの証明書を送信しない場合、Responderは行動を取ることがあり（例えば、接続を拒否します）。レスポンダは、HIPは、通知パラメータエラータイプCREDENTIALS_REQUIREDとNOTIFYメッセージを送信することにより、イニシエータにこのことをシグナリングすることができます。
If the verification of a certificate fails, a verifier MAY signal this to the provider of the certificate by sending a HIP NOTIFY message with NOTIFICATION parameter error type INVALID_CERTIFICATE.
証明書の検証に失敗した場合、検証者は、通知パラメータ・エラー・タイプINVALID_CERTIFICATEでNOTIFYメッセージをHIPを送信することにより、証明書の提供者にこれを知らせることができます。
NOTIFICATION PARAMETER - ERROR TYPES Value
------------------------------------ -----
CREDENTIALS_REQUIRED 48
48を必要な資格情報
The Responder is unwilling to set up an association, as the Initiator did not send the needed credentials.
イニシエータは、必要な資格情報を送信していないようResponderは、関連付けを設定したくないです。
INVALID_CERTIFICATE 50
無効な証明書50
Sent in response to a failed verification of a certificate. Notification Data MAY contain n groups of 2 octets (n calculated from the NOTIFICATION parameter length), in order Cert group and Cert ID of the Certificate parameter that caused the failure.
証明書の検証に失敗に応答して送信されます。通知データは、順序証明書群と故障の原因となった証明書パラメータの証明書IDに、（N通知パラメータの長さから算出）含有N 2つのオクテットのグループMAY。
This document defines the CERT parameter for the Host Identity Protocol [RFC5201]. This parameter is defined in Section 2 with type 768. The parameter type number is also defined in [RFC5201].
この文書では、ホスト識別プロトコル[RFC5201]のためのCERTパラメータを定義します。このパラメータは、パラメータのタイプ番号はまた、[RFC5201]で定義されているタイプ768でセクション2で定義されています。
The CERT parameter has an 8-bit unsigned integer field for different certificate types, for which IANA has created and now maintains a new sub-registry entitled "HIP Certificate Types" under the "Host Identity Protocol (HIP) Parameters". Initial values for the Certificate type registry are given in Section 2. New values for the Certificate types from the unassigned space are assigned through IETF Review.
CERTパラメータは、「パラメータホスト識別プロトコル（HIP）」IANAが作成され、今の下に「HIPの証明書の種類」という新しいサブレジストリを維持しているためにさまざまな証明書の種類、8ビットの符号なし整数フィールドを持ちます。証明書の種類レジストリの初期値が割り当てられていない空間から証明書の種類2.新しい値がIETFレビューを通じて割り当てられているセクションに記載されています。
In Section 6, this document defines two new types for the "NOTIFY Message Types" sub-registry under "Host Identity Protocol (HIP) Parameters".
第6節では、この文書では、「NOTIFYメッセージタイプ」の下のサブレジストリ「ホストアイデンティティプロトコル（HIP）パラメータ」のための2つの新しいタイプを定義します。
Certificate grouping allows the certificates to be sent in multiple consecutive packets. This might allow similar attacks, as IP-layer fragmentation allows, for example, the sending of fragments in the wrong order and skipping some fragments to delay or stall packet processing by the victim in order to use resources (e.g., CPU or memory). Hence, hosts SHOULD implement mechanisms to discard certificate groups with outstanding certificates if state space is scarce.
証明書のグループ化は、証明書が複数の連続するパケットで送信することを可能にします。これは、IP層の断片化が許す限り、例えば、間違った順序でフラグメントの送信遅延やリソース（例えば、CPUやメモリ）を使用するために、被害者がパケット処理を停止するために、いくつかの断片をスキップし、同様の攻撃を許すかもしれません。したがって、ホストは、状態空間が不足している場合に発行済証明書と証明書グループを廃棄する機構を実装する必要があります。
Checking of the URL and LDAP entries might allow denial-of-service (DoS) attacks, where the target host may be subjected to bogus work.
URLおよびLDAPエントリのチェックがターゲットホストが偽の仕事にかけることができるサービス拒否（DoS）攻撃を許す可能性があります。
Security considerations for SPKI certificates are discussed in [RFC2693] and for X.509 v3 in [RFC5280].
SPKI証明書のセキュリティの考慮事項は、[RFC2693]にし、[RFC5280]でX.509 v3のために議論されています。
The authors would like to thank A. Keranen, D. Mattes, M. Komu, and T. Henderson for the fruitful conversations on the subject. D. Mattes most notably contributed the non-HIP aware use case in Section 3.
著者は、件名に実りある会話のためにA. Keranen、D.マッテス、M.こむ、およびT.ヘンダーソンに感謝したいと思います。 D.マッテスは、最も顕著な第3節では非HIP意識ユースケースに貢献しました。
[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月。
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
[RFC2693]エリソン、C.、フランツ、B.、Lampson、B.、リベスト、R.、トーマス、B.、およびT. Ylonenと、 "SPKI証明理論"、RFC 2693、1999年9月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現"。、RFC 4514、2006年6月。
[RFC4516] Smith, M., Ed., and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4516]スミス、M.、エド、およびT.ハウズ、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ユニフォームリソースロケータ"。、RFC 4516、2006年6月。
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC4843] Nikander、P.、Laganier、J.、およびF.デュポン、RFC 4843、2007年4月 "オーバーレイルーティング可能な暗号ハッシュ識別子（ORCHID）のIPv6プレフィックス"。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]モスコウィッツ、R.、Nikander、P.、Jokela、P.、エド。、およびT.ヘンダーソン、 "ホストアイデンティティプロトコル"、RFC 5201、2008年4月。
[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月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年9月。
[X.690] ITU-T, "Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", July 2002.
[X.690] ITU-T、「勧告X.690（2002）| ISO / IEC 8825から1：2002、情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）、Canonicalの符号化規則の仕様（CER ）、および顕著な符号化規則（DER）」、2002年7月。
Appendix A. SPKI Certificate Example
付録A. SPKI証明書の例
This section shows an SPKI certificate with encoded HITs. The example has been indented for readability.
このセクションでは、符号化されたヒットとSPKI証明書を示しています。例では、読みやすくするためにインデントされています。
(sequence (public_key (rsa-pkcs1-sha1 (e #010001#) (n |yDwznOwX0w+zvQbpWoTnfWrUPLKW2NFrpXbsIcH/QBSLb k1RKTZhLasFwvtSHAjqh220W8gRiQAGIqKplyrDEqSrJp OdIsHIQ8BQhJAyILWA1Sa6f5wAnWozDfgdXoKLNdT8ZNB mzluPiw4ozc78p6MHElH75Hm3yHaWxT+s83M=| ) ) ) (cert (issuer (hash hit 2001:15:2453:698a:9aa:253a:dcb5:981e) ) (subject (hash hit 2001:12:ccd6:4715:72a3:2ab1:77e4:4acc) ) (not-before "2011-01-12_13:43:09") (not-after "2011-01-22_13:43:09") ) (signature (hash sha1 |h5fC8HUMATTtK0cjYqIgeN3HCIMA|) |u8NTRutINI/AeeZgN6bngjvjYPtVahvY7MhGfenTpT7MCgBy NoZglqH5Cy2vH6LrQFYWx0MjWoYwHKimEuBKCNd4TK6hrCyAI CIDJAZ70TyKXgONwDNWPOmcc3lFmsih8ezkoBseFWHqRGISIm MLdeaMciP4lVfxPY2AQKdMrBc=| ) )
（シーケンス（PUBLIC_KEY（RSA-PKCS1-SHA1（E＃010001＃）（N | yDwznOwX0w + zvQbpWoTnfWrUPLKW2NFrpXbsIcH / QBSLb k1RKTZhLasFwvtSHAjqh220W8gRiQAGIqKplyrDEqSrJp OdIsHIQ8BQhJAyILWA1Sa6f5wAnWozDfgdXoKLNdT8ZNB mzluPiw4ozc78p6MHElH75Hm3yHaWxT + s83M = |）））（CERT（発行者（ハッシュは、2001ヒット：2453：15：698a：9AA ：253A：dcb5：12：ccd6：4715：72a3：2ab1：77e4：4acc））（非前 "2011-01-12_13：43：09"）（未後に981e））（被験者（ハッシュ2001を打ちます"2011-01-22_13：43：09"））（署名（ハッシュ、SHA1 | h5fC8HUMATTtK0cjYqIgeN3HCIMA |）| u8NTRutINI / AeeZgN6bngjvjYPtVahvY7MhGfenTpT7MCgBy NoZglqH5Cy2vH6LrQFYWx0MjWoYwHKimEuBKCNd4TK6hrCyAI CIDJAZ70TyKXgONwDNWPOmcc3lFmsih8ezkoBseFWHqRGISIm MLdeaMciP4lVfxPY2AQKdMrBc = |））
Appendix B. X.509 v3 Certificate Example
付録B. X.509 v3の証明書の例
This section shows a X.509 v3 certificate with encoded HITs.
このセクションでは、符号化されたヒットとX.509 v3証明書を示しています。
Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=Example issuing host, DC=example, DC=com Validity Not Before: Mar 11 09:01:39 2011 GMT Not After : Mar 21 09:01:39 2011 GMT Subject: CN=Example subject host, DC=example, DC=com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c0:db:38:50:8e:63:ed:96:ea:c6:c4:ec:a3:36: 62:e2:28:e9:74:9c:f5:2f:cb:58:0e:52:54:60:b5: fa:98:87:0d:22:ab:d8:6a:61:74:a9:ee:0b:ae:cd: 18:6f:05:ab:69:66:42:46:00:a2:c0:0c:3a:28:67: 09:cc:52:27:da:79:3e:67:d7:d8:d0:7c:f1:a1:26: fa:38:8f:73:f5:b0:20:c6:f2:0b:7d:77:43:aa:c7: 98:91:7e:1e:04:31:0d:ca:94:55:20:c4:4f:ba:b1: df:d4:61:9d:dd:b9:b5:47:94:6c:06:91:69:30:42: 9c:0a:8b:e3:00:ce:49:ab:e3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Issuer Alternative Name: IP Address:2001:13:8d83:41c5:dc9f:38ed:e742:7281 X509v3 Subject Alternative Name: IP Address:2001:1c:6e02:d3e0:9b90:8417:673e:99db Signature Algorithm: sha1WithRSAEncryption 83:68:b4:38:63:a6:ae:57:68:e2:4d:73:5d:8f:11:e4:ba:30: a0:19:ca:86:22:e9:6b:e9:36:96:af:95:bd:e8:02:b9:72:2f: 30:a2:62:ac:b2:fa:3d:25:c5:24:fd:8d:32:aa:01:4f:a5:8a: f5:06:52:56:0a:86:55:39:2b:ee:7a:7b:46:14:d7:5d:15:82: 4d:74:06:ca:b7:8c:54:c1:6b:33:7f:77:82:d8:95:e1:05:ca: e2:0d:22:1d:86:fc:1c:c4:a4:cf:c6:bc:ab:ec:b8:2a:1e:4b: 04:7e:49:9c:8f:9d:98:58:9c:63:c5:97:b5:41:94:f7:ef:93: 57:29
証明書：データ：バージョン：3（0x2の）シリアル番号：0（0x0の）署名アルゴリズム：sha1WithRSAEncryption発行者：CN =例発行ホスト、DC =例、DC = comのは、有効性の前ではなく：3月11日午前9時01分39秒2011 GMTありません後：3月21日9時01分39秒2011 GMT件名：CN =例対象ホスト、DC =例、DC = comのサブジェクト公開鍵情報：公開鍵アルゴリズム：rsaEncryption RSA公開鍵：（1024ビット）モジュラス（1024ビット）： 00：C0：DB：38：50：8E：63：ED：96：EA：C6：C4：EC：A3：36：62：E2：28：E9：74：9C：F5：2F：CB：58： 0E：52：54：60：B5：FA：98：87：0D：22：AB：D8：6A：61：74：A9：EE：0B：AE：CD：18：6F：05：AB：69： 66：42：46：00：A2：C0：0C：3A：28：67：09：CC：52：27：DA：79：3E：67：D7：D8：D0：7C：F1：A1：26： FA：38：8F：73：F5：B0：20：C6：F2：0B：7D：77：43：AA：C7：98：91：7E：1E：04：31：0D：CA：94：55： 20：C4：4F：BA：B1：DF：D4：61：9D：DD：B9：B5：47：94：6C：06：91：69：30：42：9C：0A：8B：E3：00： CE：49：AB：E3の指数：65537（0x10001）書X509v3拡張子：書X509v3発行者代替名：IPアドレス：2001：13：8d83：41c5：dc9f：38ed：e742：7281書X509v3のサブジェクトの別名：IPアドレス：2001：1C ：6e02：d3e0：9b90：8417：673e：99デシベル署名アルゴリズム：sha1WithRSAEncryption 83：68：B4：38：63：A6：AE：57：68：E2：4D：73：5D：8F：11：E4：BA：30：A0：19：CA：86：22： E9：6B：E9：36：96：AF：95：BD：E8：02：B9：72：2F：30：A2：62：AC：B2：FA：3D：25：C5：24：FD：8D： 32：AA：01：4F：A5：8A：F5：06：52：56：0A：86：55：39：2B：EE：7A：7B：46：14：D7：5D：15：82：4D： 74：06：CA：B7：8C：54：C1：6B：33：7F：77：82：D8：95：E1：05：CA：E2：0D：22：1D：86：FC：1C：C4： A4：CF：C6：BC：AB：EC：B8：2A：1E：4B：04：7E：49：9C：8F：9D：98：58：9C：63：C5：97：B5：41：94： F7：EF：93：57:29
Authors' Addresses
著者のアドレス
Tobias Heer Chair of Communication and Distributed Systems - COMSYS RWTH Aachen University Ahornstrasse 55 Aachen Germany
通信と分散システムのトビアスHeerさんチェア - コムシスアーヘン工科大学Ahornstrasse 55アーヘンドイツ
Phone: +49 241 80 20 776 EMail: heer@cs.rwth-aachen.de URI: http://www.comsys.rwth-aachen.de/team/tobias-heer/
電話：+49 241 80 20 776 Eメール：heer@cs.rwth-aachen.de URI：http://www.comsys.rwth-aachen.de/team/tobias-heer/
Samu Varjonen Helsinki Institute for Information Technology Gustaf Haellstroemin katu 2b Helsinki Finland
ヘルシンキフィンランド2bの情報技術グスタフHaellstroeminストリート用Varjonen Samuヘルシンキ研究所
EMail: samu.varjonen@hiit.fi URI: http://www.hiit.fi
電子メール：samu.varjonen@hiit.fi URI：http://www.hiit.fi