Network Working Group S. Santesson
Request for Comments: 4325 Microsoft
Updates: 3280 R. Housley
Category: Standards Track Vigil Security
December 2005
Network Working Group S. Santesson
Request for Comments: 4325 Microsoft
Updates: 3280 R. Housley
Category: Standards Track Vigil Security
December 2005
Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension
Internet X.509公钥基础设施管理局信息访问证书吊销列表（CRL）扩展
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document updates RFC 3280 by defining the Authority Information Access Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates.
本文档通过定义授权信息访问证书吊销列表（CRL）扩展来更新RFC 3280。RFC 3280使用相同的语法定义授权信息访问证书扩展。CRL扩展提供了一种发现和检索CRL颁发者证书的方法。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Authority Information Access CRL Extension ......................3
3. Security Considerations .........................................5
4. References ......................................................5
4.1. Normative References .......................................5
4.2. Informative References .....................................6
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Authority Information Access CRL Extension ......................3
3. Security Considerations .........................................5
4. References ......................................................5
4.1. Normative References .......................................5
4.2. Informative References .....................................6
RFC 3280 [PKIX1] specifies the validation of certification paths. One aspect involves the determination that a certificate has not been revoked, and one revocation checking mechanism is the Certificate Revocation List (CRL). CRL validation is also specified in RFC 3280, which involves the constructions of a valid certification path for the CRL issuer. Building a CRL issuer certification path from the signer of the CRL to a trust anchor is straightforward when the certificate of the CRL issuer is present in the certification path associated with the target certificate, but it can be complex in other situations.
RFC 3280[PKIX1]指定证书路径的验证。一个方面涉及确定证书未被吊销，一个吊销检查机制是证书吊销列表（CRL）。RFC 3280中还规定了CRL验证，这涉及为CRL颁发者构建有效的认证路径。当CRL颁发者的证书存在于与目标证书相关联的证书路径中时，从CRL的签名者到信任锚点构建CRL颁发者证书路径非常简单，但在其他情况下可能很复杂。
There are several legitimate scenarios where the certificate of the CRL issuer is not present, or easily discovered, from the target certification path. This can be the case when indirect CRLs are used, when the Certification Authority (CA) that issued the target certificate changes its certificate signing key, or when the CA employs separate keys for certificate signing and CRL signing.
有几个合法的场景，其中CRL颁发者的证书不存在，或者很容易从目标证书路径中发现。当使用间接CRL时，当颁发目标证书的证书颁发机构（CA）更改其证书签名密钥时，或者当CA使用单独的密钥进行证书签名和CRL签名时，都可能出现这种情况。
Methods of finding the certificate of the CRL issuer are currently available, such as through an accessible directory location or through use of the Subject Information Access extension in intermediary CA certificates.
查找CRL颁发者的证书的方法当前可用，例如通过可访问的目录位置或通过使用中间CA证书中的主题信息访问扩展。
Directory lookup requires existence and access to a directory that has been populated with all of the necessary certificates. The Subject Information Access extension, which supports building the CRL issuer certification path top-down (in the direction from the trust anchor to the CRL issuer), requires that some certificates in the CRL issuer certification path includes an appropriate Subject Information Access extension.
目录查找要求存在并访问已填充了所有必要证书的目录。主题信息访问扩展支持自上而下构建CRL颁发者认证路径（从信任锚点到CRL颁发者的方向），要求CRL颁发者认证路径中的某些证书包括适当的主题信息访问扩展。
RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths through the Authority Information Access extension, where the id-ad-caIssuers access method may specify one or more accessLocation fields that reference CA certificates associated with the certificate containing this extension.
RFC 3280[PKIX1]通过授权信息访问扩展提供了自底向上的证书路径发现，其中id ad caIssuers访问方法可以指定一个或多个访问位置字段，这些字段引用与包含此扩展的证书关联的CA证书。
This document enables the use of the Authority Information Access extension in CRLs, enabling a CRL checking application to use the access method (id-ad-caIssuers) to locate certificates that may be useful in the construction of a valid CRL issuer certification path to an appropriate trust anchor.
本文档支持在CRL中使用权限信息访问扩展，使CRL检查应用程序能够使用访问方法（id ad caIssuers）定位证书，这些证书可能有助于构建到适当信任锚的有效CRL颁发者证书路径。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This section defines the use of the Authority Information Access extension in a CRL. The syntax and semantics defined in RFC 3280 [PKIX1] for the certificate extensions are also used for the CRL extension.
本节定义了CRL中权限信息访问扩展的使用。RFC 3280[PKIX1]中为证书扩展定义的语法和语义也用于CRL扩展。
This CRL extension MUST NOT be marked critical.
此CRL扩展不能标记为关键。
This extension MUST be identified by the extension object identifier (OID) defined in RFC 3280 (1.3.6.1.5.5.7.1.1), and the AuthorityInfoAccessSyntax MUST be used to form the extension value. For convenience, the ASN.1 [X.680] definition of the Authority Information Access extension is repeated below.
此扩展必须由RFC 3280（1.3.6.1.5.5.7.1.1）中定义的扩展对象标识符（OID）标识，并且必须使用AuthorityInfoAccessSyntax来形成扩展值。为了方便起见，下面重复了ASN.1[X.680]对权限信息访问扩展的定义。
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
AuthorityInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF
AccessDescription
AuthorityInfoAccessSyntax ::= SEQUENCE SIZE (1..MAX) OF
AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
When present in a CRL, this extension MUST include at least one AccessDescription specifying id-ad-caIssuers as the accessMethod. Access method types other than id-ad-caIssuers MUST NOT be included. At least one instance of AccessDescription SHOULD specify an accessLocation that is an HTTP [HTTP/1.1] or Lightweight Directory Access Protocol [LDAP] Uniform Resource Identifier [URI].
当存在于CRL中时，此扩展必须至少包含一个AccessDescription，指定id ad caIssuers作为accessMethod。不得包括id ad caIssuers以外的访问方法类型。至少一个AccessDescription实例应指定一个accessLocation，该accessLocation是HTTP[HTTP/1.1]或轻型目录访问协议[LDAP]统一资源标识符[URI]。
Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to a certificate containing file. The certificate file MUST contain either a single Distinguished Encoding Rules (DER) [X.690] encoded certificate (indicated by the .cer file extension) or a collection of certificates (indicated by the .p7c file extension):
如果信息通过HTTP或FTP可用，则accessLocation必须是uniformResourceIdentifier，并且URI必须指向包含文件的证书。证书文件必须包含单个可分辨编码规则（DER）[X.690]编码证书（由.cer文件扩展名指示）或证书集合（由.p7c文件扩展名指示）：
.cer A single DER encoded certificate as specified in RFC 2585 [PKIX-CERT].
.cer RFC 2585[PKIX-CERT]中指定的单个DER编码证书。
.p7c A "certs-only" CMS message as specified in RFC 2797 [CMC].
.p7c RFC 2797[CMC]中规定的“仅证书”CMS消息。
Conforming applications that support HTTP or FTP for accessing certificates MUST be able to accept .cer files and SHOULD be able to accept .p7c files.
支持HTTP或FTP访问证书的一致性应用程序必须能够接受.cer文件，并且应该能够接受.p7c文件。
HTTP server implementations accessed via the URI SHOULD use the appropriate MIME content-type for the certificate containing file. Specifically, the HTTP server SHOULD use the content-type application/pkix-cert [PKIX-CERT] for a single DER encoded certificate and application/pkcs7-mime [CMC] for CMS certs-only (PKCS#7). Consuming clients may use the MIME type and file extension as a hint to the file content, but should not depend solely on the presence of the correct MIME type or file extension in the server response.
通过URI访问的HTTP服务器实现应该为包含文件的证书使用适当的MIME内容类型。具体地说，HTTP服务器应使用内容类型application/pkix cert[pkix-cert]作为单个DER编码证书，而application/pkcs7 mime[CMC]仅用于CMS证书（PKCS#7）。消费客户端可以使用MIME类型和文件扩展名作为文件内容的提示，但不应仅依赖于服务器响应中是否存在正确的MIME类型或文件扩展名。
When the accessLocation is a directoryName, the information is to be obtained by the application from whatever directory server is locally configured. When one CA public key is used to validate signatures on certificates and CRLs, the desired CA certificate is stored in the crossCertificatePair and/or cACertificate attributes as specified in [RFC2587]. When different public keys are used to validate signatures on certificates and CRLs, the desired certificate is stored in the userCertificate attribute as specified in [RFC2587]. Thus, implementations that support the directoryName form of accessLocation MUST be prepared to find the needed certificate in any of these three attributes. The protocol that an application uses to access the directory (e.g., DAP or LDAP) is a local matter.
当accessLocation是directoryName时，应用程序将从本地配置的任何目录服务器获取信息。当使用一个CA公钥验证证书和CRL上的签名时，所需的CA证书存储在[RFC2587]中指定的crossCertificatePair和/或cACertificate属性中。当使用不同的公钥验证证书和CRL上的签名时，所需的证书存储在[RFC2587]中指定的userCertificate属性中。因此，支持directoryName形式的accessLocation的实现必须准备好在这三个属性中的任何一个中找到所需的证书。应用程序用于访问目录的协议（如DAP或LDAP）是本地事务。
Where the information is available via LDAP, the accessLocation SHOULD be a uniformResourceIdentifier. The URI MUST specify a distingishedName and attribute(s) and MAY specify a host name (e.g., ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com? cACertificate;binary,crossCertificatePair;binary). Omitting the host name (e.g., ldap:///cn=example%20CA,dc=example,dc=com?cACertificate;binary) has the effect of specifying the use of whatever LDAP server is locally configured. The URI MUST list appropriate attribute descriptions for one or more attributes holding certificates or cross-certificate pairs.
如果信息通过LDAP可用，则accessLocation应该是uniformResourceIdentifier。URI必须指定distingishedName和属性，并可以指定主机名（例如。，ldap://ldap.example.com/cn=example%20CA，dc=example，dc=com？证书；二进制，交叉证书pair；二进制）。省略主机名（例如。，ldap:///cn=example%20CA，dc=example，dc=com？cACertificate；binary）具有指定使用本地配置的LDAP服务器的效果。URI必须为持有证书或交叉证书对的一个或多个属性列出适当的属性描述。
Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name.
实施者应考虑到可能存在多个同名的不相关CA和CRL发行者。
Implementers should be aware of risks involved if the Authority Information Access extensions of corrupted CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed.
如果损坏的CRL的授权信息访问扩展包含指向恶意代码的链接，则实施者应意识到所涉及的风险。实现者应该始终采取验证检索到的数据的步骤，以确保数据的格式正确。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2587] Boeyen, S., Howes, T., and P. Richard, "Internet X.509 Public Key Infrastructure: LDAPv2 Schema", RFC 2587, June 1999.
[RFC2587]Boeyen，S.，Howes，T.，和P.Richard，“互联网X.509公钥基础设施：LDAPv2模式”，RFC 25871999年6月。
[PKIX1] 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.
[PKIX1]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[HTTP/1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP/1.1]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯·李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[LDAP] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[LDAP]Wahl，M.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[PKIX-CERT] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[PKIX-CERT]Housley，R.和P.Hoffman，“Internet X.509公钥基础设施操作协议：FTP和HTTP”，RFC 25851999年5月。
[CMC] Myers, M., Liu, X., Schaad, J., and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
[CMC]Myers，M.，Liu，X.，Schaad，J.，和J.Weinstein，“CMS上的证书管理消息”，RFC 2797，2000年4月。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002), Information Technology - Abstract Syntax Notation One, 2002.
[X.680]ITU-T建议X.680（2002）| ISO/IEC 8824-1:2002），信息技术-抽象语法符号，2002年。
[X.690] ITU-T Recommendation X.690 Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997.
[X.690]ITU-T建议X.690信息技术——ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范，1997年。
Authors' Addresses
作者地址
Stefan Santesson Microsoft Tuborg Boulevard 12 2900 Hellerup Denmark
Stefan Santesson Microsoft Tuborg大道12 2900号Hellerup丹麦
EMail: stefans@microsoft.com
EMail: stefans@microsoft.com
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。