Technical Summary
This document allows the IANA registration to point to an active
document. The application/pkcs10 media type was originally part of
S/MIMEv2 [RFC2311], which was not the product of an IETF WG, along with
application/pkcs7-mime and application/pkcs7-signature. When the SMIME
WG produced S/MIMEv3 [RFC2633], it did not include the
application/pkcs10 text and unfortunately when PKCS#10 was published as
RFC 2986 the application/pkcs10 text was not incorporated there .
Recently, S/MIMEv3.2 was published and S/MIMEv2 was moved to historic.
This means that the IANA registration no longer points to an active
document. This document fills that role with text for
application/pkcs10 adapted from RFC 2311 and an IANA registration
request for application/pkcs10.
Working Group Summary
This document is not the product of an IETF Working Group.
Document Quality
The text for formation of the application/pkcs10 media type is adapted
from RFC 2311. Only minor changes were made, as can be seen in the
diffs between version -00 and -01.
Personnel
Russ Housley is the document Shepherd. Tim Polk is the
responsible Security Area AD.
RFC Editor Note
In Section 2.1, please make the following substitution:
OLD:
When the media type application/pkcs10 is used, the body MUST be a
CertificationRequest, encoded using the Basic Encoding Rules (BER)
[X.690].
Although BER is specified, instead of the more restrictive
Distinguished Encoding Rules (DER) [X.690], a typical application will
use DER since the CertificationRequest's CertificationRequestInfo has
to be DER-encoded in order to be signed.
A robust application SHOULD output DER, but allow BER or DER on input.
NEW:
When the media type application/pkcs10 is used, the body MUST be a
CertificationRequest.
A robust application SHOULD output DER, but allow BER or DER on input.