Network Working Group S. Josefsson
Request for Comments: 4398 March 2006
Obsoletes: 2538
Category: Standards Track
Network Working Group S. Josefsson
Request for Comments: 4398 March 2006
Obsoletes: 2538
Category: Standards Track
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（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).
加密公钥经常发布，其真实性由证书证明。定义证书资源记录（RR），以便将此类证书和相关证书吊销列表存储在域名系统（DNS）中。
This document obsoletes RFC 2538.
本文件废除RFC 2538。
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. 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
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.
公钥通常以证书的形式发布，其真实性通常通过证书和相关证书吊销列表（CRL）来证明。证书是通过加密数字签名对公钥、有效期间隔和/或条件以及身份、授权或其他信息的绑定。证书吊销列表是由已吊销证书的签名者（颁发者）签署的已吊销证书和附带信息的列表。例如X.500目录系统中的X.509证书/CRL或OpenPGP软件使用的OpenPGP证书/撤销。
Section 2 specifies a CERT resource record (RR) for the storage of certificates in the Domain Name System [1] [2].
第2节规定了用于在域名系统[1][2]中存储证书的证书资源记录（RR）。
Section 3 discusses appropriate owner names for CERT RRs.
第3节讨论了证书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.
第9节解释了本文件与RFC 2538相比的变化。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[3]中所述进行解释。
The CERT resource record (RR) has the structure given below. Its RR type code is 37.
证书资源记录（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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | key tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | /
+---------------+ certificate or 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
密钥标记字段是使用[12]附录B中所述的RRSIG密钥标记算法为嵌入在证书中的密钥计算的16位值。此字段用作效率度量，用于
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.
选择适用于特定密钥的证书RRs。可以为有问题的密钥计算密钥标签，然后只需要检查具有相同密钥标签的证书RRs。请注意，两个不同的键可以具有相同的键标记。但是，在计算密钥标记之前，必须将密钥转换为其作为DNSKEY RR的公钥部分的格式。只有当密钥适用于某个算法并且符合为DNS安全性定义的限制（如密钥大小）时，这才可能实现。如果不是，则算法字段必须为零，标记字段没有意义，应该为零。
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]中的算法字段相同，不同之处在于零算法字段表示安全DNS不知道该算法，这可能只是由于算法未针对DNSSEC标准化[11]。
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
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
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类型是为了表明X.509证书符合IETF PKIX工作组定义的配置文件[8]。证书部分将以一个八位字节无符号OID长度开始，然后是一个X.500 OID，指示证书剩余部分的性质
certificate section (see Section 2.3, below). (NOTE: X.509 certificates do not include their X.500 directory-type-designating OID as a prefix.)
certificate section (see Section 2.3, below). (NOTE: X.509 certificates do not include their X.500 directory-type-designating OID as a prefix.)translate error, please retry
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文档从实验状态移动时使用。这两种证书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数据包及其扩展和后续数据包。这用于传输公钥材料和撤销签名。数据是二进制的，不能被编码成ASCII格式。实现应该按照[5]第10.1节中的描述处理可转移公钥，但它可以处理额外的OpenPGP数据包。
The ACPKIX type indicates an Attribute Certificate format [9].
ACPKIX类型表示属性证书格式[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类型表示一个URL，该URL将为相应类型（分别为PKIX或ACPKIX）的“证书、CRL或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指纹，也包含URL。IPGP证书RR的证书部分定义为一个八位字节的指纹长度，后跟OpenPGP指纹，后跟URL。按照RFC 2440[5]中的定义计算OpenPGP指纹。零长度指纹或零长度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时，必须使用这些类型，并可由实施者自行决定使用。在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的证书部分必须以以null结尾的URI开头[10]，null后面的数据是私有格式证书本身。URI应该是这样的，从中检索将导致关于证书格式的文档。私有证书类型的识别不需要基于URI相等，但可以使用各种形式的模式匹配，以便（例如）子类型或版本信息也可以编码到URI中。
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前缀指定的私有格式证书。证书部分将以一个八位字节无符号OID长度开始，然后是一个BER编码OID，指示证书部分其余部分的性质。这可以是X.509证书格式或其他格式。符合IETF PKIX配置文件的X.509证书应以PKIX类型而不是OID专用类型表示。私有证书类型的识别不需要基于OID相等，但可以使用各种形式的模式匹配，如OID前缀。
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.
证书RR的RDATA部分的类型字段为无符号十进制整数或助记符，如上文第2.1节所列。
The key tag field is represented as an unsigned decimal integer.
键标记字段表示为无符号十进制整数。
The algorithm field is represented as an unsigned decimal integer or a mnemonic symbol as listed in [12].
算法字段表示为[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部分以base 64[16]表示，可以划分为任意数量的空格分隔的子字符串，直至单个base-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本身。但是，文本表示中将只显示一个逻辑base-64字符串。
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:
OID已结合X.500目录定义，用于用户证书、证书颁发机构证书、证书颁发机构撤销和用户证书撤销。下表列出了在CERT RRs中使用的OID、其BER编码及其长度前缀十六进制格式：
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
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
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.
建议将证书证书RRs存储在与其主题相关的域名下，即用于控制与被认证公钥对应的私钥的实体名称。建议将证书吊销列表证书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 1035[2]第5.1节，遵循以下一些指导原则可能会导致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.
选择用于存储证书RRs的名称对于执行证书查询的客户端非常重要。在某些情况下，客户端可能不知道它希望检索的CERT RR对象的所有信息。例如，客户端可能不知道X.509证书的使用者名称或OpenPGP密钥所有者的电子邮件地址。此外，客户端可能只知道使用X.509证书的服务的主机名或OpenPGP密钥的密钥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.
因此，定义了两个所有者名称准则：基于内容的所有者名称和基于目的的所有者名称。基于内容的所有者名称源自证书RR数据的内容；例如，X.509证书中的主题字段或OpenPGP密钥中的用户ID字段。基于目的的所有者名称是检索证书RRs的客户端应该已经知道的名称；例如，受保护密钥的主机名为pgx.50p。基于内容和基于目的的所有者名称可能相同；例如，当客户端根据传入电子邮件的发件人：地址查找密钥时。
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.
实施应使用本文档中描述的基于目的的所有者名称指南，并可在基于内容的所有者名称（或其他名称）处使用CNAME RRs，指向基于目的的所有者名称。
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不会根据证书资源记录的DNS所有者名称的相似性或差异推断证书资源记录之间的任何关系。例如，如果在从证书标识符映射到域名时使用多个标签，则必须注意理解通配符记录合成。
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版本，如X.509[8]的PKIX配置文件，允许在“主体备选名称”和“发行人备选名称”下与主体和发行人关联多个名称。例如，PKIX配置文件具有以下具有ASN.1规范的备用名称：
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 ::= 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 }
The recommended locations of CERT storage are as follows, in priority order:
建议的证书存储位置按优先级顺序如下：
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
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. john-doe.com, 2. www.secure.john-doe.com, and 3. Doe.com.xy.
1. john-doe.com，2。www.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
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
1. widget.foo.example, 2. 201.13.251.10.in-addr.arpa, and 3. hacker.mail.widget.foo.example.
1. widget.foo.example，2。201.13.251.10.in-addr.arpa和3。hacker.mail.widget.foo.example。
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]、SSL/TLS[13]和IPsec[14]的基于用途的X.509 CERT RR所有者名称指南：
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".
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".
TLS Certificate Hostname of the TLS server.
TLS服务器的TLS证书主机名。
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证书主机名和/或（对于IPv4或IPv6地址）相应反向域中的完全限定域名。
An alternate approach for IPsec is to store raw public keys [18].
IPsec的另一种方法是存储原始公钥[18]。
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签名密钥（证书）使用通用字符串用户ID[5]。然而，OpenPGP建议此类名称包括当事人的RFC 2822[7]电子邮件地址，如“Leslie示例”所示<Leslie@host.example>". 如果使用这种格式，证书应按照电子邮件地址的标准翻译为
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。如果无法从字符串名称中提取RFC 2822名称，则建议不要使用特定域名。
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:
如果用户有多个电子邮件地址，则可以使用CNAME类型来减少DNS中存储的数据量。例如：
$ORIGIN example.org. smith IN CERT PGP 0 0 <OpenPGP binary> john.smith IN CNAME smith js IN CNAME smith
$originexample.org。CERT PGP 0 0中的smith<OpenPGP binary>CNAME中的john.smith
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数据包的应用程序将难以构造正确的所有者名称，并且无法使用基于内容的所有者名称准则。但是，这些客户端通常知道密钥指纹或密钥ID。密钥ID可在OpenPGP数据包中找到，密钥指纹通常可在可用的辅助数据中找到。在这种情况下，建议使用与密钥指纹和十六进制[16]表示的密钥ID相同的所有者名称。例如：
$ORIGIN example.org. 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... F835EDA21E94B565716F IN CERT PGP ... B565716F IN CERT PGP ...
$originexample.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并不总是适用的，因为它将一个所有者名称映射到另一个所有者名称，这在存储具有相同密钥ID的两个密钥时可能是次优的。
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类型相同的所有者名称（基于目的和内容）存储。
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）或更小的数据。这意味着每个证书RR不能包含超过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查找的访问模式从每个域更改为每个用户。如果大规模部署数字签名电子邮件和基于证书RRs的密钥/证书查找，这可能会导致DNS负载增加，并带来潜在的性能和缓存有效性后果。目前还不知道负载是否会明显增加。
The majority of this document is copied verbatim from RFC 2538, by Donald Eastlake 3rd and Olafur Gudmundsson.
本文件的大部分内容是由Donald Eastlake 3rd和Olafur Gudmundsson从RFC 2538中逐字复制的。
Thanks to David Shaw and Michael Graff for their contributions to earlier works that motivated, and served as inspiration for, this document.
感谢Michael Graff的贡献，感谢Michael Graff的贡献，感谢Michael Graff的早期贡献。
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.
奥利维尔·杜布伊森、斯科特·霍伦贝克、罗斯·霍斯利、彼得·科赫、奥拉夫·M·科尔克曼、本·劳里、爱德华·刘易斯、约翰·拉夫尼、艾利森·曼金、道格拉斯·奥蒂斯、马科斯·桑兹、佩卡·萨沃拉、杰森·斯洛德贝克、塞缪尔·韦勒和弗洛里安·魏默的建议和评论对本文件进行了改进。毫无疑问，这份名单是不完整的。我们向遗漏的任何人道歉。
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中放置证书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类型会引入另一个间接级别，可能会打开新的漏洞。保护间接寻址的一种方法是在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，则可以安全地断言证书RR的不存在以及证书或吊销列表的不存在。没有DNSSEC，这是不可能的。
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
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
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标准行动253 URI URI专用RFC 4398 254 OID OID专用RFC 4398 255保留RFC 4398 256-65279可由IETF共识65280-65534实验RFC 4398 65535保留RFC 4398进行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.
证书类型0x0000到0x00FF和0xFF00到0xFFFF只能由IETF标准操作分配[6]。本文件分配0x0001至0x0008、0x00FD和0x00FE。根据证书类型的RFC文档，通过IETF共识[6]分配证书类型0x0100到0xFEFF。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安全算法编号注册表。具体而言，CERT RR要求保留算法编号0，如第2节所述。IANA将引用证书RR作为该注册表的用户，尤其是值0。
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.改进术语。例如，将“PGP”替换为“OpenPGP”，以与RFC 2440对齐。3.在第2.1节中，澄清OpenPGP公钥数据是二进制的，而不是ASCII铠装格式，并参考RFC 2440中关于如何处理OpenPGP密钥的10.1，并确认实现可能处理其他数据包类型。4.澄清表示格式中的整数是十进制的。5.用DNSKEY/RRSIG等替换键/SIG，以符合DNSSECbis术语。改进键标记算法计算的参考。6.添加建议使用CNAME减少带宽的示例。7.在第3节中，添加了讨论“基于内容”与“基于目的”所有者名称的最后几段。为基于目的的X.509证书所有者名称添加第3.2节，为基于目的的OpenPGP证书所有者名称添加第3.4节。8.增加了尺寸方面的考虑。9SPKI类型已保留，直到RFC 2692/2693从实验状态移动。10添加了间接类型IPKIX、ISPKI、IPGP和IACPKIX。
11. An IANA registry of CERT type values was created.
11. 已创建证书类型值的IANA注册表。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，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.，Wahl，M.，Grimstad，A.，Huber，R.，和S.Sataluri，“使用LDAP/X.500可分辨名称中的域”，RFC 2247，1998年1月。
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[5] Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“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注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[7] Resnick，P.，“互联网信息格式”，RFC 2822，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.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[9] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[9] Farrell，S.和R.Housley，“用于授权的互联网属性证书配置文件”，RFC 3281，2002年4月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[10] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，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.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[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.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[13] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[14] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[14] Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999.
[15] Ellison，C.，Frantz，B.，Lampson，B.，Rivest，R.，Thomas，B.，和T.Ylonen，“SPKI证书理论”，RFC 26931999年9月。
[16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[16] Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC3548，2003年7月。
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[17] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[18] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[18] Richardson，M.“在DNS中存储IPsec密钥材料的方法”，RFC 4025，2005年3月。
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.
关于本文件中由Simon Josefsson编写的部分（“作者”，本节剩余部分），作者不作任何保证，也不对因使用本文件而造成的任何损害负责。作者向任何人授予不可撤销的使用、修改和分发许可，允许其以任何方式使用、修改和分发，但不得削弱任何其他人使用、修改和分发的权利，前提是重新分发的衍生作品不包含误导性的作者或版本信息。衍生作品无需根据类似条款获得许可。
Author's Address
作者地址
Simon Josefsson
西蒙·约瑟夫森
EMail: simon@josefsson.org
EMail: simon@josefsson.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。