Internet Engineering Task Force (IETF)                         S. Turner
Request for Comments: 5967                                          IECA
Updates: 2986                                                August 2010
Category: Informational
ISSN: 2070-1721
        
Internet Engineering Task Force (IETF)                         S. Turner
Request for Comments: 5967                                          IECA
Updates: 2986                                                August 2010
Category: Informational
ISSN: 2070-1721

The application/pkcs10 Media Type

应用程序/pkcs10媒体类型

Abstract

摘要

This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986.

本文件规定了用于承载RFC 2986中定义的PKCS#10认证请求的媒体类型。它继承了RFC 2311的原始规范，该规范最近已被移至历史状态，并将其正确链接到RFC 2986。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc5967.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5967.

Copyright Notice

版权公告

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有（c）2010 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 Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。

1. Introduction
1. 介绍 
   [RFC2311] first defined the application/pkcs10 media type.  When
   [RFC2633] was published, the application/pkcs10 section was dropped,
   but for some reason the text was not incorporated into the PKCS #10
   document [RFC2986].  [RFC2311] was moved to Historic status by
   [RFC5751].  To ensure the IANA media type registration points to a
   non-Historic document, this document updates [RFC2986] with the
   definition of the application/pkcs10 media type and an IANA
   registration based on [RFC4288].
        
   [RFC2311] first defined the application/pkcs10 media type.  When
   [RFC2633] was published, the application/pkcs10 section was dropped,
   but for some reason the text was not incorporated into the PKCS #10
   document [RFC2986].  [RFC2311] was moved to Historic status by
   [RFC5751].  To ensure the IANA media type registration points to a
   non-Historic document, this document updates [RFC2986] with the
   definition of the application/pkcs10 media type and an IANA
   registration based on [RFC4288].

The text for Section 2 is adapted from Section 3.7 of [RFC2311].

第2节的文本改编自[RFC2311]第3.7节。

1.1. Requirements Terminology
1.1. 需求术语

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。

2. Creating a Certification Request
2. 创建认证请求

A typical application that allows a user to generate cryptographic information has to submit that information to a Certification Authority (CA), who transforms it into a certificate. PKCS #10 [RFC2986] describes a syntax for certification requests.

允许用户生成加密信息的典型应用程序必须将该信息提交给证书颁发机构（CA），CA将其转换为证书。PKCS#10[RFC2986]描述了认证请求的语法。

The details of certification requests and the process of obtaining a certificate are beyond the scope of this memo. Instead, only the format of data used in application/pkcs10 is defined.

认证申请的详细信息和获取证书的过程超出了本备忘录的范围。相反，只定义了application/pkcs10中使用的数据格式。

2.1. Format of the application/pkcs10 Body
2.1. 应用程序/pkcs10正文的格式

PKCS #10 defines the ASN.1 type CertificationRequest for use in submitting a certification request. For transfer to a CA, this abstract syntax needs to be encoded and identified in a unique

PKCS#10定义了ASN.1类型的CertificationRequest，用于提交认证请求。为了传输到CA，这个抽象语法需要以唯一的方式编码和标识

manner. When the media type application/pkcs10 is used, the body MUST be a CertificationRequest.

方式使用媒体类型application/pkcs10时，正文必须是CertificationRequest。

A robust application SHOULD output Distinguished Encoding Rules (DER), but allow Basic Encoding Rules (BER) or DER on input.

一个健壮的应用程序应该输出可分辨编码规则（DER），但允许输入基本编码规则（BER）或DER。

Data produced by BER or DER is 8-bit, but some transports are limited to 7-bit data. In such cases, a suitable 7-bit transfer encoding MUST be applied; in MIME-compatible transports, the base64 encoding [RFC4648] SHOULD be used with application/pkcs10, although any 7-bit transfer encoding may work.

BER或DER产生的数据是8位的，但有些传输仅限于7位数据。在这种情况下，必须应用合适的7位传输编码；在MIME兼容的传输中，base64编码[RFC4648]应与application/pkcs10一起使用，尽管任何7位传输编码都可以工作。

2.2. Sending and Receiving an application/pkcs10 Body Part
2.2. 发送和接收应用程序/pkcs10身体部位

For sending a certificate-signing request, the application/pkcs10 message format MUST be used to convey a PKCS #10 certificate-signing request. Note that for sending certificates and Certificate Revocation Lists (CRLs) without any signed content, the application/pkcs7-mime message format MUST be used to convey a degenerate PKCS #7 signedData "certs-only" message [RFC5751].

要发送证书签名请求，必须使用application/pkcs10消息格式传递PKCS#10证书签名请求。请注意，要发送没有任何签名内容的证书和证书吊销列表（CRL），必须使用application/pkcs7 mime消息格式来传递退化的PKCS#7签名数据“仅证书”消息[RFC5751]。

To send an application/pkcs10 body, the application generates the cryptographic information for the user. The details of the cryptographic information are beyond the scope of this memo.

要发送应用程序/pkcs10正文，应用程序将为用户生成加密信息。加密信息的详细信息超出了本备忘录的范围。

Step 1. The cryptographic information is placed within a PKCS #10 CertificationRequest.

第一步。加密信息放在PKCS#10 CertificationRequest中。

Step 2. The CertificationRequest is encoded according to BER or DER (preferred, DER).

第二步。认证请求根据BER或DER（首选，DER）进行编码。

Step 3. As a typical step, the encoded CertificationRequest is also base64 encoded so that it is 7-bit data suitable for transfer in ESMTP. This then becomes the body of an application/pkcs10 body part.

第三步。作为一个典型步骤，编码的CertificationRequest也是base64编码的，因此它是适合在ESMTP中传输的7位数据。这将成为应用程序/pkcs10主体部分的主体。

The result might look like this:

结果可能如下所示： 

      Content-Type: application/pkcs10; name=smime.p10
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p10
        
      Content-Type: application/pkcs10; name=smime.p10
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p10

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V

RFVBNJ756BBGHYHHHHHUJHJH77N8HGT9HG4VQPFYF467N8HGHGHHHHHHHHHHHHHJH4VQPFF467GHIGFHFYGTRFFBNJT6JH7756TBB9H F8HGHGTRFVHJHHJH776BB9HG4VQBNJ7567GHIGFYT6GHYHHHHHHHHJFFFF4 0GhIGfHfQbnj756YT64V

A typical application only needs to send a certification request. It is a Certification Authority that has to receive and process the request. The steps for recovering the CertificationRequest from the message are straightforward but are not presented here. The procedures for processing the certification request are beyond the scope of this document.

典型的应用程序只需要发送一个认证请求。它是必须接收和处理请求的证书颁发机构。从消息中恢复CertificationRequest的步骤很简单，但此处不介绍。处理认证申请的程序超出了本文件的范围。

3. IANA Considerations
3. IANA考虑

IANA has updated the registration for the application/pkcs10 media subtype in the Application Media Types registry using the filled-in template from BCP 13 [RFC4288] given below.

IANA已使用下面给出的BCP 13[RFC4288]中填写的模板更新了应用程序/pkcs10媒体子类型在应用程序媒体类型注册表中的注册。

3.1. Registration of Media Subtype application/pkcs10
3.1. 媒体子类型应用程序/pkcs10的注册

The media subtype for a PKCS #10 certification request is application/pkcs10.

PKCS#10认证请求的媒体子类型为application/pkcs10。

Type name: application

类型名称：应用程序

Subtype name: pkcs10

子类型名称：pkcs10

Required parameters: None

所需参数：无

Optional parameters: None

可选参数：无

Encoding considerations: binary; see Section 2.

编码考虑：二进制；见第2节。

Security considerations:

安全考虑：

Clients use a certification request to request that a Certification Authority certify a public key. The certification request is digitally signed. Also, see Section 6.

客户端使用证书请求请求证书颁发机构认证公钥。认证请求是数字签名的。另见第6节。

Interoperability considerations: See Section 2.

互操作性注意事项：参见第2节。

Published specification: This specification.

已发布规范：本规范。

Applications which use this media type:

使用此媒体类型的应用程序：

Applications that support PKCS #10 certification requests [RFC2986].

支持PKCS#10认证请求的应用程序[RFC2986]。

Additional information:

其他信息： 

         Magic number(s): None
         File extension(s): .p10
        
         Magic number(s): None
         File extension(s): .p10

Macintosh File Type Code(s):

Macintosh文件类型代码： 

      Person & email address to contact for further information:
        Sean Turner <turners@ieca.com>
        
      Person & email address to contact for further information:
        Sean Turner <turners@ieca.com>

Restrictions on usage: none

使用限制：无 

      Author: Sean Turner <turners@ieca.com>
        
      Author: Sean Turner <turners@ieca.com>

Intended usage: COMMON

预期用途：普通

Change controller: The IESG

更改控制器：IESG

4. Security Considerations
4. 安全考虑

The security considerations of [RFC2986] and [RFC5751] apply; no new security considerations are introduced by this document.

[RFC2986]和[RFC5751]的安全考虑适用；本文档没有引入新的安全注意事项。

5. Acknowledgements
5. 致谢

I wish to thank the authors of RFC 2311, Steve Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa Repka.

我要感谢RFC2311的作者史蒂夫·杜塞、保罗·霍夫曼、布莱克·拉姆斯代尔、劳伦斯·伦德布雷德和丽莎·雷普卡。

I would also like to thank Bjoern Hoehrmann for his review of the media subtype application.

我还要感谢Bjoern Hoehrmann对媒体子类型应用程序的审查。

6. References
6. 工具书类
6.1. Normative References
6.1. 规范性引用文件

[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月。

[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.

[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，2000年11月。

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.

[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。

[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。

[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

[X.690]ITU-T建议X.690（2002）| ISO/IEC 8825-1:2002。信息技术.ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）的规范。

6.2. Informative References
6.2. 资料性引用

[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.

[RFC2311]Dusse，S.，Hoffman，P.，Ramsdell，B.，Lundblade，L.，和L.Repka，“S/MIME版本2消息规范”，RFC 23111998年3月。

[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

[RFC2633]Ramsdell，B.，Ed.，“S/MIME版本3消息规范”，RFC 2633，1999年6月。

Author's Address

作者地址

Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA

Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031 

   EMail: turners@ieca.com
        
   EMail: turners@ieca.com