RFC4398 日本語訳
4398 Storing Certificates in the Domain Name System (DNS). S.Josefsson. March 2006. (Format: TXT=35652 bytes) (Obsoletes RFC2538) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Josefsson Request for Comments: 4398 March 2006 Obsoletes: 2538 Category: Standards Track
Josefssonがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4398 2006年3月は以下を時代遅れにします。 2538年のカテゴリ: 標準化過程
Storing Certificates in the Domain Name System (DNS)
ドメインネームシステムで証明書を保存します。(DNS)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS).
暗号の公開鍵は頻繁に発行されます、そして、それらの信憑性は証明書によって示されます。 CERTリソース記録(RR)は、ドメインネームシステム(DNS)でそのような証明書と関連する証明書失効リストを保存できるように定義されます。
This document obsoletes RFC 2538.
このドキュメントはRFC2538を時代遅れにします。
Josefsson Standards Track [Page 1] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[1ページ]RFC4398
Table of Contents
目次
1. Introduction ....................................................3
2. The CERT Resource Record ........................................3
2.1. Certificate Type Values ....................................4
2.2. Text Representation of CERT RRs ............................6
2.3. X.509 OIDs .................................................6
3. Appropriate Owner Names for CERT RRs ............................7
3.1. Content-Based X.509 CERT RR Names ..........................8
3.2. Purpose-Based X.509 CERT RR Names ..........................9
3.3. Content-Based OpenPGP CERT RR Names ........................9
3.4. Purpose-Based OpenPGP CERT RR Names .......................10
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
4. Performance Considerations .....................................11
5. Contributors ...................................................11
6. Acknowledgements ...............................................11
7. Security Considerations ........................................12
8. IANA Considerations ............................................12
9. Changes since RFC 2538 .........................................13
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
Appendix A. Copying Conditions ...................................16
1. 序論…3 2. 本命リソース記録…3 2.1. タイプ値を証明してください…4 2.2. 本命RRsのテキスト表現…6 2.3. X.509 OIDs…6 3. 本命RRsのために所有者名を当ててください…7 3.1. 内容ベースのX.509本命RR名…8 3.2. 目的ベースのX.509本命RR名…9 3.3. 内容ベースのOpenPGP本命RR名…9 3.4. 目的ベースのOpenPGP本命RR名…10 3.5. IPKIX、ISPKI、IPGP、およびIACPKIXのための所有者名…10 4. パフォーマンス問題…11 5. 貢献者…11 6. 承認…11 7. セキュリティ問題…12 8. IANA問題…12 9. RFC2538以来の変化…13 10. 参照…14 10.1. 標準の参照…14 10.2. 有益な参照…15 付録A.コピー状態…16
Josefsson Standards Track [Page 2] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[2ページ]RFC4398
1. Introduction
1. 序論
Public keys are frequently published in the form of a certificate, and their authenticity is commonly demonstrated by certificates and related certificate revocation lists (CRLs). A certificate is a binding, through a cryptographic digital signature, of a public key, a validity interval and/or conditions, and identity, authorization, or other information. A certificate revocation list is a list of certificates that are revoked, and of incidental information, all signed by the signer (issuer) of the revoked certificates. Examples are X.509 certificates/CRLs in the X.500 directory system or OpenPGP certificates/revocations used by OpenPGP software.
公開鍵は証明書の形で頻繁に発行されます、そして、証明書と関連する証明書失効リスト(CRLs)によってそれらの信憑性は一般的に示されます。 証明書は結合です、公開鍵か正当性間隔、そして/または、状態と、アイデンティティか、承認か、他の情報の暗号のデジタル署名で。 証明書失効リストは取り消される証明書、および付帯的な情報(取り消された証明書の署名者(発行人)によって署名されるすべて)のリストです。 例はOpenPGPソフトウェアによって使用されるX.500ディレクトリシステムかOpenPGP証明書/取消しでX.509証明書/CRLsです。
Section 2 specifies a CERT resource record (RR) for the storage of certificates in the Domain Name System [1] [2].
セクション2はドメインネームシステム[1][2]での証明書のストレージのためのCERTリソース記録(RR)を指定します。
Section 3 discusses appropriate owner names for CERT RRs.
セクション3はCERT RRsのために適切な所有者名について論じます。
Sections 4, 7, and 8 cover performance, security, and IANA considerations, respectively.
セクション4、7、および8 それぞれ性能、セキュリティ、およびIANA問題を含んでください。
Section 9 explains the changes in this document compared to RFC 2538.
本書ではRFC2538と比べて、セクション9は変化について説明します。
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 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[3]で説明されるように本書では解釈されることであるべきですか?
2. The CERT Resource Record
2. 本命リソース記録
The CERT resource record (RR) has the structure given below. Its RR type code is 37.
CERTリソース記録(RR)で、構造を以下に与えます。 RRタイプコードは37です。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate or CRL /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| キー・タグ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アルゴリズム| / +---------------+ 証明書かCRL///++++++++++++++++++++++++++++++++、-|
The type field is the certificate type as defined in Section 2.1 below.
タイプ分野は以下のセクション2.1で定義されるように証明書タイプです。
The key tag field is the 16-bit value computed for the key embedded in the certificate, using the RRSIG Key Tag algorithm described in Appendix B of [12]. This field is used as an efficiency measure to
キー・タグ分野は証明書に埋め込まれたキーのために計算された16ビットの値です、[12]のAppendix Bで説明されたRRSIG Key Tagアルゴリズムを使用して。 この分野は効率測定として使用されます。
Josefsson Standards Track [Page 3] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[3ページ]RFC4398
pick which CERT RRs may be applicable to a particular key. The key tag can be calculated for the key in question, and then only CERT RRs with the same key tag need to be examined. Note that two different keys can have the same key tag. However, the key MUST be transformed to the format it would have as the public key portion of a DNSKEY RR before the key tag is computed. This is only possible if the key is applicable to an algorithm and complies to limits (such as key size) defined for DNS security. If it is not, the algorithm field MUST be zero and the tag field is meaningless and SHOULD be zero.
CERT RRsが適切であるかもしれないものに特定のキーを選んでください。 問題のキーのためにキー・タグを見込むことができます、そして、次に、同じキー・タグがあるCERT RRsだけが調べられる必要があります。 2個の異なったキーが同じキー・タグを持つことができることに注意してください。 しかしながら、キー・タグが計算される前にキーをそれがDNSKEY RRの公開鍵一部として持っている形式に変えなければなりません。 キーがアルゴリズムに適切であり、DNSセキュリティのために定義された限界(主要なサイズなどの)に応じる場合にだけ、これは可能です。 アルゴリズム分野がそれがそうでないなら、ゼロであるに違いなく、タグ・フィールドが無意味である、SHOULD、ゼロになってください。
The algorithm field has the same meaning as the algorithm field in DNSKEY and RRSIG RRs [12], except that a zero algorithm field indicates that the algorithm is unknown to a secure DNS, which may simply be the result of the algorithm not having been standardized for DNSSEC [11].
アルゴリズム分野はDNSKEYとRRSIG RRs[12]にアルゴリズム分野と同じ意味を持っています、アルゴリズムがさばくゼロが、単にDNSSEC[11]のために標準化されていないアルゴリズムの結果であるかもしれない安全なDNSにおいて、アルゴリズムが未知であることを示すのを除いて。
2.1. Certificate Type Values
2.1. 証明書タイプ値
The following values are defined or reserved:
以下の値は、定義されるか、または予約されます:
Value Mnemonic Certificate Type
----- -------- ----------------
0 Reserved
1 PKIX X.509 as per PKIX
2 SPKI SPKI certificate
3 PGP OpenPGP packet
4 IPKIX The URL of an X.509 data object
5 ISPKI The URL of an SPKI certificate
6 IPGP The fingerprint and URL of an OpenPGP packet
7 ACPKIX Attribute Certificate
8 IACPKIX The URL of an Attribute Certificate
9-252 Available for IANA assignment
253 URI URI private
254 OID OID private
255 Reserved
256-65279 Available for IANA assignment
65280-65534 Experimental
65535 Reserved
簡略記憶証明書タイプを評価してください。----- -------- ---------------- 0 IANA課題65280-65534Experimental65535ReservedのためのIANA課題253の個人的な254OID OID個人的な255URI URI Reserved256-65279AvailableのためのAttribute Certificate9-252AvailableのOpenPGPパケット7ACPKIX Attribute Certificate8IACPKIX URLのSPKI証明書6IPGPの指紋とURLのX.509データ・オブジェクト5ISPKI URLのPKIX2SPKI SPKI証明書3PGP OpenPGPパケット4IPKIX URLに従って予約された1PKIX X.509
These values represent the initial content of the IANA registry; see Section 8.
これらの値はIANA登録の初期の内容を表します。 セクション8を見てください。
The PKIX type is reserved to indicate an X.509 certificate conforming to the profile defined by the IETF PKIX working group [8]. The certificate section will start with a one-octet unsigned OID length and then an X.500 OID indicating the nature of the remainder of the
PKIXタイプは、IETF PKIXワーキンググループ[8]によって定義されたプロフィールに一致しているX.509証明書を示すために予約されます。 証明書部分は残りの本質を示す1八重奏の未署名のOIDの長さと次に、X.500 OIDから始まるでしょう。
Josefsson Standards Track [Page 4] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[4ページ]RFC4398
certificate section (see Section 2.3, below). (NOTE: X.509 certificates do not include their X.500 directory-type-designating OID as a prefix.)
セクションを証明してください(以下でセクション2.3を見てください)。 (注意: X.509証明書は接頭語としてそれらのX.500ディレクトリタイプ指定OIDを含んでいません。)
The SPKI and ISPKI types are reserved to indicate the SPKI certificate format [15], for use when the SPKI documents are moved from experimental status. The format for these two CERT RR types will need to be specified later.
SPKIとISPKIタイプはSPKI証明書書式[15]を示すために予約されます、SPKIドキュメントが実験状態から動かされるときの使用のために。 これらの2つのCERT RRタイプのための形式は、後で指定される必要があるでしょう。
The PGP type indicates an OpenPGP packet as described in [5] and its extensions and successors. This is used to transfer public key material and revocation signatures. The data is binary and MUST NOT be encoded into an ASCII armor. An implementation SHOULD process transferable public keys as described in Section 10.1 of [5], but it MAY handle additional OpenPGP packets.
PGPタイプはその[5]、拡大、および後継者で説明されるようにOpenPGPパケットを示します。 これは、公開鍵の材料と取消し署名を移すのに使用されます。 データは、2進であり、ASCIIよろいかぶとにコード化されてはいけません。 SHOULDが移転可能な公開鍵を処理する実装が[5]のセクション10.1で説明されて、それだけが追加OpenPGPパケットを扱うかもしれません。
The ACPKIX type indicates an Attribute Certificate format [9].
ACPKIXタイプはAttribute Certificate書式[9]を示します。
The IPKIX and IACPKIX types indicate a URL that will serve the content that would have been in the "certificate, CRL, or URL" field of the corresponding type (PKIX or ACPKIX, respectively).
IPKIXとIACPKIXタイプは対応するタイプ(それぞれPKIXかACPKIX)の「証明書、CRL、またはURL」分野にあった内容に役立つURLを示します。
The IPGP type contains both an OpenPGP fingerprint for the key in question, as well as a URL. The certificate portion of the IPGP CERT RR is defined as a one-octet fingerprint length, followed by the OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is calculated as defined in RFC 2440 [5]. A zero-length fingerprint or a zero-length URL are legal, and indicate URL-only IPGP data or fingerprint-only IPGP data, respectively. A zero-length fingerprint and a zero-length URL are meaningless and invalid.
IPGPタイプは問題のキーのためのOpenPGP指紋と1つのURLの両方を含んでいます。 IPGP CERT RRの証明書部分はURLがあとに続いたOpenPGP指紋が支えた1八重奏の指紋の長さと定義されます。 OpenPGP指紋はRFC2440[5]で定義されるように計算されます。 ゼロ・レングス指紋かゼロ・レングスURLが、法的であり、それぞれURLだけIPGPデータか指紋だけIPGPデータを示します。 ゼロ・レングス指紋とゼロ・レングスURLは、無意味であって、無効です。
The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect". These types MUST be used when the content is too large to fit in the CERT RR and MAY be used at the implementer's discretion. They SHOULD NOT be used where the DNS message is 512 octets or smaller and could thus be expected to fit a UDP packet.
IPKIX、ISPKI、IPGP、およびIACPKIXタイプは「間接的である」として知られています。 これらのタイプは、内容がCERT RRをうまくはめ込むことができないくらい大きいときに、使用しなければならなくて、implementerの裁量に使用されるかもしれません。 それら、SHOULD NOTをDNSメッセージが512の八重奏か、より小さいところで使用して、その結果、UDPパケットに合うと予想できました。
The URI private type indicates a certificate format defined by an absolute URI. The certificate portion of the CERT RR MUST begin with a null-terminated URI [10], and the data after the null is the private format certificate itself. The URI SHOULD be such that a retrieval from it will lead to documentation on the format of the certificate. Recognition of private certificate types need not be based on URI equality but can use various forms of pattern matching so that, for example, subtype or version information can also be encoded into the URI.
URIの個人的なタイプは絶対URIによって定義された証明書書式を示します。 CERT RR MUSTの証明書部分はヌルで終えられたURI[10]で始まります、そして、ヌルが個人的な形式であった後にデータはそれ自体を証明します。 URI SHOULDは、それからの検索がそうするためのそうです。証明書の形式に関するドキュメンテーションに通じてください。 個人的な証明書タイプの認識は、例えば、また、「副-タイプ」かバージョン情報をURIにコード化できるようにURI平等に基づく必要はありませんが、様々な形式のパターン・マッチングを使用できます。
Josefsson Standards Track [Page 5] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[5ページ]RFC4398
The OID private type indicates a private format certificate specified by an ISO OID prefix. The certificate section will start with a one-octet unsigned OID length and then a BER-encoded OID indicating the nature of the remainder of the certificate section. This can be an X.509 certificate format or some other format. X.509 certificates that conform to the IETF PKIX profile SHOULD be indicated by the PKIX type, not the OID private type. Recognition of private certificate types need not be based on OID equality but can use various forms of pattern matching such as OID prefix.
OIDの個人的なタイプは、個人的な形式証明書がISO OID接頭語で指定したのを示します。 証明書部分は、1八重奏の未署名のOIDの長さから始まって、次に、証明書部分の残りの本質を示すBERによってコード化されたOIDから始まるでしょう。 これは、X.509証明書形式かある他の形式であるかもしれません。 IETF PKIXプロフィールSHOULDに一致しているX.509証明書がPKIXタイプによって示されて、いずれのOID兵卒もタイプしません。 個人的な証明書タイプの認識は、OID平等に基づく必要はありませんが、様々な形式のOID接頭語などのパターン・マッチングを使用できます。
2.2. Text Representation of CERT RRs
2.2. 本命RRsのテキスト表現
The RDATA portion of a CERT RR has the type field as an unsigned decimal integer or as a mnemonic symbol as listed in Section 2.1, above.
CERT RRのRDATA部分には、タイプ分野が未署名の10進整数やセクション2.1に記載されている簡略記号のようにあります、上です。
The key tag field is represented as an unsigned decimal integer.
キー・タグ分野は未署名の10進整数として表されます。
The algorithm field is represented as an unsigned decimal integer or a mnemonic symbol as listed in [12].
アルゴリズム分野は未署名の10進整数か[12]に記載されている簡略記号として表されます。
The certificate/CRL portion is represented in base 64 [16] and may be divided into any number of white-space-separated substrings, down to single base-64 digits, which are concatenated to obtain the full signature. These substrings can span lines using the standard parenthesis.
証明書/CRL部分は、ベース64[16]に表されて、いろいろな切り離された白いスペースサブストリングに分割されるかもしれません、ただ一つのベース-64ケタまで。(ケタは、完全な署名を得るために連結されます)。 標準の挿入句を使用することでこれらのサブストリングは系列にかかることができます。
Note that the certificate/CRL portion may have internal sub-fields, but these do not appear in the master file representation. For example, with type 254, there will be an OID size, an OID, and then the certificate/CRL proper. However, only a single logical base-64 string will appear in the text representation.
証明書/CRL部分には内部のサブ分野があるかもしれませんが、これらが基本ファイル表現では現れないことに注意してください。 例えば、タイプ254で、適切なOIDサイズ、OID、および次に証明書/CRLがあるでしょう。 しかしながら、ただ一つの論理的なベース-64ストリングだけがテキスト表現に現れるでしょう。
2.3. X.509 OIDs
2.3. X.509 OIDs
OIDs have been defined in connection with the X.500 directory for user certificates, certification authority certificates, revocations of certification authority, and revocations of user certificates. The following table lists the OIDs, their BER encoding, and their length-prefixed hex format for use in CERT RRs:
OIDsはユーザー証明書のためのX.500ディレクトリ、証明権威証明書、証明権威、およびユーザー証明書の取消しの取消しに関して定義されました。 以下のテーブルはOIDs、彼らのBERコード化、およびCERT RRsにおける使用のための彼らの長さで前に置かれた十六進法書式を記載します:
Josefsson Standards Track [Page 6] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[6ページ]RFC4398
id-at-userCertificate
= { joint-iso-ccitt(2) ds(5) at(4) 36 }
== 0x 03 55 04 24
id-at-cACertificate
= { joint-iso-ccitt(2) ds(5) at(4) 37 }
== 0x 03 55 04 25
id-at-authorityRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 38 }
== 0x 03 55 04 26
id-at-certificateRevocationList
= { joint-iso-ccitt(2) ds(5) at(4) 39 }
== 0x 03 55 04 27
certificateRevocationListの0x03 55 04 26(4)38のcACertificateの0x03 55 04 24(4)36の共同iso-ccitt(2) ds(5)のuserCertificateのイド==イドの共同authorityRevocationListの0x03 55 04 25(4)37の共同iso-ccitt(2) ds(5)の==イド=iso-ccitt(2) ds(5)=イドは(4)39の共同iso-ccitt(2) ds(5)=0x03 55 04 27と等しいです。
3. Appropriate Owner Names for CERT RRs
3. 本命RRsのための適切な所有者名
It is recommended that certificate CERT RRs be stored under a domain name related to their subject, i.e., the name of the entity intended to control the private key corresponding to the public key being certified. It is recommended that certificate revocation list CERT RRs be stored under a domain name related to their issuer.
証明書CERT RRsが彼らの対象に関連するドメイン名の下で保存されるのは、お勧めです、すなわち、公認されていて、公開鍵に対応する秘密鍵を制御することを意図する実体の名前。 証明書取消しリストCERT RRsが彼らの発行人に関連するドメイン名の下で保存されるのは、お勧めです。
Following some of the guidelines below may result in DNS names with characters that require DNS quoting as per Section 5.1 of RFC 1035 [2].
以下のガイドラインのいくつかに従うと、RFCのセクション5.1に従って1035[2]を引用するDNSを必要とするキャラクタのDNS名はもたらされるかもしれません。
The choice of name under which CERT RRs are stored is important to clients that perform CERT queries. In some situations, the clients may not know all information about the CERT RR object it wishes to retrieve. For example, a client may not know the subject name of an X.509 certificate, or the email address of the owner of an OpenPGP key. Further, the client might only know the hostname of a service that uses X.509 certificates or the Key ID of an OpenPGP key.
CERT質問を実行するクライアントにとって、CERT RRsが保存される名前の選択は重要です。 いくつかの状況で、クライアントはそれが検索したがっているCERT RRオブジェクトのすべての情報を知るかもしれないというわけではありません。 例えば、クライアントはX.509証明書の対象の名前、またはOpenPGPキーの所有者のEメールアドレスを知らないかもしれません。 さらに、クライアントはX.509証明書を使用するサービスのホスト名かOpenPGPキーのKey IDを知っているだけであるかもしれません。
Therefore, two owner name guidelines are defined: content-based owner names and purpose-based owner names. A content-based owner name is derived from the content of the CERT RR data; for example, the Subject field in an X.509 certificate or the User ID field in OpenPGP keys. A purpose-based owner name is a name that a client retrieving CERT RRs ought to know already; for example, the host name of an X.509 protected service or the Key ID of an OpenPGP key. The content-based and purpose-based owner name may be the same; for example, when a client looks up a key based on the From: address of an incoming email.
したがって、2つの所有者名前ガイドラインが定義されます: 内容ベースの所有者名と目的ベースの所有者名。 CERT RRデータの内容から内容ベースの所有者名を得ます。 例えば、X.509証明書のSubject分野かOpenPGPキーのUser ID分野。 目的ベースの所有者名はクライアントがCERT RRsを検索する場合既に知っているべきである名前です。 例えば、X.509のホスト名はサービスかOpenPGPキーのKey IDを保護しました。 内容ベースの、そして、目的ベースの所有者名は同じであるかもしれません。 クライアントが見上げるとき、例えば、キーはFrom:を基礎づけました。 入って来るメールのアドレス。
Implementations SHOULD use the purpose-based owner name guidelines described in this document and MAY use CNAME RRs at content-based owner names (or other names), pointing to the purpose-based owner name.
目的ベースの所有者名を示して、実装SHOULDはガイドラインという本書では説明された目的ベースの所有者名を使用して、内容ベースの所有者名(または、他の名前)にCNAME RRsを使用するかもしれません。
Josefsson Standards Track [Page 7] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[7ページ]RFC4398
Note that this section describes an application-based mapping from the name space used in a certificate to the name space used by DNS. The DNS does not infer any relationship amongst CERT resource records based on similarities or differences of the DNS owner name(s) of CERT resource records. For example, if multiple labels are used when mapping from a CERT identifier to a domain name, then care must be taken in understanding wildcard record synthesis.
このセクションが証明書で使用される名前スペースからDNSによって使用された名前スペースまでアプリケーションベースのマッピングについて説明することに注意してください。 DNSはCERTリソース記録のDNS所有者名の類似性か違いに基づくCERTリソース記録の中の少しの関係も推論しません。 例えば、CERT識別子からドメイン名まで写像するとき、複数のラベルが使用されているなら、ワイルドカード記録統合を理解しながら、注意を中に入れなければなりません。
3.1. Content-Based X.509 CERT RR Names
3.1. 内容ベースのX.509本命RR名
Some X.509 versions, such as the PKIX profile of X.509 [8], permit multiple names to be associated with subjects and issuers under "Subject Alternative Name" and "Issuer Alternative Name". For example, the PKIX profile has such Alternate Names with an ASN.1 specification as follows:
X.509[8]のPKIXプロフィールなどのいくつかのX.509バージョンが、複数の名前が「対象の代替名」と「発行人代替名」の下で対象と発行人に関連していることを許可します。 例えば、PKIXプロフィールには、ASN.1仕様は以下の通りでそのようなAlternate Namesがあります:
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }
GeneralName:、:= 選択otherName[0]OtherName、rfc822Name[1]IA5String、dNSName[2]IA5String、x400Address[3]ORAddress、directoryName[4]名、ediPartyName[5]EDIPartyName、uniformResourceIdentifier[6]IA5String、iPAddress[7]八重奏ストリング、registeredID[8]オブジェクト識別子
The recommended locations of CERT storage are as follows, in priority order:
CERTストレージのお勧めの位置は優先順で以下の通りです:
1. If a domain name is included in the identification in the
certificate or CRL, that ought to be used.
2. If a domain name is not included but an IP address is included,
then the translation of that IP address into the appropriate
inverse domain name ought to be used.
3. If neither of the above is used, but a URI containing a domain
name is present, that domain name ought to be used.
4. If none of the above is included but a character string name is
included, then it ought to be treated as described below for
OpenPGP names.
5. If none of the above apply, then the distinguished name (DN)
ought to be mapped into a domain name as specified in [4].
1. ドメイン名が証明書における識別に含まれているか、そして、CRL、それは使用されるべきです。 2. ドメイン名が含まれていませんが、IPアドレスが含まれているなら、適切な逆さのドメイン名へのそのIPアドレスに関する翻訳は使用されるべきです。 3. 上記のどちらも使用されていませんが、ドメイン名を含むURIが存在しているなら、そのドメイン名は使用されるべきです。 4. 上記のいずれも含まれていませんが、文字列名が含まれているなら、それはOpenPGP名のために以下で説明されるように扱われるべきです。 5. 上記のいずれも適用されないなら、分類名(DN)は[4]の指定されるとしてのドメイン名に写像されるべきです。
Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/ DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a) string "John (the Man) Doe", (b) domain name john-doe.com, and (c) URI <https://www.secure.john-doe.com:8080/>. The storage locations recommended, in priority order, would be
例1: (a) ストリング(b)のドメイン名の「ジョン(男性)・ドウ」、john-doe.com、および(c)URI<https://www.secure.john-doe.comのSubject Alternative Namesと/CN=ジョン・ドウ/DC=ドウ/DC=com/DC=xy/O=ドウInc/C=XY/にX.509v3証明書を発行します: 8080/>優先順で推薦された番地はそうでしょう。
Josefsson Standards Track [Page 8] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[8ページ]RFC4398
1. john-doe.com, 2. www.secure.john-doe.com, and 3. Doe.com.xy.
1. john-doe.com、2www.secure.john-doe.com、および3。 Doe.com.xy。
Example 2: An X.509v3 certificate is issued to /CN=James Hacker/ L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a) domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and (c) string "James Hacker <hacker@mail.widget.foo.example>". The storage locations recommended, in priority order, would be
例2: (a) ドメイン名widget.foo.exampleのSubject Alternate名で/CN=ジェームスHacker/L=ベイジングストーク/o=ウィジェットInc/C=GB/にX.509v3証明書を発行します、(b)IPv4アドレス、10.251、.13、.201、(c)ストリング、「ジェームス Hacker <hacker@mail.widget.foo.example 、gt;、」 優先順で推薦された番地はそうでしょう。
1. widget.foo.example, 2. 201.13.251.10.in-addr.arpa, and 3. hacker.mail.widget.foo.example.
1. widget.foo.example、2。 addr.arpaの201.13.251.10.、および3hacker.mail.widget.foo.example。
3.2. Purpose-Based X.509 CERT RR Names
3.2. 目的ベースのX.509本命RR名
Due to the difficulty for clients that do not already possess a certificate to reconstruct the content-based owner name, purpose-based owner names are recommended in this section. Recommendations for purpose-based owner names vary per scenario. The following table summarizes the purpose-based X.509 CERT RR owner name guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
内容ベースの所有者名を再建するために既に証明書を持っていないクライアントのための困難のために、目的ベースの所有者名はこのセクションでお勧めです。 目的ベースの所有者名のための推薦はシナリオ単位で異なります。 以下のテーブルは使用のためにS/MIME[17]でガイドラインという目的ベースのX.509 CERT RR所有者名をまとめます、SSL/TLS[13]、およびIPsec[14]:
Scenario Owner name
------------------ ----------------------------------------------
S/MIME Certificate Standard translation of an RFC 2822 email
address. Example: An S/MIME certificate for
"postmaster@example.org" will use a standard
hostname translation of the owner name,
"postmaster.example.org".
シナリオOwner名------------------ ---------------------------------------------- RFC2822Eメールアドレスに関するS/MIME Certificate Standard翻訳。 例: " postmaster@example.org "のためのS/MIME証明書は所有者名、"postmaster.example.org"の標準のホスト名翻訳を使用するでしょう。
TLS Certificate Hostname of the TLS server.
TLSサーバのTLS Certificate Hostname。
IPsec Certificate Hostname of the IPsec machine and/or, for IPv4
or IPv6 addresses, the fully qualified domain
name in the appropriate reverse domain.
適切な逆のドメインのIPsecマシンのIPsec Certificate Hostname、そして/または、IPv4かIPv6アドレスのための完全修飾ドメイン名。
An alternate approach for IPsec is to store raw public keys [18].
IPsecのための代替のアプローチは生の公開鍵[18]を保存することです。
3.3. Content-Based OpenPGP CERT RR Names
3.3. 内容ベースのOpenPGP本命RR名
OpenPGP signed keys (certificates) use a general character string User ID [5]. However, it is recommended by OpenPGP that such names include the RFC 2822 [7] email address of the party, as in "Leslie Example <Leslie@host.example>". If such a format is used, the CERT ought to be under the standard translation of the email address into
OpenPGPは、キー(証明書)使用が一般的な文字列User ID[5]であると署名しました。 しかしながら、同じくらい中でそのような名前がパーティーのRFC2822[7]Eメールアドレスを含むことがOpenPGPによって勧められる、「レスリー Example <Leslie@host.example 、gt;、」 そのような形式が使用されているなら、CERTがEメールアドレスの標準の翻訳であるべきです。
Josefsson Standards Track [Page 9] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[9ページ]RFC4398
a domain name, which would be leslie.host.example in this case. If no RFC 2822 name can be extracted from the string name, no specific domain name is recommended.
ドメイン名。(この場合そのドメイン名はleslie.host.exampleでしょう)。 ストリング名からいいえをRFC2822が命名する抜粋できるなら、どんな特定のドメイン名もお勧めではありません。
If a user has more than one email address, the CNAME type can be used to reduce the amount of data stored in the DNS. For example:
ユーザに1つ以上のEメールアドレスがあるなら、DNSに保存されたデータ量を減少させるのにCNAMEタイプを使用できます。 例えば:
$ORIGIN example.org.
smith IN CERT PGP 0 0 <OpenPGP binary>
john.smith IN CNAME smith
js IN CNAME smith
$、ORIGIN example.org2進の鍛冶屋IN CERT PGP0 0john.smith IN CNAME鍛冶屋のjs IN CNAME<OpenPGP>鍛冶屋
3.4. Purpose-Based OpenPGP CERT RR Names
3.4. 目的ベースのOpenPGP本命RR名
Applications that receive an OpenPGP packet containing encrypted or signed data but do not know the email address of the sender will have difficulties constructing the correct owner name and cannot use the content-based owner name guidelines. However, these clients commonly know the key fingerprint or the Key ID. The key ID is found in OpenPGP packets, and the key fingerprint is commonly found in auxiliary data that may be available. In this case, use of an owner name identical to the key fingerprint and the key ID expressed in hexadecimal [16] is recommended. For example:
暗号化されたか署名しているデータを含むOpenPGPパケットを受けますが、送付者のEメールアドレスを知らないアプリケーションは、正しい所有者名を構成するのに苦労して、ガイドラインという内容ベースの所有者名を使用できません。 しかしながら、これらのクライアントは一般的に主要な指紋かKey IDを知っています。 主要なIDはOpenPGPパケットで見つけられます、そして、主要な指紋は利用可能であるかもしれない補助のデータで一般的に見つけられます。 この場合、16進[16]で急送された主要な指紋と主要なIDと同じ所有者名の使用はお勧めです。 例えば:
$ORIGIN example.org.
0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
F835EDA21E94B565716F IN CERT PGP ...
B565716F IN CERT PGP ...
$ORIGIN example.org。 本命PGPの…0424D4EE81A0E3D119C6F835EDA21E94B565716F 本命PGPの…F835EDA21E94B565716F 本命PGPの…B565716F
If the same key material is stored for several owner names, the use of CNAME may help avoid data duplication. Note that CNAME is not always applicable, because it maps one owner name to the other for all purposes, which may be sub-optimal when two keys with the same Key ID are stored.
同じ主要な材料がいくつかの所有者名のために保存されるなら、CNAMEの使用は、データ重複を避けるのを助けるかもしれません。 CNAMEがいつも適切であるというわけではないことに注意してください、すべての目的(同じKey IDがある2個のキーが保存されるとき、サブ最適であるかもしれない)のために1つの所有者名をもう片方に写像するので。
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
3.5. IPKIX、ISPKI、IPGP、およびIACPKIXのための所有者名
These types are stored under the same owner names, both purpose- and content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
これらのタイプは同じ所有者名、目的とPKIX、SPKI、PGP、およびACPKIXとしての内容ベースのタイプの両方の下に保存されます。
Josefsson Standards Track [Page 10] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[10ページ]RFC4398
4. Performance Considerations
4. パフォーマンス問題
The Domain Name System (DNS) protocol was designed for small transfers, typically below 512 octets. While larger transfers will perform correctly and work is underway to make larger transfers more efficient, it is still advisable at this time that every reasonable effort be made to minimize the size of certificates stored within the DNS. Steps that can be taken may include using the fewest possible optional or extension fields and using short field values for necessary variable-length fields.
ドメインネームシステム(DNS)プロトコルは小さい転送、通常512未満の八重奏のために設計されました。 より大きい転送は正しく働くでしょう、そして、仕事は、より大きい転送をより効率的にするように進行中ですが、DNSの中に保存された証明書のサイズを最小にするのをあらゆる妥当な努力をするのはこのとき、まだ賢明です。 取ることができる方法は、最もわずかな任意であるか拡大の可能な分野しか使用しないで、必要な可変長の分野にショートの守備範囲値を使用するのを含むかもしれません。
The RDATA field in the DNS protocol may only hold data of size 65535 octets (64kb) or less. This means that each CERT RR MUST NOT contain more than 64kb of payload, even if the corresponding certificate or certificate revocation list is larger. This document addresses this by defining "indirect" data types for each normal type.
DNSプロトコルのRDATA分野はサイズ65535以下の八重奏(64kb)に関するデータを保持するだけであるかもしれません。 これは、各CERT RR MUST NOTがペイロードの64kb以上を含むことを意味します、対応する証明書か証明書失効リストがさらに大きいなら。 このドキュメントは、各正常体型のために「間接的な」データ型を定義することによって、これを扱います。
Deploying CERT RRs to support digitally signed email changes the access patterns of DNS lookups from per-domain to per-user. If digitally signed email and a key/certificate lookup based on CERT RRs are deployed on a wide scale, this may lead to an increased DNS load, with potential performance and cache effectiveness consequences. Whether or not this load increase will be noticeable is not known.
CERT RRsをサポートする配布すると、DNSルックアップのアクセスパターンはメール変化にデジタルにドメインからユーザまで署名しました。 CERT RRsに基づくデジタルに署名しているメールとキー/証明書ルックアップが広大な規模で配布されるなら、これは増強されたDNS荷重に通じるかもしれません、潜在的性能とキャッシュ有効性結果で。 この負荷増加がめぼしくなるかどうかは知られていません。
5. Contributors
5. 貢献者
The majority of this document is copied verbatim from RFC 2538, by Donald Eastlake 3rd and Olafur Gudmundsson.
このドキュメントの大部分がドナルドイーストレーク3番目とOlafurグドムンソンによってRFC2538が逐語的に回避されます。
6. Acknowledgements
6. 承認
Thanks to David Shaw and Michael Graff for their contributions to earlier works that motivated, and served as inspiration for, this document.
それがインスピレーションとして動機づけて、機能した以前の作品への彼らの貢献をデヴィッド・ショーとマイケル・グラフをありがとうございます、とこれは記録します。
This document was improved by suggestions and comments from Olivier Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M. Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin, Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is incomplete. We apologize to anyone we left out.
このドキュメントはオリビエDubuisson、スコットHollenbeck、ラスHousley、ピーター・コッホ、オラフM.Kolkman、ベン・ローリー、エドワード・ルイス、ジョンLoughney、アリソン・マンキン、ダグラスオーティス、マルコス・サンス、ペッカSavola、ジェイソンSloderbeck、サミュエル・ウィーラー、およびフローリアンバイマーから提案とコメントで改良されました。 間違いなく、リストは不完全です。 私たちは省いた人はだれにも謝ります。
Josefsson Standards Track [Page 11] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[11ページ]RFC4398
7. Security Considerations
7. セキュリティ問題
By definition, certificates contain their own authenticating signatures. Thus, it is reasonable to store certificates in non-secure DNS zones or to retrieve certificates from DNS with DNS security checking not implemented or deferred for efficiency. The results may be trusted if the certificate chain is verified back to a known trusted key and this conforms with the user's security policy.
定義上、証明書は、それら自身が署名を認証するのを含んでいます。 したがって、非安全なDNSゾーンに証明書を保存するか、またはDNSセキュリティー検査が効率のために実装されないか、または延期されていなくDNSからの証明書を検索するのが妥当です。 証明書チェーンが知られている信じられたキーに確かめて戻されて、これがユーザの安全保障政策に従うなら、結果は信じられるかもしれません。
Alternatively, if certificates are retrieved from a secure DNS zone with DNS security checking enabled and are verified by DNS security, the key within the retrieved certificate may be trusted without verifying the certificate chain if this conforms with the user's security policy.
あるいはまた、証明書がDNSセキュリティー検査が可能にされている状態で安全なDNSゾーンから検索されて、DNSセキュリティによって確かめられるなら、これがユーザの安全保障政策に従うなら証明書チェーンについて確かめないで、検索された証明書の中のキーは信じられるかもしれません。
If an organization chooses to issue certificates for its employees, placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC) is in use, it is possible for someone to enumerate all employees of the organization. This is usually not considered desirable, for the same reason that enterprise phone listings are not often publicly published and are even marked confidential.
組織が、従業員(所有者名のDNSの置くCERT RRs)のために証明書を発行するのを選んで、DNSSEC(NSECと)が使用中であるなら、だれかが組織の全社員を数え上げるのは、可能です。 通常、これは望ましいと考えられません、企業電話リストがしばしば公的に発行されるというわけではなくて、秘密であるとマークさえされる同じ理由で。
Using the URI type introduces another level of indirection that may open a new vulnerability. One method of securing that indirection is to include a hash of the certificate in the URI itself.
URIタイプを使用すると、新しい脆弱性を開くかもしれない別のレベルの間接指定が導入されます。 その間接指定を保証する1つのメソッドはURI自体に証明書のハッシュを含むことです。
If DNSSEC is used, then the non-existence of a CERT RR and, consequently, certificates or revocation lists can be securely asserted. Without DNSSEC, this is not possible.
DNSSECが使用されているなら、しっかりとその結果CERT RRと、証明書か取消しリストの非存在について断言できます。 DNSSECがなければ、これは可能ではありません。
8. IANA Considerations
8. IANA問題
The IANA has created a new registry for CERT RR: certificate types. The initial contents of this registry is:
IANAはCERT RRのために新しい登録を作成しました: タイプを証明してください。 この登録の初期のコンテンツは以下の通りです。
Decimal Type Meaning Reference
------- ---- ------- ---------
0 Reserved RFC 4398
1 PKIX X.509 as per PKIX RFC 4398
2 SPKI SPKI certificate RFC 4398
3 PGP OpenPGP packet RFC 4398
4 IPKIX The URL of an X.509 data object RFC 4398
5 ISPKI The URL of an SPKI certificate RFC 4398
6 IPGP The fingerprint and URL RFC 4398
of an OpenPGP packet
7 ACPKIX Attribute Certificate RFC 4398
8 IACPKIX The URL of an Attribute RFC 4398
Certificate
10進タイプ意味参照------- ---- ------- --------- Attribute RFC4398CertificateのOpenPGPパケット7ACPKIX Attribute Certificate RFC4398 8IACPKIX URLのSPKI証明書RFC4398 6IPGPの指紋とURL RFC4398のX.509データ・オブジェクトRFC4398 5ISPKI URLのPKIX RFC4398 2SPKI SPKI証明書RFC4398 3PGP OpenPGPパケットRFC4398 4IPKIX URLに従って0の予約されたRFC、4398、1PKIX X.509。
Josefsson Standards Track [Page 12] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[12ページ]RFC4398
9-252 Available for IANA assignment
by IETF Standards action
253 URI URI private RFC 4398
254 OID OID private RFC 4398
255 Reserved RFC 4398
256-65279 Available for IANA assignment
by IETF Consensus
65280-65534 Experimental RFC 4398
65535 Reserved RFC 4398
9-252 IETF Standards動作253のURIのURIの個人的なRFC4398 254のOID OIDの個人的なRFC4398 255Reserved RFC4398 256-65279AvailableによるIANA課題に、IETF Consensus65280-65534Experimental RFC4398 65535Reserved RFC4398によるIANA課題において、利用可能です。
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can only be assigned by an IETF standards action [6]. This document assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate types 0x0100 through 0xFEFF are assigned through IETF Consensus [6] based on RFC documentation of the certificate type. The availability of private types under 0x00FD and 0x00FE ought to satisfy most requirements for proprietary or private types.
IETF規格動作[6]で0xFFFFを通した0x00FFと0xFF00を通した証明書タイプ0x0000を選任できるだけです。 このドキュメントは0×0001から0×0008、0x00FD、および0x00FEを割り当てます。 0xFEFFを通した証明書タイプ0x0100は証明書タイプのRFCドキュメンテーションに基づくIETF Consensus[6]を通して選任されます。 0x00FDと0x00FEの下の個人的なタイプの有用性は独占であるか個人的なタイプのためのほとんどの要件を満たすべきです。
The CERT RR reuses the DNS Security Algorithm Numbers registry. In particular, the CERT RR requires that algorithm number 0 remain reserved, as described in Section 2. The IANA will reference the CERT RR as a user of this registry and value 0, in particular.
CERT RRはDNS Security Algorithm民数記登録を再利用します。 特に、CERT RRは、セクション2で説明されるようにアルゴリズムNo.0が予約されていたままで残っているのを必要とします。 IANAは特にこの登録と価値0のユーザとしてCERT RRに参照をつけるでしょう。
9. Changes since RFC 2538
9. RFC2538以来の変化
1. Editorial changes to conform with new document requirements,
including splitting reference section into two parts and
updating the references to point at latest versions, and to add
some additional references.
2. Improve terminology. For example replace "PGP" with "OpenPGP",
to align with RFC 2440.
3. In Section 2.1, clarify that OpenPGP public key data are binary,
not the ASCII armored format, and reference 10.1 in RFC 2440 on
how to deal with OpenPGP keys, and acknowledge that
implementations may handle additional packet types.
4. Clarify that integers in the representation format are decimal.
5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
terminology. Improve reference for Key Tag Algorithm
calculations.
6. Add examples that suggest use of CNAME to reduce bandwidth.
7. In Section 3, appended the last paragraphs that discuss
"content-based" vs "purpose-based" owner names. Add Section 3.2
for purpose-based X.509 CERT owner names, and Section 3.4 for
purpose-based OpenPGP CERT owner names.
8. Added size considerations.
9. The SPKI types has been reserved, until RFC 2692/2693 is moved
from the experimental status.
10. Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
1. 参照部を2つの部品に分割して、最新版を指し示すために参照をアップデートするのを含んでいて、新しいドキュメント要件に従って、いくつかの追加参照を加える編集の変化。 2. 用語を改良してください。 例えば、RFC2440に並ぶために"PGP"を"OpenPGP"に取り替えてください。 3. セクション2.1では、データがバイナリー、ASCIIの武具の形式でなく、RFC2440の10.1に参照をつけるOpenPGPキーに対処して、それを承認するために、実装が追加パケットタイプを扱うかもしれないそのOpenPGP公開鍵をはっきりさせてください。 4. はっきりさせてください。表現形式の整数は小数です。 5. DNSSECbis用語に並ぶためにKEY/SIGをDNSKEY/RRSIGなどに取り替えてください。 Key Tag Algorithm計算の参照を改良してください。 6. 帯域幅を減少させるためにCNAMEの使用を示す例を加えてください。 7. 追加して、セクション3では、最終はそれについて短い記事を書きます。「目的ベース」に対して「内容ベース」の所有者名について議論してください。 目的ベースのX.509 CERT所有者名のためにセクション3.2を加えて、目的ベースのOpenPGP CERT所有者名のためにセクション3.4を加えてください。 8. サイズ問題を加えました。 9. RFC2692/2693が実験状態から動かされるまで、予約されましたSPKIが、タイプする。 10. 間接的なタイプのIPKIX、ISPKI、IPGP、およびIACPKIXを加えました。
Josefsson Standards Track [Page 13] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[13ページ]RFC4398
11. An IANA registry of CERT type values was created.
11. CERTタイプ値のIANA登録は作成されました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
January 1998.
[4]Kille、S.、ウォール、M.、グリムスター、A.、ヒューバー、R.、およびS.Sataluri、「LDAP/X.500分類名にドメインを使用します」、RFC2247(1998年1月)。
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998.
[5] カラスとJ.とDonnerhackeとL.とフィニー、H.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[6]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[7] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[8]Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[9] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.
[9] ファレルとS.とR.Housley、「承認のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[10]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[11]はArendsします、R.、Austein、R.、ラーソン、M.、マッシー、D.、S.ローズと、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[12] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
Josefsson Standards Track [Page 14] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[14ページ]RFC4398
10.2. Informative References
10.2. 有益な参照
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[13] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[14] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999.
[15] エリソン、C.、フランツ、B.、ランプソン、B.、Rivest、R.、トーマス、B.、およびT.Ylonen、「SPKI証明書理論」、RFC2693(1999年9月)。
[16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[16]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[17]、RFC3851、2004年7月。
[18] Richardson, M., "A Method for Storing IPsec Keying Material in
DNS", RFC 4025, March 2005.
[18] リチャードソン、M.、「DNSで材料を合わせるIPsecを保存するためのメソッド」、RFC4025、2005年3月。
Josefsson Standards Track [Page 15] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[15ページ]RFC4398
Appendix A. Copying Conditions
付録A.コピー状態
Regarding the portion of this document that was written by Simon
Josefsson ("the author", for the remainder of this section), the
author makes no guarantees and is not responsible for any damage
resulting from its use. The author grants irrevocable permission to
anyone to use, modify, and distribute it in any way that does not
diminish the rights of anyone else to use, modify, and distribute it,
provided that redistributed derivative works do not contain
misleading author or version information. Derivative works need not
be licensed under similar terms.
サイモンJosefsson(このセクションの残りのための「作者」)によって書かれたこのドキュメントの一部に関して、作者は、保証を全くしないで、また使用から生じるどんな損害にも責任がありません。 作者は他の誰もそれを使用して、変更して、分配する権利を減少させないどんな方法でもそれを使用して、変更して、分配するために呼び戻せない許可をだれにも与えます、再配付された派生している作品が紛らわしい作者かバージョン情報を含んでいなければ。 派生している作品は同類項に基づき認可される必要はありません。
Author's Address
作者のアドレス
Simon Josefsson
サイモンJosefsson
EMail: simon@josefsson.org
メール: simon@josefsson.org
Josefsson Standards Track [Page 16] RFC 4398 Storing Certificates in the DNS February 2006
2006年2月にDNSの証明書を保存するJosefsson標準化過程[16ページ]RFC4398
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Josefsson Standards Track [Page 17]
Josefsson標準化過程[17ページ]
一覧
スポンサーリンク
