Independent Submission H. Hotz
Request for Comments: 6717 Jet Propulsion Lab, Caltech
Category: Informational R. Allbery
ISSN: 2070-1721 Stanford University
August 2012
Independent Submission H. Hotz
Request for Comments: 6717 Jet Propulsion Lab, Caltech
Category: Informational R. Allbery
ISSN: 2070-1721 Stanford University
August 2012
kx509 Kerberized Certificate Issuance Protocol in Use in 2012
2012年使用的kx509 Kerberized证书颁发协议
Abstract
摘要
This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.
本文档描述了一个名为kx509的协议，用于使用Kerberos票证获取X.509证书。这些证书可以用于许多与通过其他方式获取的X.509证书相同的目的，但是如果Kerberos基础结构已经存在，那么使用kx509的开销可能会小得多。
While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation.
虽然没有标准化，但该协议已经在多个大型组织中使用，使用该协议颁发的证书得到了国际电网信托联合会的认可。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6717.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6717.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Protocol Data ...................................................3
2.1. Request Packet .............................................3
2.2. Reply Packet ...............................................4
3. Protocol Operation ..............................................7
4. Acknowledgements ................................................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Appendix A. Certificate Caching and Deployment Considerations ....12
Appendix B. Historic Extensions ..................................12
Appendix C. Example Exchange .....................................12
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Protocol Data ...................................................3
2.1. Request Packet .............................................3
2.2. Reply Packet ...............................................4
3. Protocol Operation ..............................................7
4. Acknowledgements ................................................8
5. IANA Considerations .............................................8
6. Security Considerations .........................................9
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Appendix A. Certificate Caching and Deployment Considerations ....12
Appendix B. Historic Extensions ..................................12
Appendix C. Example Exchange .....................................12
The two primary ways of providing cryptographically secure identification on the Internet are Kerberos tickets [RFC4120] and X.509 [RFC5280] [X.509] certificates.
在Internet上提供加密安全标识的两种主要方法是Kerberos票证[RFC4120]和X.509[RFC5280][X.509]证书。
In practical IT infrastructure where both are in use, it's highly desirable to deploy their support in a way that guarantees they both authoritatively refer to the same entities. There is already a widely adopted standard for using X.509 certificates to acquire corresponding Kerberos tickets called Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC4556]. This document describes the kx509 protocol for supporting the symmetric operation of acquiring X.509 certificates using Kerberos tickets.
在实际的IT基础架构中，如果两者都在使用，那么最好以一种能够保证它们都权威性地引用相同实体的方式部署它们的支持。使用X.509证书获取相应的Kerberos票证已经有一个广泛采用的标准，称为公钥密码体制，用于Kerberos中的初始身份验证（PKINIT）[RFC4556]。本文档描述了用于支持使用Kerberos票证获取X.509证书的对称操作的kx509协议。
Preparing and reviewing this document exposed a number of issues that are discussed in the security considerations. Unfortunately, some of them can only be addressed with an incompatible upgrade to this protocol. The IETF's Kerberos working group has an expected work item to address these issues.
准备和审阅本文档时，会暴露安全注意事项中讨论的一些问题。不幸的是，其中一些问题只能通过对该协议进行不兼容的升级来解决。IETF的Kerberos工作组有一个预期的工作项来解决这些问题。
The International Grid Trust Federation [IGTF] supports the use of Short Lived Credential Services [SLCS] as a means to authenticate for resource usage based on other, native identity stores that an organization maintains. X.509 certificates issued using the kx509 protocol based on a Kerberos identity is one of the recognized credential services. The certificate profile for that use is outside the scope of this RFC but is described in [GRID-prof].
国际网格信任联合会[IGTF]支持使用短期凭证服务[SLC]作为基于组织维护的其他本机身份存储对资源使用情况进行身份验证的手段。使用基于Kerberos身份的kx509协议颁发的X.509证书是公认的凭证服务之一。该用途的证书配置文件不在本RFC的范围内，但在[GRID prof]中有描述。
In normal operation, kx509 can be used after a Kerberos ticket-granting-ticket (TGT) is acquired, which is most likely during user login. First, the client generates an RSA public/private key pair. Next, using the Kerberos ticket-granting-ticket, it acquires a Kerberos service ticket for the KCA (Kerberized Certificate Authority) and uses this to send the public half of its key pair. The KCA will decrypt the service ticket, verify the integrity of the incoming packet, determine the identity of the user, and use the session key to send back a corresponding X.509 certificate.
在正常操作中，kx509可以在获取Kerberos票证授予票证（TGT）后使用，这很可能是在用户登录期间。首先，客户机生成RSA公钥/私钥对。接下来，使用Kerberos票证授予票证，它获取KCA（Kerberized Certificate Authority）的Kerberos服务票证，并使用该票证发送其密钥对的公共部分。KCA将解密服务票证，验证传入数据包的完整性，确定用户的身份，并使用会话密钥发回相应的X.509证书。
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]中所述进行解释。
The protocol consists of a single request/reply exchange using UDP.
该协议由使用UDP的单个请求/应答交换组成。
Both the request and the reply packet begin with four bytes of version ID information, followed by a DER-encoded ASN.1 message. The first two bytes of the version ID are reserved. They MUST be set to zero when sent and SHOULD be ignored when received. The third and fourth bytes are the major and minor version numbers, respectively. The version of the protocol described in this document is designated 2.0, so the first four bytes of the packet are 0, 0, 2, and 0.
请求和应答数据包都以四个字节的版本ID信息开始，然后是一条DER编码的ASN.1消息。版本ID的前两个字节是保留的。它们在发送时必须设置为零，在接收时应忽略。第三个和第四个字节分别是主版本号和次版本号。本文档中描述的协议版本被指定为2.0，因此数据包的前四个字节分别为0、0、2和0。
Incompatible variations of this protocol MUST use a different major version number.
此协议的不兼容变体必须使用不同的主版本号。
The request consists of a version ID, followed by a DER-encoded ASN.1 message containing a Kerberos AP-REQ, integrity check data on the request, and public key generated by the client. The ASN.1 encoding is:
该请求由一个版本ID、一条包含Kerberos AP-REQ的DER编码ASN.1消息、请求上的完整性检查数据以及客户端生成的公钥组成。ASN.1编码是：
KX509Request ::= SEQUENCE {
AP-REQ OCTET STRING,
pk-hash OCTET STRING,
pk-key OCTET STRING
}
KX509Request ::= SEQUENCE {
AP-REQ OCTET STRING,
pk-hash OCTET STRING,
pk-key OCTET STRING
}
The AP-REQ is as described in [RFC4120], Section 5.5.1.
AP-REQ如[RFC4120]第5.5.1节所述。
The pk-hash is Hashed Message Authentication Code (HMAC) using SHA-1 as the underlying hash. All 160 bits are sent. The key used is the Kerberos session key. The data to be hashed is the concatenation of the following:
pk散列是使用SHA-1作为基础散列的散列消息身份验证码（HMAC）。所有160位都被发送。使用的密钥是Kerberos会话密钥。要散列的数据是以下数据的串联：
o 4-byte version ID at the beginning of the packet.
o 数据包开头的4字节版本ID。
o OCTET STRING of the AP-REQ.
o AP-REQ的八位字节字符串。
o OCTET STRING of the pk-key.
o pk键的八位字节字符串。
The pk-key contains a public key. This key and its corresponding private key are generated by the client before contacting the server. Implementations of this protocol MUST support RSA keys, in which case the key is a DER-encoded RSAPublicKey as defined in [RFC3447], Section A.1.1, and then it is stored in this octet string in the request. Its encoding as an OCTET STRING starts with the 0x30 byte sequence at the beginning of a DER-encoded RSAPublicKey. Use of other public-key types is not defined.
pk密钥包含一个公钥。此密钥及其对应的私钥由客户端在联系服务器之前生成。此协议的实现必须支持RSA密钥，在这种情况下，密钥是[RFC3447]第a.1.1节中定义的经DER编码的RSAPPublicKey，然后存储在请求中的此八位字节字符串中。它作为八位字节字符串的编码从DER编码的RSAPublicKey开头的0x30字节序列开始。未定义其他公钥类型的使用。
Appendix C shows an example request packet.
附录C显示了一个示例请求包。
The reply consists of a version ID, followed by a DER-encoded ASN.1 message containing an error code, an optional authentication hash, optional certificate, and optional error text. The service SHOULD return replies of the same version as the request where possible.
回复包含一个版本ID，后跟一条DER编码的ASN.1消息，其中包含一个错误代码、一个可选的身份验证哈希、可选的证书和可选的错误文本。服务应尽可能返回与请求相同版本的回复。
KX509Response ::= SEQUENCE {
error-code[0] INTEGER DEFAULT 0,
hash[1] OCTET STRING OPTIONAL,
certificate[2] OCTET STRING OPTIONAL,
e-text[3] VisibleString OPTIONAL
}
KX509Response ::= SEQUENCE {
error-code[0] INTEGER DEFAULT 0,
hash[1] OCTET STRING OPTIONAL,
certificate[2] OCTET STRING OPTIONAL,
e-text[3] VisibleString OPTIONAL
}
Although the format of the reply contains independently optional objects, the server MUST only generate replies with one of the following allowed combinations.
尽管回复的格式包含独立的可选对象，但服务器必须仅使用以下允许的组合之一生成回复。
+------------+------+-------------+--------+
| | hash | certificate | |
| error-code | hash | | e-text |
| error-code | | | e-text |
+------------+------+-------------+--------+
+------------+------+-------------+--------+
| | hash | certificate | |
| error-code | hash | | e-text |
| error-code | | | e-text |
+------------+------+-------------+--------+
The first case is returned when the server successfully generates a certificate for the user. The certificate is a DER-encoded certificate as defined in [RFC5280], Appendix A, page 116. Its encoding as an OCTET STRING starts with the 0x30 byte sequence that is at the beginning of a DER-encoded certificate.
当服务器成功为用户生成证书时，返回第一个案例。该证书为[RFC5280]附录a第116页中定义的DER编码证书。它作为八位字节字符串的编码从DER编码证书开头的0x30字节序列开始。
The second case is returned when the server successfully authenticates the user and their key, but is unable for some other reason to generate a certificate.
当服务器成功验证用户及其密钥，但由于某些其他原因无法生成证书时，返回第二种情况。
The third case MAY be returned if the server is unable to successfully authenticate the user and intends to return some unauthenticated information to the client.
如果服务器无法成功对用户进行身份验证，并打算向客户端返回一些未经身份验证的信息，则可能会返回第三种情况。
The hash on a response is computed using SHA-1 HMAC as for the request.
响应上的哈希是使用请求的SHA-1 HMAC计算的。
The data that is hashed is the concatenation of the following things:
散列的数据是以下内容的串联：
o 4-byte version ID at the beginning of the packet.
o 数据包开头的4字节版本ID。
o DER representation of the error-code exclusive of the tag and length, if it is present.
o 错误代码的DER表示，不包括标记和长度（如果存在）。
o OCTET STRING of the certificate, if it is present.
o 证书的八位字节字符串（如果存在）。
o VisibleString representation of the e-text exclusive of the tag and length, if it is present.
o 电子文本的VisibleString表示形式，不包括标记和长度（如果存在）。
In other words, the hash is computed on the data in the fields that are present, exclusive of the overall ASN.1 wrapping.
换句话说，散列是根据存在的字段中的数据计算的，不包括整个ASN.1包装。
The e-text MAY be translated into other character sets for display purposes, but the hash is computed on the e-text in its VisibleString representation. If the e-text contains NUL characters, the client MAY ignore any part of the error message after the first NUL character for display purposes.
出于显示目的，可以将电子文本转换为其他字符集，但哈希是在电子文本的VisibleString表示中计算的。如果电子文本包含NUL字符，出于显示目的，客户端可能会忽略第一个NUL字符之后错误消息的任何部分。
As implied by the above table, if the reply does not contain a certificate, it MUST contain an error message and a non-zero error code. Conversely, if a certificate is returned, then the error-code MUST be zero. The server SHOULD use the DEFAULT encoding for a zero error-code value by omitting any explicit error-code from the reply.
如上表所示，如果回复不包含证书，则必须包含错误消息和非零错误代码。相反，如果返回证书，则错误代码必须为零。服务器应该通过从应答中省略任何显式错误代码，对零错误代码值使用默认编码。
The defined values for error-code are as follows:
错误代码的定义值如下所示：
+------------+-----------------------------+------------------------+
| error-code | Condition | Example |
+------------+-----------------------------+------------------------+
| 1 | Permanent problem with | Incompatible version |
| | client request | |
| 2 | Solvable problem with | Expired Kerberos |
| | client request | credentials |
| 3 | Temporary problem with | Packet loss |
| | client request | |
| 4 | Permanent problem with the | Internal |
| | server | misconfiguration |
| 5 | Temporary problem with the | Server overloaded |
| | server | |
+------------+-----------------------------+------------------------+
+------------+-----------------------------+------------------------+
| error-code | Condition | Example |
+------------+-----------------------------+------------------------+
| 1 | Permanent problem with | Incompatible version |
| | client request | |
| 2 | Solvable problem with | Expired Kerberos |
| | client request | credentials |
| 3 | Temporary problem with | Packet loss |
| | client request | |
| 4 | Permanent problem with the | Internal |
| | server | misconfiguration |
| 5 | Temporary problem with the | Server overloaded |
| | server | |
+------------+-----------------------------+------------------------+
If a client error is returned, the client SHOULD NOT retry the request unless some remedial action is first taken, although if error-code 3 is returned, the client MAY retry with other servers before giving up.
如果返回客户端错误，除非首先采取补救措施，否则客户端不应重试请求，尽管如果返回错误代码3，客户端可能会在放弃之前与其他服务器重试。
If a server error is returned, it is RECOMMENDED that the client retry the request with a different server if one is known.
如果返回服务器错误，建议客户端使用其他服务器重试请求（如果已知）。
Since all KCAs serving a Kerberos realm are intended to be equivalent, in accordance with Section 4.1.2.2 of [RFC5280], the certificates returned from different KCAs serving the same Kerberos realm MUST NOT contain duplicate serial numbers.
根据[RFC5280]第4.1.2.2节，由于服务于Kerberos领域的所有KCA都是等效的，因此从服务于同一Kerberos领域的不同KCA返回的证书不得包含重复的序列号。
This protocol and document do not address certificate verification or path construction. There are no provisions for returning any additional certificates that might be needed. Any application using a returned certificate must be configured independently to address these issues. An incompatible upgrade to this protocol will provide options to address this issue.
此协议和文档不涉及证书验证或路径构造。没有规定退还可能需要的任何其他证书。任何使用返回证书的应用程序都必须单独配置以解决这些问题。此协议的不兼容升级将提供解决此问题的选项。
The returned certificate MUST identify the Kerberos client principal from the AP-REQ in the original KX509Request in the subject of the certificate or in a subjectAltName extension. The identification MUST be unique within the organization's deployed infrastructure. It is RECOMMENDED that a subjectAltName extension be included of type id-pkinit-san as described in [RFC4556], Section 3.2.2. Note that the id-pkinit-san is simply a standard representation of a Kerberos principal and has no other implications with respect to PKINIT.
返回的证书必须在证书主题或subjectAltName扩展中的原始KX509请求中标识AP-REQ中的Kerberos客户端主体。标识在组织部署的基础架构中必须是唯一的。建议按照[RFC4556]第3.2.2节所述，将subjectAltName扩展包含在类型id pkinit san中。请注意，id pkinit san只是Kerberos主体的标准表示形式，对于pkinit没有其他含义。
Other extensions MAY be added according to local policy.
可根据当地政策添加其他扩展。
Appendix C shows an example reply packet.
附录C显示了一个示例回复包。
Absent errors, the protocol consists of a single request, sent via UDP, and a single reply, also sent via UDP.
如果没有错误，该协议由单个请求（通过UDP发送）和单个回复（也通过UDP发送）组成。
There is no special provision for requests or replies that exceed the allowable size of a UDP packet. Also, some implementations have imposed hard size limits that are smaller than a typical UDP MTU and will limit the use of extensions and the supportable key size. Even without hard limits, if the request or reply exceeds the MTU size of a UDP packet for the infrastructure in use, then the reliability of the exchange will decrease significantly.
对于超过UDP数据包允许大小的请求或答复，没有特殊规定。此外，一些实现施加了比典型UDP MTU小的硬大小限制，并将限制扩展的使用和可支持的密钥大小。即使没有硬限制，如果请求或应答超过所用基础设施UDP数据包的MTU大小，则交换的可靠性将显著降低。
For "normal" Kerberos AP-REQ structures, and "normal" X.509 certificates, this is unlikely unless the Kerberos service ticket contains large amounts of authorization data. For this reason, it is RECOMMENDED that service tickets for the KCA be issued without authorization data. If the KCA performs authorization, it should do so by other means.
对于“正常”Kerberos AP-REQ结构和“正常”X.509证书，除非Kerberos服务票证包含大量授权数据，否则不太可能出现这种情况。因此，建议在没有授权数据的情况下签发KCA的服务票。如果KCA执行授权，则应通过其他方式执行。
Before constructing the request, the client must know the canonical name(s) and port(s) of the server(s) to contact. It MAY determine them by looking up the service's SRV record as described in [RFC2782]. The entry to be used is _kca._udp._realm_, where _realm_ is the Kerberos realm, used as part of the DNS name.
在构造请求之前，客户端必须知道要联系的服务器的规范名称和端口。它可以通过查找[RFC2782]中所述的服务SRV记录来确定它们。要使用的条目是_kca._udp._realm，其中_realm是Kerberos领域，用作DNS名称的一部分。
The client has to acquire a service ticket in order to construct the AP-REQ for the service. Conventionally, the Kerberos service principal name to use for this service has a first component of "kca_service". Absent local configuration or other external knowledge of the correct principal to use, the second and final component is conventionally the canonical name of the KCA server being contacted, and the realm of the principal is determined following normal Kerberos domain-to-realm mapping conventions, as discussed in [RFC4120], Section 1.3.
客户端必须获取服务票证，以便为服务构建AP-REQ。通常，用于此服务的Kerberos服务主体名称具有“kca_服务”的第一个组件。如果没有本地配置或要使用的正确主体的其他外部知识，第二个也是最后一个组件通常是所联系的KCA服务器的规范名称，主体的领域根据正常的Kerberos域到领域映射约定确定，如[RFC4120]第1.3节所述。
When the server receives a request, it MUST verify the following properties of the request before issuing a certificate:
当服务器收到请求时，它必须在颁发证书之前验证请求的以下属性：
o The AP-REQ can be decoded and is not expired.
o AP-REQ可解码且未过期。
o If the request uses cross-realm authentication, then it satisfies the requirements of local policy and [RFC4120], Sections 1.2 and 2.7.
o 如果请求使用跨域身份验证，则它满足本地策略和[RFC4120]第1.2节和第2.7节的要求。
o The request's hash is valid.
o 请求的哈希值有效。
The server SHOULD make other sanity checks, such as a minimum public key length, to the extent feasible.
服务器应尽可能进行其他健全性检查，如最小公钥长度。
The server MAY decline to respond to an erroneous request. If it does not receive a response, a client MAY retry its request, but the client SHOULD wait at least one second before doing so.
服务器可能拒绝响应错误的请求。如果没有收到响应，客户机可以重试其请求，但在重试之前，客户机应至少等待一秒钟。
The client MUST verify any hash in the reply and MUST NOT use any certificate in a reply whose hash does not verify. The client MAY display the e-text if the hash is absent or does not verify but SHOULD indicate the message is not authenticated.
客户端必须验证回复中的任何哈希，并且不得在哈希未验证的回复中使用任何证书。如果散列不存在或未验证，客户端可能会显示电子文本，但应指示消息未经过身份验证。
The original version of kx509 was implemented using Kerberos 4 at the University of Michigan and was nicely documented in [KX509]. Many thanks to them for their original work, as well as the subsequent updates.
KX509的原始版本是在密歇根大学使用Kerberos 4实现的，并且很好地被记录在[KX509]中。非常感谢他们的原创作品，以及随后的更新。
While developing this document, important corrections and comments were provided by Jeffrey Altman and Love Hornquist Astrand. The following people also provided many helpful comments and corrections: Doug Engert, Jeffrey Hutzelman, Sam Hartman, Timothy J. Miller, Chaskiel Grundman, and Jim Schaad. Alan Sill provided the references to the International Grid Trust Federation and its acceptable credential services. Example network traffic was provided by Doug Engert, Marcus Watts, Matt Crawford, and Chaskiel Grundman from their deployments and was extremely useful for verifying the reality of this specification.
在编制本文件时，Jeffrey Altman和Love Hornquist Astrand提供了重要的更正和评论。下面的人也提供了许多有用的评论和更正：道格·恩格特、杰弗里·哈泽尔曼、萨姆·哈特曼、蒂莫西·米勒、查斯基尔·格伦德曼和吉姆·沙德。Alan Sill提供了国际电网信托联合会及其可接受的凭证服务的参考资料。Doug Engert、Marcus Watts、Matt Crawford和Chaskiel Grundman在其部署中提供了示例网络流量，对于验证此规范的真实性非常有用。
This service is conventionally run on UDP port 9878. IANA has registered that port in the Service Name and Transport Port Number Registry as follows:
此服务通常在UDP端口9878上运行。IANA已在服务名称和传输端口号注册表中注册该端口，如下所示：
Service Name: kca-service
Transport Protocol: UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: The kx509 Kerberized Certificate Issuance
Protocol in Use in 2012
Reference: RFC 6717
Port Number: 9878
Assignment Notes: Historically, this service has been referred to
as "kca_service", but this service name does
Service Name: kca-service
Transport Protocol: UDP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: The kx509 Kerberized Certificate Issuance
Protocol in Use in 2012
Reference: RFC 6717
Port Number: 9878
Assignment Notes: Historically, this service has been referred to
as "kca_service", but this service name does
not meet the registry requirements.
不符合注册要求。
The Generic Security Service Application Program Interface (GSS-API) / Kerberos / Simple Authentication and Security Layer (SASL) service name currently in use for this protocol is "kca_service". This does not meet the naming requirements for IANA's GSS-API/Kerberos/SASL service name registry, so no registration has been requested. The conflict between the conventional service name and the registry rules is expected to be addressed in a future version of this protocol. Appropriate registrations will be requested at that time.
此协议当前使用的通用安全服务应用程序接口（GSS-API）/Kerberos/简单身份验证和安全层（SASL）服务名称为“kca_服务”。这不符合IANA的GSS-API/Kerberos/SASL服务名称注册表的命名要求，因此未请求注册。传统服务名称和注册表规则之间的冲突预计将在该协议的未来版本中解决。届时将要求进行适当的登记。
The only encrypted information in the protocol is that used by Kerberos itself. The considerations for any Kerberized service apply here.
协议中唯一加密的信息是Kerberos本身使用的信息。任何Kerberized服务的注意事项适用于此处。
The public key in the request is sent in the clear and without any guarantees that the requester actually possesses the corresponding private key. Therefore, the only appropriate uses of the returned certificate are those where the identity of the requester is unimportant or the subsequent use independently guarantees that the user possesses the private key. This issue is expected to be addressed in a future version of this protocol.
请求中的公钥以明文形式发送，不保证请求者实际拥有相应的私钥。因此，返回证书的唯一适当使用是那些请求者的身份不重要或后续使用独立保证用户拥有私钥的情况。这一问题有望在本议定书的未来版本中得到解决。
For example, if the kx509-issued certificate is used for a digital signature in a way that does not independently demonstrate proof-of-possession of the private key, then an eavesdropper could request their own valid certificate via kx509 and claim to have originated material signed by the legitimate, original requester. [RFC4211], Appendix C, contains a more detailed discussion of why proof-of-possession is important.
例如，如果kx509颁发的证书用于数字签名的方式不能独立证明拥有私钥，则窃听者可以通过kx509请求其自己的有效证书，并声称拥有合法原始请求者签名的原始材料。[RFC4211]附录C更详细地讨论了占有证明的重要性。
An example that should be safe is initial client authentication with Transport Layer Security (TLS) [RFC5246] connections. If a client certificate is used, then a Certificate Verify message (Section 7.4.8 of [RFC5246]) is added to the handshake exchange. It includes a signature of the handshake messages to that point. Those messages depend on data known only to the client and server ends of the specific connection, so computing the signature proves possession of the private key. This application was the original intended use case for kx509.
应该是安全的一个示例是使用传输层安全性（TLS）[RFC5246]连接的初始客户端身份验证。如果使用了客户端证书，则证书验证消息（RFC5246的第7.4.8节）将添加到握手交换中。它包括到该点的握手消息的签名。这些消息依赖于只有特定连接的客户端和服务器端才知道的数据，因此计算签名证明拥有私钥。此应用程序是kx509的原始预期用例。
Some information, such as the public key and certificate, is transmitted in the clear but (as the name implies) is generally intended to be publicly available. However, its visibility could still raise privacy concerns. The hash is used to protect the integrity of this information.
某些信息，如公钥和证书，以明文形式传输，但（顾名思义）通常是公开的。然而，它的可见性仍然可能引起隐私问题。哈希用于保护此信息的完整性。
The policies for issuing Kerberos tickets and X.509 certificates are usually expressed very differently. An implementation of this protocol should not provide a mechanism for bypassing ticket or certificate policies.
用于颁发Kerberos票证和X.509证书的策略的表达方式通常非常不同。此协议的实现不应提供绕过票证或证书策略的机制。
In particular, if the issued certificate can be used with PKINIT, this authentication loop SHOULD NOT bypass policy limits for either X.509 certificates or Kerberos tickets.
特别是，如果颁发的证书可以与PKINIT一起使用，则此身份验证循环不应绕过X.509证书或Kerberos票证的策略限制。
X.509 certificates are usually issued with considerably longer validity times than Kerberos tickets. Care should be taken that the issued certificate is not valid for longer than the intended policy should allow. Note that Section 3.2.3 of [RFC4556] REQUIRES that the lifetime of an issued ticket not exceed the lifetime of the predecessor certificate. By analogy, it is RECOMMENDED that the lifetime of an issued certificate not exceed the lifetime of the predecessor Kerberos ticket unless the implications with respect to local policy and supporting infrastructure are clearly understood and allow it.
X.509证书通常比Kerberos票据具有更长的有效期。应注意，颁发的证书的有效期不得超过预期政策允许的时间。请注意，[RFC4556]第3.2.3节要求已发行票据的有效期不得超过先前证书的有效期。通过类比，建议已颁发证书的生存期不超过前一个Kerberos票证的生存期，除非明确理解并允许与本地策略和支持基础架构相关的含义。
[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月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[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月。
[GRID-prof] "Grid Certificate Profile", March 2008, <http://www.ogf.org/documents/GFD.125.pdf>.
[GRID教授]“GRID证书简介”，2008年3月<http://www.ogf.org/documents/GFD.125.pdf>.
[IGTF] "The International Grid Trust Federation", <http://www.igtf.net/>.
[IGTF]“国际电网信托联合会”<http://www.igtf.net/>.
[KX509] Doster, W., Watts, M., and D. Hyde, "The KX.509 Protocol", September 2001, <http://www.citi.umich.edu/ techreports/reports/citi-tr-01-2.pdf>.
[KX509]Doster，W.，Watts，M.和D.Hyde，“KX.509协议”，2001年9月<http://www.citi.umich.edu/ techreports/reports/citi-tr-01-2.pdf>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[RFC4211]Schaad，J.“Internet X.509公钥基础设施证书请求消息格式（CRMF）”，RFC 42112005年9月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC4556]Zhu，L.和B.Tung，“Kerberos中初始身份验证的公钥加密（PKINIT）”，RFC 45562006年6月。
[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月。
[SLCS] "Short Lived Credential Services", February 2009, <http://tagpma.org/authn_profiles/slcs>.
[SLCS]“短期凭证服务”，2009年2月<http://tagpma.org/authn_profiles/slcs>.
[X.509] International Telecommunications Union, "Recommendation X.509: The Directory: Public-key and attribute certificate framework", November 2008.
[X.509]国际电信联盟，“建议X.509：目录：公钥和属性证书框架”，2008年11月。
As noted in the Security Considerations section, the functional lifetime of the acquired X.509 certificate should usually match the lifetime of its predecessor Kerberos ticket. Therefore, it is likely that X.509 certificates issued with this protocol should be deleted when the supporting Kerberos tickets are deleted. That makes the Kerberos ticket cache a reasonable location to store the certificate (and its private key).
如安全注意事项部分所述，获得的X.509证书的功能生存期通常应与其前一个Kerberos票证的生存期相匹配。因此，在删除支持Kerberos票证时，可能应该删除使用此协议颁发的X.509证书。这使得Kerberos票证缓存成为存储证书（及其私钥）的合理位置。
On the other hand, applications, such as web browsers, probably expect certificates in different stores.
另一方面，应用程序（如web浏览器）可能希望在不同的存储中获得证书。
A widely used solution to this dichotomy is to implement a PKCS11 library that supports the kx509-acquired credentials. The credentials remain stored in the Kerberos credentials cache, but full PKI functionality is still available via a standard interface for PKI credentials.
对于这种二分法，一个广泛使用的解决方案是实现一个支持kx509获得的凭证的PKCS11库。凭据仍然存储在Kerberos凭据缓存中，但完整的PKI功能仍然可以通过PKI凭据的标准接口使用。
This appendix documents extensions to the kx509 protocol that are either no longer in use or are expected to be dropped.
本附录记录了kx509协议的扩展，这些扩展已不再使用或预计将被删除。
A subjectAltName othername extension of type kcaAuthRealm (OID value 1.3.6.1.4.1.250.42.1) is frequently used to include the client's realm as an ASN.1 octet string.
kcaAuthRealm（OID值1.3.6.1.4.1.250.42.1）类型的subjectAltName othername扩展经常用于将客户端的领域作为ASN.1八位字符串包含。
The Microsoft-defined userPrincipalName has frequently been used for the same purpose as the id-pkinit-san.
Microsoft定义的userPrincipalName经常用于与id pkinit san相同的目的。
The historic implementations of this protocol included provisions for DSA keys in place of RSA. DSA does not appear to be in use. A future version of this protocol will use a standard certificate request structure that will provide algorithm agility.
该协议的历史性实施包括DSA密钥代替RSA的规定。DSA似乎未被使用。该协议的未来版本将使用标准证书请求结构，该结构将提供算法灵活性。
The historic implementations of this protocol allowed an optional client-version field (at the end of the request) of type VisibleString. If present, the KCA copied it into the issued certificate as an extension with the OID 1.3.6.1.4.1.250.42.2. This feature does not appear to be in use.
此协议的历史实现允许VisibleString类型的可选客户端版本字段（在请求末尾）。如果存在，KCA将其复制到颁发的证书中，作为OID 1.3.6.1.4.1.250.42.2的扩展。此功能似乎未被使用。
The request and reply are from the same exchange. The Ethernet, IP, and UDP headers, and the 4-byte version string at the beginning of the request and reply packets are all omitted. Only the ASN.1- encoded portions are shown.
请求和答复来自同一个交易所。以太网、IP和UDP报头以及请求和应答数据包开头的4字节版本字符串都被省略。仅显示ASN.1编码的部分。
0:d=0 hl=4 l= 678 cons: SEQUENCE
4:d=1 hl=4 l= 509 prim: OCTET STRING
[HEX DUMP]:6E8201F9308201F5A003... (AP-REQ)
517:d=1 hl=2 l= 20 prim: OCTET STRING
[HEX DUMP]:ECFF1C922300D0E9DD02... (pk-hash)
539:d=1 hl=3 l= 140 prim: OCTET STRING
[HEX DUMP]:30818902818100B70F46... (pk-key)
0:d=0 hl=4 l= 678 cons: SEQUENCE
4:d=1 hl=4 l= 509 prim: OCTET STRING
[HEX DUMP]:6E8201F9308201F5A003... (AP-REQ)
517:d=1 hl=2 l= 20 prim: OCTET STRING
[HEX DUMP]:ECFF1C922300D0E9DD02... (pk-hash)
539:d=1 hl=3 l= 140 prim: OCTET STRING
[HEX DUMP]:30818902818100B70F46... (pk-key)
Request Packet ASN.1 Decode
请求包ASN.1解码
0:d=0 hl=4 l= 870 cons: SEQUENCE
4:d=1 hl=2 l= 22 cons: cont [ 1 ]
6:d=2 hl=2 l= 20 prim: OCTET STRING
[HEX DUMP]:F3A844834C26D843B6FD... (hash)
28:d=1 hl=4 l= 842 cons: cont [ 2 ]
32:d=2 hl=4 l= 838 prim: OCTET STRING
[HEX DUMP]:308203423082022AA003... (certificate)
0:d=0 hl=4 l= 870 cons: SEQUENCE
4:d=1 hl=2 l= 22 cons: cont [ 1 ]
6:d=2 hl=2 l= 20 prim: OCTET STRING
[HEX DUMP]:F3A844834C26D843B6FD... (hash)
28:d=1 hl=4 l= 842 cons: cont [ 2 ]
32:d=2 hl=4 l= 838 prim: OCTET STRING
[HEX DUMP]:308203423082022AA003... (certificate)
Reply Packet ASN.1 Decode
应答包ASN.1解码
Authors' Addresses
作者地址
Henry B. Hotz Jet Propulsion Laboratory, California Institute of Technology 4800 Oak Grove Dr. Pasadena, CA 91109 USA
美国加利福尼亚州帕萨迪纳橡树林4800号加利福尼亚理工学院亨利·B·霍茨喷气推进实验室，邮编：91109
Phone: +01 818 354-4880
EMail: hotz@jpl.nasa.gov
Phone: +01 818 354-4880
EMail: hotz@jpl.nasa.gov
Russ Allbery Stanford University P.O. Box 20066 Stanford, CA 94309 USA
Russ Allbery斯坦福大学邮政信箱20066美国加利福尼亚州斯坦福94309
EMail: rra@stanford.edu
URI: http://www.eyrie.org/~eagle/
EMail: rra@stanford.edu
URI: http://www.eyrie.org/~eagle/