Network Working Group S. Farrell
Request for Comments: 5697 Trinity College Dublin
Category: Experimental November 2009
Network Working Group S. Farrell
Request for Comments: 5697 Trinity College Dublin
Category: Experimental November 2009
Other Certificates Extension
其他证书扩展
Abstract
摘要
Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit.
将状态信息与公钥证书关联的一些应用程序可以从将属于同一最终实体的一组证书链接在一起的方式中获益，并且为了引用该应用程序状态信息，可以安全地认为这些证书彼此等效。此备忘录定义了一个证书扩展，允许应用程序在不引入新的应用程序协议数据单元的情况下建立所需的链接。
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. A Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Other Certificates Extension . . . . . . . . . . . . . . . . . 3
4. Another Approach Using Permanent Identifiers . . . . . . . . . 5
5. A Possible Optimisation . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. A Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Other Certificates Extension . . . . . . . . . . . . . . . . . 3
4. Another Approach Using Permanent Identifiers . . . . . . . . . 5
5. A Possible Optimisation . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . 8
RFC 5280 [RFC5280] defines a profile for the use of public key certificates for Internet applications. If an application associates application-state information with a public key certificate, then that association may be disrupted if the end entity changes its public key certificate. Such disruption can occur due to renewals or if the end entity changes its certificate issuer. Similarly, if the end entity is actually a distributed system, where each instance has a different private key, then the relying party (RP) has no way to associate the different public key certificates with the relevant application-state information.
RFC 5280[RFC5280]定义了一个配置文件，用于在Internet应用程序中使用公钥证书。如果应用程序将应用程序状态信息与公钥证书关联，则如果最终实体更改其公钥证书，则该关联可能会中断。此类中断可能由于续签或最终实体更改其证书颁发者而发生。类似地，如果最终实体实际上是分布式系统，其中每个实例具有不同的私钥，则依赖方（RP）无法将不同的公钥证书与相关应用程序状态信息相关联。
For example, assume a web browser retains state information (perhaps passwords) about a web site, indexed (possibly indirectly) via values contained in the web server's public key certificate (perhaps a DNS name). When the web server certificate expires and a new certificate is acquired (perhaps with a different DNS name), then the browser cannot safely map the new certificate to the relevant state information.
例如，假设web浏览器保留有关网站的状态信息（可能是密码），并通过web服务器公钥证书（可能是DNS名称）中包含的值进行索引（可能是间接的）。当web服务器证书过期并获取新证书（可能具有不同的DNS名称）时，浏览器无法安全地将新证书映射到相关的状态信息。
This memo defines a new public key certificate extension that supports such linkage, allowing the certificate issuer to attest that the end entity that holds the private key for the certificate in question also holds other private keys corresponding to other identified certificates.
此备忘录定义了支持此类链接的新公钥证书扩展，允许证书颁发者证明持有所述证书私钥的最终实体也持有与其他已标识证书对应的其他私钥。
Other than the issuer asserting that the set of certificates belongs to the same end entity for use with the same application, the fine detail of the semantics of the linkage of certificates is not defined here, since that is a matter for application developers and the operators of certification authorities (CAs). In particular, we do not define how a CA can validate that the same end entity is the holder of the various private keys, nor how the application should
除了颁发者声明证书集属于用于同一应用程序的同一终端实体之外，这里没有定义证书链接语义的详细信息，因为这是应用程序开发人员和证书颁发机构（CA）操作员的事情。特别是，我们没有定义CA如何验证同一终端实体是各种私钥的持有者，也没有定义应用程序应该如何验证
make use of this information. Nor do we define what kinds of state information may be shared.
利用这些信息。我们也没有定义可以共享哪些类型的状态信息。
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]中所述进行解释。
Public key certificates expire, typically about a year after they are created. Some applications might need to know that the same entity is the subject of the current certificate and a previously used certificate.
公钥证书通常在创建后一年左右到期。某些应用程序可能需要知道同一实体是当前证书和以前使用的证书的主题。
For example, if a web server certificate expires, it could be useful for a web browser to know that the server currently presenting a certificate in a Transport Layer Security (TLS) [RFC5246] handshake represents the same web server that previously presented a certificate. This could be used, for example, to allow the browser to automatically fill in form fields for the server in question, even if the server certificate has been replaced. While the same effect can be achieved based on the use of the same issuer and subject fields in a certificate, there could be security issues involved in such comparisons, e.g., if the subject name includes a DNS name and the ownership of that DNS domain has changed.
例如，如果web服务器证书过期，则web浏览器可以知道当前在传输层安全性（TLS）[RFC5246]握手中提供证书的服务器表示先前提供证书的同一web服务器。例如，这可以用于允许浏览器自动填写相关服务器的表单字段，即使服务器证书已被替换。虽然基于在证书中使用相同的颁发者和主题字段可以实现相同的效果，但在此类比较中可能涉及安全问题，例如，如果主题名称包括DNS名称，并且该DNS域的所有权已更改。
The use of the new extension provides a way for the CA to signal to the application that the same end entity is involved, regardless of name changes. The new extension could also allow the web site operator to more easily change the CA when replacing its certificate.
新扩展的使用为CA向应用程序发出涉及相同终端实体的信号提供了一种方式，而不管名称如何更改。新的扩展还允许网站运营商在更换证书时更容易地更改CA。
This section defines the syntax for the other certificates extension.
本节定义了其他证书扩展的语法。
The new extension is simply a list of references to the linked certificates. The references make use of the SCVPCertID structure from the Server-Based Certificate Validation Protocol (SCVP) [RFC5055], which contains a hash over the relevant certificate and the certificate's issuer and serial number.
新的扩展只是链接证书的引用列表。这些引用使用了基于服务器的证书验证协议（SCVP）[RFC5055]中的SCVPCertID结构，该协议包含相关证书、证书的颁发者和序列号上的散列。
When this extension is present, the CA is asserting that the same end entity is the subject of the relevant certificates.
当存在此扩展时，CA断言相同的终端实体是相关证书的主体。
This extension MUST NOT be marked critical.
此扩展不能标记为关键。
id-pe-otherCerts OBJECT IDENTIFIER ::= { id-pe 19 }
id-pe-otherCerts OBJECT IDENTIFIER ::= { id-pe 19 }
OtherCertificates ::= SEQUENCE OF SCVPCertID
OtherCertificates ::= SEQUENCE OF SCVPCertID
CAs MUST only issue certificates containing this extension where the links created are such that the relevant consumers of the certificates can safely make use of those links. This will typically be the case where the certificates are only used by a single application. CAs MUST NOT issue certificates that link to certificates issued for a different purpose, for example, a CA SHOULD NOT link a web server certificate to a VPN gateway certificate (unless those can be the same, which might occur for some embedded devices). The purpose for which the certificate is intended may be determined by certificate policy or other means (e.g., extended key usage object identifiers) that are out of the scope of this specification.
CA必须仅在创建的链接能够使证书的相关使用者安全地使用这些链接的情况下颁发包含此扩展的证书。通常情况下，证书仅由单个应用程序使用。CA不得颁发链接到为不同目的颁发的证书的证书，例如，CA不应将web服务器证书链接到VPN网关证书（除非这些证书可以相同，这可能发生在某些嵌入式设备上）。证书的目的可由证书策略或本规范范围之外的其他方式（例如，扩展密钥使用对象标识符）确定。
CAs MUST NOT issue certificates containing this extension unless they have validated that the end entity is the holder of all of the relevant private keys.
CA不得颁发包含此扩展的证书，除非其已验证最终实体是所有相关私钥的持有人。
Applications MUST validate certificates according to the rules specified in RFC 5280 [RFC5280] and MUST NOT assume that because certificates are linked that they are therefore valid. This means, of course, that both certificates must chain up to some local trust point(s).
应用程序必须根据RFC 5280[RFC5280]中指定的规则验证证书，并且不得假设由于链接了证书，因此证书是有效的。当然，这意味着两个证书必须链接到某个本地信任点。
If an application imposes further checks on certificate validity (e.g., as is done in RFC 2818 [RFC2818] for web server certificates), then both certificates MUST be valid according to those application-specific rules.
如果应用程序对证书有效性进行进一步检查（例如，如RFC 2818[RFC2818]中针对web服务器证书所做的检查），则根据这些特定于应用程序的规则，两个证书都必须有效。
It is not required that two linked certificates be simultaneously valid. For example, an application can validate certificate1 and cache that information. When the application is subsequently presented with certificate2 (linked back to certificate1), if it considers the cached information about certificate1 trustworthy, then it can validate certificate2 and use the linkage to associate certificate2 with the relevant application-state information (just as it would have done had certificate1 been re-presented). As a second example, if certificate1 has expired but would otherwise be valid, then the linkage from certificate2 can also be used once certificate2 has been validated.
不要求两个链接的证书同时有效。例如，应用程序可以验证证书1并缓存该信息。当应用程序随后显示certificate2（链接回certificate1）时，如果它认为有关certificate1的缓存信息是可信的，那么它可以验证certificate2并使用链接将certificate2与相关应用程序状态信息相关联（就像重新呈现certificate1一样）。第二个例子是，如果certificate1已过期，但在其他情况下是有效的，那么certificate2的链接也可以在certificate2验证后使用。
If the application checks certificate status for the certificates in question, and any of the certificates concerned has been revoked, then the linkage MUST NOT be used.
如果应用程序检查有问题证书的证书状态，并且任何相关证书已被吊销，则不得使用链接。
Note that there are no constraints on the contents of the certificate to which the link points. The consequence is that the CA issuing the new certificate can link back to legacy certificates of all kinds, once the relevant RP supports this extension.
请注意，链接指向的证书的内容没有限制。其结果是，一旦相关RP支持此扩展，颁发新证书的CA可以链接回所有类型的旧证书。
This extension MUST only be used in end-entity certificates, that is, it MUST NOT be used in CA certificates or other similar certificates. Since CA certificates are only used for certificate validation and this extension has no effect on the validation procedure, this extension would generally be meaningless in a CA certificate. In addition, it may be wise to gain some deployment experience with this extension before using it for more security-sensitive certificates, like CA certificates.
此扩展只能在最终实体证书中使用，即不能在CA证书或其他类似证书中使用。由于CA证书仅用于证书验证，并且此扩展对验证过程没有影响，因此此扩展在CA证书中通常没有意义。此外，在将此扩展用于更安全敏感的证书（如CA证书）之前，最好先获得一些部署经验。
RFC 4043 [RFC4043] defines a new name form (a "Permanent Identifier" or PI) for public key certificates that supports similar functionality to the new extension defined here. If two certificates have the same PI and that PI form is globally unique, then the end entities involved can be considered to be the same.
RFC 4043[RFC4043]为公钥证书定义了一种新的名称形式（“永久标识符”或PI），它支持与此处定义的新扩展类似的功能。如果两个证书具有相同的PI，并且该PI形式是全局唯一的，则可以认为所涉及的最终实体是相同的。
The main difference between the PI and the other certificates extension is that (when more than one CA is involved) PI requires a globally unique identifier, whereas the other certificates extension only requires that the issuer of the new certificate be able to link back to the old certificate(s).
PI和其他证书扩展之间的主要区别在于（当涉及多个CA时）PI需要全局唯一标识符，而其他证书扩展仅要求新证书的颁发者能够链接回旧证书。
As a consequence, the other certificates extension can be deployed "reactively" to link certificates that may not match "ideal" application-naming requirements. If the old certificate did make use of PI, then presumably application-naming issues have already been handled, and then the new certificate can contain the same PI. In this latter case, there would be no need for the other certificates extension.
因此，可以“反应式”部署其他证书扩展来链接可能不符合“理想”应用程序命名要求的证书。如果旧证书确实使用了PI，那么应用程序命名问题可能已经得到处理，然后新证书可以包含相同的PI。在后一种情况下，不需要其他证书扩展。
The SCVPCertID structure used here contains the issuer name for the CA of the linked certificate. It may happen that this issuer is also the issuer of the certificate containing the other certificates extension. If a new certificate were linked back to a number of old certificates from that same CA, then there would be considerable redundancy since there would be many copies of the same issuer name.
此处使用的SCVPCertID结构包含链接证书的CA的颁发者名称。此颁发者也可能是包含其他证书扩展的证书的颁发者。如果将一个新证书链接回来自同一CA的多个旧证书，那么会有相当多的冗余，因为会有许多相同颁发者名称的副本。
One suggestion raised was to have a convention where if the X.500 Name in the SCVPCertID is an "empty" DN (see RFC5280), then that would indicate that the same CA issued both the current and the
提出的一项建议是，如果SCVPCertID中的X.500名称为“空”DN（请参阅RFC5280），则表示同一CA同时发布了当前和
linked certificates. However, that scheme is not adopted in this version. A future, Standards Track version of this specification might adopt that optimisation.
链接证书。但是，此版本中未采用该方案。本规范的未来标准跟踪版本可能采用该优化。
The use case motivating this was contributed to the W3C web security context (WSC) working group by Tyler Close. See http://www.w3.org/2006/WSC/wiki/SafeWebFormEditor for details.
激发这一点的用例由Tyler Close提交给W3C web安全上下文（WSC）工作组。看见http://www.w3.org/2006/WSC/wiki/SafeWebFormEditor 详情请参阅。
Denis Pinkas pointed out that the PI extension is an alternative to this one.
丹尼斯·平卡斯指出，PI扩展是这一扩展的替代。
James Manger suggested the optimisation to reduce the number of copies of the issuer name.
James Manger建议进行优化，以减少发行人名称的副本数量。
As stated above, relying parties MUST validate any certificates per the algorithm given in RFC 5280 [RFC5280] before making any use of those certificates.
如上所述，在使用任何证书之前，依赖方必须按照RFC 5280[RFC5280]中给出的算法验证任何证书。
Relying parties similarly MUST NOT assume that any other fields in the relevant certificates have common values. For example, linked certificates might have non-overlapping key usage extensions.
依赖方同样不得假设相关证书中的任何其他字段具有共同值。例如，链接证书可能具有不重叠的密钥使用扩展。
Since the issuer of the new certificate (or some superior CA) is trusted by the RP, and the RP has validated the new certificate, the RP is basically as reliant on the proper operation of that CA as always -- if the CA wished to "cheat" on the RP, the other certificates extension simply provides a new way to do that, but one that is equivalent to existing vulnerabilities. In many cases, such a bad CA could simply issue a new certificate that is identical in all respects (other than the key pair) and the RP would accept the identity contained in that new certificate.
由于新证书（或某些高级CA）的颁发者受到RP的信任，并且RP已经验证了新证书，因此RP基本上一如既往地依赖于该CA的正确操作——如果CA希望在RP上“欺骗”，则其他证书扩展只提供了一种新的方法，但这相当于现有的漏洞。在许多情况下，这样一个坏的CA可以简单地发出一个在所有方面都相同的新证书（除了密钥对），RP将接受该新证书中包含的标识。
However, if the issuer of the new certificate is limited in some way (e.g., via a name constraint in a superior CA certificate), and if the old certificate doesn't match those limitations (e.g., the subject of the old certificate doesn't fit under the name constraints of the issuer of the new certificate), then the new certificate could be linked back to an identity that doesn't meet the constraints intended to be imposed on the issuer of the new certificate. Applications for which this is an unacceptable risk SHOULD NOT make use of the other certificates extension.
但是，如果新证书的颁发者受到某种限制（例如，通过高级CA证书中的名称约束），并且如果旧证书不符合这些限制（例如，旧证书的主题不符合新证书颁发者的名称约束），然后，可以将新证书链接回一个不满足新证书颁发者所受约束的标识。对于不可接受风险的应用程序，不应使用其他证书扩展。
Since the SCVPCertID structure includes a hash of the other certificate and hash algorithm weaknesses that produce collisions are becoming more of an issue, CAs and relying parties MUST ensure that currently acceptable hash functions are used. In particular, the default use of SHA-1 for SCVPCertID may or may not currently be considered acceptable. CAs might be wise to use SHA-256 instead, but will typically use whatever hash function they use as part of certificate signing.
由于SCVPCertID结构包括其他证书的散列，并且导致冲突的散列算法弱点越来越严重，CA和依赖方必须确保使用当前可接受的散列函数。特别是，SCVPCertID默认使用SHA-1可能被认为是可以接受的，也可能不被认为是可以接受的。CA使用SHA-256可能是明智的，但通常会使用它们用作证书签名一部分的任何哈希函数。
In some application contexts, if the old certificate has expired (and perhaps any associated certificate revocation list (CRL) entries are no longer on the latest CRL), it may be unsafe to link the new and old certificates. Application developers SHOULD carefully consider whether to make use of the other certificates extension in such contexts.
在某些应用程序上下文中，如果旧证书已过期（并且任何关联的证书吊销列表（CRL）条目可能不再位于最新的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月。
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[RFC5055]Freeman，T.，Housley，R.，Malpani，A.，Cooper，D.，和W.Polk，“基于服务器的证书验证协议（SCVP）”，RFC 50552007年12月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC4043] Pinkas, D. and T. Gindin, "Internet X.509 Public Key Infrastructure Permanent Identifier", RFC 4043, May 2005.
[RFC4043]Pinkas，D.和T.Gindin，“互联网X.509公钥基础设施永久标识符”，RFC 4043，2005年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
PKIX OID registrations may be viewed at:
http://www.imc.org/ietf-pkix/pkix-oid.asn
PKIX OID registrations may be viewed at:
http://www.imc.org/ietf-pkix/pkix-oid.asn
PKIXOtherCertsModule
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 44 }
PKIXOtherCertsModule
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 44 }
DEFINITIONS EXPLICIT TAGS ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL
--全部出口
IMPORTS
进口
-- From [RFC5055]
SCVPCertID
FROM SCVP { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 21 } ;
-- From [RFC5055]
SCVPCertID
FROM SCVP { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 21 } ;
-- The one and only new thing, a new certificate extension
--唯一的新事物，一个新的证书扩展
id-pe-otherCerts OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 19 }
id-pe-otherCerts OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 19 }
-- The value is a sequence of cert ids.
OtherCertificates ::= SEQUENCE OF SCVPCertID
-- The value is a sequence of cert ids.
OtherCertificates ::= SEQUENCE OF SCVPCertID
END
终止
Author's Address
作者地址
Stephen Farrell Trinity College Dublin Department of Computer Science Trinity College Dublin, 2 Ireland
斯蒂芬·法雷尔三一学院都柏林计算机科学系三一学院都柏林，2爱尔兰
Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie
Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie