< draft-turner-application-pkcs10-media-type-04.txt   draft-turner-application-pkcs10-media-type-05.txt >
Network Working Group S. Turner Network Working Group S. Turner
Internet Draft IECA Internet Draft IECA
Intended Status: Informational April 22, 2010 Intended Status: Informational May 6, 2010
Updates: 2986 (once approved) Updates: 2986 (once approved)
Expires: October 22, 2010 Expires: November 6, 2010
The application/pkcs10 Media Type The application/pkcs10 Media Type
draft-turner-application-pkcs10-media-type-04.txt draft-turner-application-pkcs10-media-type-05.txt
Abstract Abstract
This document specifies a media type used to carry PKCS#10 This document specifies a media type used to carry PKCS#10
certification requests as defined in RFC 2986. It carries over the certification requests as defined in RFC 2986. It carries over the
original specification from RFC 2311, which recently has been moved original specification from RFC 2311, which recently has been moved
to Historic state, and properly links it to RFC 2986. to Historic state, and properly links it to RFC 2986.
Status of this Memo Status of this Memo
skipping to change at page 2, line 5 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 22, 2010. This Internet-Draft will expire on November 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 46 skipping to change at page 2, line 46
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Creating a Certification Request 2. Creating a Certification Request
A typical application which allows a user to generate cryptographic A typical application which allows a user to generate cryptographic
information has to submit that information to a certification information has to submit that information to a certification
authority (CA), who transforms it into a certificate. PKCS #10 authority (CA), who transforms it into a certificate. PKCS #10
[RFC2986] describes a syntax for certification requests. The [RFC2986] describes a syntax for certification requests. A PKCS #10
application/pkcs10 media type MUST be used to transfer a PKCS #10 certification request MUST use the application/pkcs10 media type.
certification request.
The details of certification requests and the process of obtaining a The details of certification requests and the process of obtaining a
certificate are beyond the scope of this memo. Instead, only the certificate are beyond the scope of this memo. Instead, only the
format of data used in application/pkcs10 is defined. format of data used in application/pkcs10 is defined.
2.1. Format of the application/pkcs10 Body 2.1. Format of the application/pkcs10 Body
PKCS #10 defines the ASN.1 type CertificationRequest for use in PKCS #10 defines the ASN.1 type CertificationRequest for use in
submitting a certification request. For transfer to a CA, this submitting a certification request. For transfer to a CA, this
abstract syntax needs to be encoded and identified in a unique abstract syntax needs to be encoded and identified in a unique
manner. When the media type application/pkcs10 is used, the body manner. When the media type application/pkcs10 is used, the body
MUST be a CertificationRequest, encoded using the Basic Encoding MUST be a CertificationRequest, encoded using the Basic Encoding
Rules (BER) [X.690]. Rules (BER) [X.690].
Although BER is specified, instead of the more restrictive DER Although BER is specified, instead of the more restrictive
[X.690], a typical application will use DER since the Distinguished Encoding Rules (DER) [X.690], a typical application
CertificationRequest's CertificationRequestInfo has to be DER-encoded will use DER since the CertificationRequest's
in order to be signed. CertificationRequestInfo has to be DER-encoded in order to be signed.
A robust application SHOULD output DER, but allow BER or DER on A robust application SHOULD output DER, but allow BER or DER on
input. input.
Data produced by BER or DER is 8-bit, but some transports are limited 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 to 7-bit data. In such cases, a suitable 7-bit transfer encoding MUST
be applied; in MIME-compatible transports, the base64 encoding be applied; in MIME-compatible transports, the base64 encoding
[RFC4648] SHOULD be used with application/pkcs10, although any 7-bit [RFC4648] SHOULD be used with application/pkcs10, although any 7-bit
transfer encoding may work. transfer encoding may work.
skipping to change at page 4, line 24 skipping to change at page 4, line 24
A typical application only needs to send a certification request. It A typical application only needs to send a certification request. It
is a certification authority that has to receive and process the is a certification authority that has to receive and process the
request. The steps for recovering the CertificationRequest from the request. The steps for recovering the CertificationRequest from the
message are straightforward but are not presented here. The message are straightforward but are not presented here. The
procedures for processing the certification request are beyond the procedures for processing the certification request are beyond the
scope of this document. scope of this document.
3. IANA Considerations 3. IANA Considerations
IANA is asked to update the registration for the application/pkcs10 IANA is asked to update the registration for the application/pkcs10
media subtype using the filled-in template from BCP 13 [RFC4288] media subtype in the Application Media Types registry using the
given below. filled-in template from BCP 13 [RFC4288] given below.
3.1. Registration of media subtype application/pkcs10 3.1. Registration of media subtype application/pkcs10
The media subtype for a PKCS#10 certification request is The media subtype for a PKCS#10 certification request is
application/pkcs10. application/pkcs10.
Type name: application Type name: application
Subtype name: pkcs10 Subtype name: pkcs10
skipping to change at page 4, line 50 skipping to change at page 4, line 50
Encoding considerations: binary; See Section 2. Encoding considerations: binary; See Section 2.
Security considerations: Security considerations:
Clients use a certification request to request that a Clients use a certification request to request that a
Certification Authority certify a public key. The certification Certification Authority certify a public key. The certification
request is digitally signed. Also see Section 6. request is digitally signed. Also see Section 6.
Interoperability considerations: See Section 2. Interoperability considerations: See Section 2.
Published specification: [RFC2986] and this specification. Published specification: This specification.
Applications which use this media type: Applications which use this media type:
Applications that support PKCS#10 certification requests Applications that support PKCS#10 certification requests
[RFC2986]. [RFC2986].
Additional information: Additional information:
Magic number(s): None Magic number(s): None
File extension(s): .p10 File extension(s): .p10
 End of changes. 8 change blocks. 
14 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/