RFC2538 日本語訳

Network Working Group                                        D. Eastlake
Request for Comments: 2538                                           IBM
Category: Standards Track                                 O. Gudmundsson
                                                                TIS Labs
                                                              March 1999

コメントを求めるワーキンググループD.イーストレークの要求をネットワークでつないでください: 2538年のIBMカテゴリ: 1999年の標準化過程O.グドムンソンのTIS研究室行進

          Storing Certificates in the Domain Name System (DNS)

ドメインネームシステムで証明書を保存します。(DNS)

Status of this Memo

この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 (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

Abstract

要約

   Cryptographic public key are frequently published and their
   authenticity 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)でそのような証明書と関連する証明書失効リストを保存できるように定義されます。

Table of Contents

目次

   Abstract...................................................1
   1. Introduction............................................2
   2. The CERT Resource Record................................2
   2.1 Certificate Type Values................................3
   2.2 Text Representation of CERT RRs........................4
   2.3 X.509 OIDs.............................................4
   3. Appropriate Owner Names for CERT RRs....................5
   3.1 X.509 CERT RR Names....................................5
   3.2 PGP CERT RR Names......................................6
   4. Performance Considerations..............................6
   5. IANA Considerations.....................................7
   6. Security Considerations.................................7
   References.................................................8
   Authors' Addresses.........................................9
   Full Copyright Notice.....................................10

要約…1 1. 序論…2 2. 本命リソース記録…2 2.1 タイプ値を証明してください…3 2.2 本命RRsのテキスト表現…4 2.3X.509 OIDs…4 3. 本命RRsのために所有者名を当ててください…5 3.1 X.509本命RR名…5 3.2 PGP本命RR名…6 4. パフォーマンス問題…6 5. IANA問題…7 6. セキュリティ問題…7つの参照箇所…8人の作者のアドレス…9の完全な版権情報…10

Eastlake & Gudmundsson      Standards Track                     [Page 1]

RFC 2538            Storing Certificates in the DNS           March 1999

1999年3月にDNSの証明書を保存するイーストレークとグドムンソン標準化過程[1ページ]RFC2538

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 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 PGP
   certificates/revocations used by PGP software.

公開鍵は証明書の形で頻繁に発行されます、そして、証明書と関連する証明書失効リスト(CRLs)によってそれらの信憑性は一般的に示されます。 証明書は結合です、公開鍵か正当性間隔、そして/または、状態と、アイデンティティか、承認か、他の情報の暗号のデジタル署名で。 証明書失効リストは取り消される証明書、および付帯的な情報(取り消された証明書の署名者(発行人)によって署名されるすべて)のリストです。 例はPGPソフトウェアによって使用されるX.500ディレクトリシステムかPGP証明書/取消しでX.509証明書/CRLsです。

   Section 2 below specifies a CERT resource record (RR) for the storage
   of certificates in the Domain Name System.

セクション2 以下では、ドメインネームシステムにおける、証明書のストレージのためのCERTリソース記録(RR)は指定します。

   Section 3 discusses appropriate owner names for CERT RRs.

セクション3はCERT RRsのために適切な所有者名について論じます。

   Sections 4, 5, and 6 below cover performance, IANA, and security
   considerations, respectively.

以下のセクション4、5、および6はそれぞれ性能、IANA、およびセキュリティ問題を含んでいます。

   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 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

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 define in section 2.1
   below.

セクションで2.1未満を定義するとき、タイプ分野は証明書タイプです。

   The algorithm field has the same meaning as the algorithm field in
   KEY and SIG RRs [RFC 2535] except that a zero algorithm field
   indicates the algorithm is unknown to a secure DNS, which may simply
   be the result of the algorithm not having been standardized for
   secure DNS.

アルゴリズム分野には、アルゴリズムがさばくゼロが、単に安全なDNSのために標準化されていないアルゴリズムの結果であるかもしれない安全なDNSにおいて、アルゴリズムが未知であることを示すのを除いて、KEYとSIG RRs[RFC2535]のアルゴリズム分野と同じ意味があります。

Eastlake & Gudmundsson      Standards Track                     [Page 2]

RFC 2538            Storing Certificates in the DNS           March 1999

1999年3月にDNSの証明書を保存するイーストレークとグドムンソン標準化過程[2ページ]RFC2538

   The key tag field is the 16 bit value computed for the key embedded
   in the certificate as specified in the DNSSEC Standard [RFC 2535].
   This field is used as an efficiency measure to 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 be examined. However, the key must always be transformed to the
   format it would have as the public key portion of a KEY RR before the
   key tag is computed.  This is only possible if the key is applicable
   to an algorithm (and limits such as key size limits) defined for DNS
   security.  If it is not, the algorithm field MUST BE zero and the tag
   field is meaningless and SHOULD BE zero.

キー・タグ分野はDNSSEC Standard[RFC2535]の指定されるとしての証明書に埋め込まれたキーのために計算された16ビットの値です。 どのCERT RRsを選ぶか効率測定が特定のキーに適切であるかもしれないようにこの分野は使用されています。 問題のキーのためにキー・タグについて計算できます、そして、次に、同じキー・タグがあるCERT RRsだけが調べられなければなりません。 しかしながら、キー・タグが計算される前にいつもキーをそれがKEY RRの公開鍵一部として持っている形式に変えなければなりません。 キーがDNSセキュリティのために定義されたアルゴリズム(そして、主要なサイズ限界などの限界)に適切である場合にだけ、これは可能です。 それがそうでないなら、アルゴリズム分野はゼロであるに違いありません、そして、タグ・フィールドは無意味、そして、SHOULD BEゼロです。

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 cert
        3   PGP      PGP cert
    4-252            available for IANA assignment
      253   URI      URI private
      254   OID      OID private
    255-65534        available for IANA assignment
    65535            reserved

簡略記憶証明書タイプを評価してください。----- -------- ----------- ---- 0 IANA課題65535に利用可能な個人的な254OID OID個人的な255-65534が予約したIANA課題253URI URIに手があいているPKIX2SPKI SPKI本命3PGP PGP本命4-252に従って予約された1PKIX X.509

   The PKIX type is reserved to indicate an X.509 certificate conforming
   to the profile being defined by the IETF PKIX working group.  The
   certificate section will start with a one byte unsigned OID length
   and then an X.500 OID indicating the nature of the remainder of the
   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
   not include their X.500 directory type designating OID as a prefix.)

PKIXタイプは、IETF PKIXワーキンググループによって定義されるプロフィールに一致しているX.509証明書を示すために予約されます。 証明書部分は、1バイトの未署名のOIDの長さから始まって、次に、証明書部分の残りの本質を示すX.500 OIDから始まるでしょう(2.3未満を見てください)。 (注意: X.509証明書は接頭語としてOIDを指定する彼らのX.500ディレクトリタイプを含んでいません。)

   The SPKI type is reserved to indicate a certificate formated as to be
   specified by the IETF SPKI working group.

SPKIタイプは、IETF SPKIワーキンググループによって指定されるほど証明書がformatedされたのを示すために予約されます。

   The PGP type indicates a Pretty Good Privacy certificate as described
   in RFC 2440 and its extensions and successors.

PGPタイプはそのRFC2440、拡大、および後継者で説明されるようにプリティ・グッド・プライバシ証明書を示します。

   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 [RFC 2396] 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

URIの個人的なタイプは絶対URIによって定義された証明書書式を示します。 ヌルが個人的な形式証明書自体であった後にCERT RR MUSTの証明書部分はヌル終えられたURI[RFC2396]とデータで始まります。 URI SHOULDは、それからの検索がそうするためのそうです。証明書の形式に関するドキュメンテーションに通じてください。 個人的な証明書タイプの認識は、URI平等に基づく必要はありませんが、様々な形式のパターン・マッチングを使用できます。

Eastlake & Gudmundsson      Standards Track                     [Page 3]

RFC 2538            Storing Certificates in the DNS           March 1999

1999年3月にDNSの証明書を保存するイーストレークとグドムンソン標準化過程[3ページ]RFC2538

   so that, for example, subtype or version information can also be
   encoded into the URI.

それで、また、例えばそれ、「副-タイプ」またはバージョン情報をURIにコード化できます。

   The OID private type indicates a private format certificate specified
   by a an ISO OID prefix.  The certificate section will start with a
   one byte 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で接頭語を指定したのを示します。 OIDは証明書部分がコード化される1バイトの未署名のOIDの長さと次にBERから証明書部分の残りの本質を示し始めるでしょう。 これは、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
   integer or as a mnemonic symbol as listed in section 2.1 above.

CERT RRのRDATA部分には、符号のない整数として、または、上のセクション2.1で記載されている簡略記号としてタイプ分野があります。

   The key tag field is represented as an unsigned integer.

キー・タグ分野は符号のない整数として表されます。

   The algorithm field is represented as an unsigned integer or a
   mnemonic symbol as listed in [RFC 2535].

アルゴリズム分野は[RFC2535]に記載されている符号のない整数か簡略記号として表されます。

   The certificate / CRL portion is represented in base 64 and may be
   divided up 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で表されて、いろいろな余白の切り離されたサブストリングに分割されるかもしれません、単独ベース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. But 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における使用のための十六進法形式を前に置きました:

Eastlake & Gudmundsson      Standards Track                     [Page 4]

RFC 2538            Storing Certificates in the DNS           March 1999

1999年3月にDNSの証明書を保存するイーストレークとグドムンソン標準化過程[4ページ]RFC2538

    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 the use in DNS
   names of characters that require DNS quoting which is to use a
   backslash followed by the octal representation of the ASCII code for
   the character such as %%BODY%%00 for NULL.

以下のガイドラインのいくつかに従うと、NULLのための000円などのキャラクタのためにどれがバックスラッシュを使用することになっているかをASCIIコードの8進表現でいうことになったのを引用するDNSを必要とするキャラクタのDNS名における使用はもたらされるかもしれません。

3.1 X.509 CERT RR Names

3.1 X.509本命RR名

   Some X.509 versions permit multiple names to be associated with
   subjects and issuers under "Subject Alternate Name" and "Issuer
   Alternate Name".  For example, x.509v3 has such Alternate Names with
   an ASN.1 specification as follows:

いくつかのX.509バージョンが、複数の名前が「対象の別名称」と「発行人別名称」の下で対象と発行人に関連していることを許可します。 例えば、x.509v3には、ASN.1仕様は以下の通りでそのようなAlternate Namesがあります:

         GeneralName ::= CHOICE {
            otherName                  [0] INSTANCE OF OTHER-NAME,
            rfc822Name                 [1] IA5String,
            dNSName                    [2] IA5String,
            x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
            directoryName              [4] EXPLICIT Name,
            ediPartyName               [5] EDIPartyName,
            uniformResourceIdentifier  [6] IA5String,
            iPAddress                  [7] OCTET STRING,
            registeredID               [8] OBJECT IDENTIFIER
         }

GeneralName:、:= 選択他に名義のrfc822Name[1]IA5String、dNSName[2]IA5String(x400Addressの[3]の明白なOR-アドレス)、およびタイプのotherName[0]インスタンス、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ストレージのお勧めの位置は優先順で以下の通りです:

Eastlake & Gudmundsson      Standards Track                     [Page 5]

RFC 2538            Storing Certificates in the DNS           March 1999

1999年3月にDNSの証明書を保存するイーストレークとグドムンソン標準化過程[5ページ]RFC2538

   (1) If a domain name is included in the identification in the
       certificate or CRL, that should 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 should be used.
   (3) If neither of the above it used but a URI containing a domain
       name is present, that domain name should be used.
   (4) If none of the above is included but a character string name is
       included, then it should be treated as described for PGP names in
       3.2 below.
   (5) If none of the above apply, then the distinguished name (DN)
       should be mapped into a domain name as specified in RFC 2247.

(1) ドメイン名が証明書における識別に含まれているか、そして、CRL、それは使用されるべきです。 (2) ドメイン名が含まれていませんが、IPアドレスが含まれているなら、適切な逆さのドメイン名へのそのIPアドレスに関する翻訳は使用されるべきです。 (3) それが使用した上記のどちらも、ドメイン名を含むURIが存在しているなら、そのドメイン名は使用されるべきです。 (4) 上記のいずれも含まれていませんが、文字列名が含まれているなら、それは3.2未満におけるPGP名のために説明されるように扱われるべきです。 (5) 上記のいずれも適用されないなら、分類名(DN)はRFC2247の指定されるとしてのドメイン名に写像されるべきです。

   Example 1: Assume that 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/>.  Then
   the storage locations recommended, in priority order, would be
       (1) john-doe.com,
       (2) www.secure.john-doe.com, and
       (3) Doe.com.xy.

例1: X.509v3証明書がwww.secure.john-doe.com: (a) ストリング(b)のドメイン名の「ジョン(男性)・ドウ」、john- doe.com、および(c)uri<https://8080/>のSubject Alternative名で/CN=ジョン・ドウ/DC=ドウ/DC=com/DC=xy/O=ドウInc/C=XY/に発行されると仮定してください。そして、優先順で推薦された番地は、(1) john-doe.comと、(2) www.secure.john-doe.comと、(3)Doe.com.xyでしょう。

   Example 2:  Assume that 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>".  Then the storage locations
   recommended, in priority order, would be
        (1) widget.foo.example,
        (2) 201.13.251.10.in-addr.arpa, and
        (3) hacker.mail.widget.foo.example.

例2: X.509v3証明書が(a) ドメイン名widget.foo.exampleのSubject Alternate名で/CN=ジェームスHacker/L=ベイジングストーク/o=ウィジェットInc/C=GB/に発行されると仮定してください、(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と、(3)hacker.mail.widget.foo.exampleでしょう。

3.2 PGP CERT RR Names

3.2 PGP本命RR名

   PGP signed keys (certificates) use a general character string User ID
   [RFC 2440]. However, it is recommended by PGP that such names include
   the RFC 822 email address of the party, as in "Leslie Example
   <Leslie@host.example>".  If such a format is used, the CERT should be
   under the standard translation of the email address into a domain
   name, which would be leslie.host.example in this case.  If no RFC 822
   name can be extracted from the string name no specific domain name is
   recommended.

PGPは、キー(証明書)使用が一般的な文字列User ID[RFC2440]であると署名しました。 しかしながら、同じくらい中でそのような名前がパーティーのRFC822Eメールアドレスを含むことがPGPによって勧められる、「レスリー Example <Leslie@host.example 、gt;、」 そのような形式が使用されているなら、ドメイン名にはCERTがEメールアドレスの標準の翻訳であるはずです。(この場合それは、leslie.host.exampleでしょう)。 ストリング名からいいえをRFC822が命名する抜粋できるなら、どんな特定のドメイン名もお勧めではありません。

4. Performance Considerations

4. パフォーマンス問題

   Current Domain Name System (DNS) implementations are optimized for
   small transfers, typically not more than 512 bytes including
   overhead.  While larger transfers will perform correctly and work is

現在のドメインネームシステム(DNS)実装は小さい転送、通常オーバーヘッドを含まないどんな512バイト以上最適化されます。 より大きい転送は正しく働くでしょう、そして、仕事はそのように働きますが

Eastlake & Gudmundsson      Standards Track                     [Page 6]

RFC 2538            Storing Certificates in the DNS           March 1999

1999年3月にDNSの証明書を保存するイーストレークとグドムンソン標準化過程[6ページ]RFC2538

   underway to make larger transfers more efficient, it is still
   advisable at this time to make every reasonable effort to minimize
   the size of certificates stored within the DNS.  Steps that can be
   taken may include using the fewest possible optional or extensions
   fields and using short field values for variable length fields that
   must be included.

より大きい転送をより効率的にするように進行中です、DNSの中に保存された証明書のサイズを最小にするためのあらゆる妥当な努力をするのはこのとき、まだ賢明です。 取ることができる方法は、含まなければならない可変長フィールドに最もわずかな可能な任意であるか拡大分野と使用ショートの守備範囲値しか使用するのを含まないかもしれません。

5. IANA Considerations

5. IANA問題

   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
   only be assigned by an IETF standards action [RFC 2434] (and this
   document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
   Certificate types 0x0100 through 0xFEFF are assigned through IETF
   Consensus [RFC 2434] based on RFC documentation of the certificate
   type.  The availability of private types under 0x00FD and 0x00FE
   should satisfy most requirements for proprietary or private types.

IETF規格動作[RFC2434]で0xFFFFを通した0x00FFと0xFF00を通した証明書タイプ0x0000を選任できるだけです(このドキュメントは0×0001から0×0003、0x00FD、および0x00FEを割り当てます)。 0xFEFFを通した証明書タイプ0x0100は証明書タイプのRFCドキュメンテーションに基づくIETF Consensus[RFC2434]を通して選任されます。 0x00FDと0x00FEの下の個人的なタイプの有用性は独占であるか個人的なタイプのためのほとんどの要件を満たすべきです。

6. Security Considerations

6. セキュリティ問題

   By definition, certificates contain their own authenticating
   signature.  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セキュリティによって確かめられるなら、これがユーザの安全保障政策に従うなら証明書チェーンについて確かめないで、検索された証明書の中のキーは信じられるかもしれません。

   CERT RRs are not used in connection with securing the DNS security
   additions so there are no security considerations related to CERT RRs
   and securing the DNS itself.

CERT RRsはしたがって、あるDNSセキュリティ追加にCERT RRsに関連しないセキュリティ問題を全く保証して、DNS自身を固定することに関して使用されません。

Eastlake & Gudmundsson      Standards Track                     [Page 7]

RFC 2538            Storing Certificates in the DNS           March 1999

1999年3月にDNSの証明書を保存するイーストレークとグドムンソン標準化過程[7ページ]RFC2538

References

参照

   RFC 1034   Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, November 1987.

RFC1034Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   RFC 1035   Mockapetris, P., "Domain Names - Implementation and
              Specifications", STD 13, RFC 1035, November 1987.

RFC1035Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日

   RFC 2119   Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

RFC2119ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   RFC 2247   Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
              Sataluri, "Using Domains in LDAP/X.500 Distinguished
              Names", RFC 2247, January 1998.

RFC2247KilleとS.とウォールとM.とグリムスターとA.とヒューバーとR.とS.Sataluri、「LDAP/X.500分類名にドメインを使用します」、RFC2247、1998年1月。

   RFC 2396   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

RFC2396バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。

   RFC 2440   Callas, J., Donnerhacke, L., Finney, H. and R.  Thayer,
              "OpenPGP Message Format", RFC 2240, November 1998.

2440年のRFCカラスとJ.とDonnerhackeとL.とフィニーとH.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2240、1998年11月。

   RFC 2434   Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

RFC2434Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   RFC 2535   Eastlake, D., "Domain Name System (DNS) Security
              Extensions", RFC 2535, March 1999.

2535年のRFCイーストレーク、D.、「ドメインネームシステム(DNS)セキュリティ拡大」、RFC2535、1999年3月。

   RFC 2459   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and CRL
              Profile", RFC 2459, January 1999.

RFC2459HousleyとR.とフォードとW.とポークとW.と一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC2459、1999年1月。

Eastlake & Gudmundsson      Standards Track                     [Page 8]

RFC 2538            Storing Certificates in the DNS           March 1999

1999年3月にDNSの証明書を保存するイーストレークとグドムンソン標準化過程[8ページ]RFC2538

Authors' Addresses

作者のアドレス

   Donald E. Eastlake 3rd
   IBM
   65 Shindegan Hill Road
   RR#1
   Carmel, NY 10512 USA

カーメル、ドナルドE.イーストレーク3番目のIBM65Shindeganヒル道路RR#1ニューヨーク10512米国

   Phone:   +1-914-784-7913 (w)
            +1-914-276-2668 (h)
   Fax:     +1-914-784-3833 (w-fax)
   EMail:   dee3@us.ibm.com

以下に電話をしてください。 +1-914-784-7913 (w)+1-914-276-2668(h)Fax: +1-914-784-3833(w-ファックス)に、メールしてください: dee3@us.ibm.com

   Olafur Gudmundsson
   TIS Labs at Network Associates
   3060 Washington Rd, Route 97
   Glenwood MD 21738

ネットワーク関連3060ワシントンのOlafurグドムンソンTIS研究室、ルート97グレンウッド第Md21738

   Phone: +1 443-259-2389
   EMail: ogud@tislabs.com

以下に電話をしてください。 +1 443-259-2389 メールしてください: ogud@tislabs.com

Eastlake & Gudmundsson      Standards Track                     [Page 9]

RFC 2538            Storing Certificates in the DNS           March 1999

1999年3月にDNSの証明書を保存するイーストレークとグドムンソン標準化過程[9ページ]RFC2538

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Eastlake & Gudmundsson      Standards Track                    [Page 10]

イーストレークとグドムンソン標準化過程[10ページ]