Category: Standards Track                      TraceRoute Security, Inc.
Management protocol using the Cryptographic Message Syntax (CMS).
due to algorithm or hardware design.
required by S/MIME and other groups.
round-trips is to be minimized.
Support must exist for the mandatory algorithms used by S/MIME.
The protocol must contain Proof-of-Possession (POP) methods.
how to transport our messages are now found in [CMC-TRANS].
certificate issuance, more than one round-trip is required.
PKI Requests are formed using either the PKCS #10 or CRMF structure.
PKI Responses are based on SignedData or AuthenticatedData [CMS].
this new expanded PKI Request on to the CA.
certificate/certificate revocation list (CRL) retrieval.
document, both RAs and EEs can be clients.
PKI Responses.  In this document, both CAs and RAs can be servers.
[PKCS10], which defines a certification request syntax.
CRMF  refers to the Certificate Request Message Format RFC [CRMF].
document as part of the protocol.
encryption and signing with and without key management.
that they are to the server.
subset of the PKI Requests.
Simple PKI Response  on success.
PKI Response in this case.
services specified in this document.
certification request based on PKCS #10 as an ExtensionReq attribute.
The Full PKI Request provides the most functionality and flexibility.
pending, or if the enrollment failed.
MUST include a Subject Key Identifier extension.
signing, there MUST be only one SignerInfo in the SignedData.
a.  The Password Recipient Info option of RecipientInfo MUST be used.
Authentication Code (MAC) value on the encapsulated content.
the identifier (encoded as UTF8) and the shared-secret.
signing certificate for a client be used.
noKeyReuse as the CMCFailInfo failure code.
request item and no other certification requests are processed.
Section 3.2.1.3 for more details.
any order; the order in the sequence is not significant.
list will be ordered by grouping specific tasks together.
of PKIData if they are present and are not referenced by a control.
and a value based on the object identifier.
bodyPartID  is a unique integer that identifies this control.
attrType    is the OID that identifies the control.
instead it returned a processing error.
The controls defined by this document are found in Section 6.
requirements for clients and servers dealing with CRMF.
tcr  is a certification request that uses the PKCS #10 syntax.
Details on PKCS #10 are found in Section 3.2.1.2.1.
on CRMF are found in Section 3.2.1.2.2.
values are defined outside of this document.
bodyPartID  is the identifier number for this certification request.
Details on body part identifiers are found in Section 3.2.2.
request.  Its fields are described in [PKCS10].
value with the value badRequest.
The fields in CertReqMsg are explained in [CRMF].
MUST override the CRMF control.
in SubsequentMessage MUST NOT be used.
process all extensions defined, but not prohibited in [PKIXCERT].
with the value of unsupportedExt.
identification and the structure to contain the data to be passed.
contentInfo  is a ContentInfo object (defined in [CMS]).
client or no certificate exists for a signing key.
additional controls that need to be processed.
encrypted POP control (see Section 6.7).
The EnvelopedData content type provides for shrouding of data.
provide encryption of an entire PKI Request (see Section 5).
The outer wrapper for a PKI Request.
The outer wrapper for a PKI Response.
bodyPartID  is the unique id identifying this data object.
otherMsgType  is the OID that defines the type of message body.
PKI Request to which the error applies.
removes the encrypted private key before sending it on to the CA.
identifier  is the OID that defines the associated data.
UnauthenticatedAttribute sequence of an AuthenticatedData.
are returned in the certificate field of the SignedData.
the CRL bag.  Servers MAY include the self-signed certificates.
Clients MUST be able to process a Full PKI Response.
to-do list for later processing.
be relied on by generators.
field can be encrypted separately.
Note: PKIResponse can be substituted for PKIData in the above figure.
amalgamate multiple PKI Requests and forward them to a server).
clear.  Servers MUST provide support for all three options.
Controls are carried as part of both Full PKI Requests and Responses.
each of the controls described in this document.
with the single integer of value 1.
status code returned in the cMCStatus field.
if cMCStatus contains the value failed.
queried about the status of the certification request.
set of extended error codes.
control MAY be omitted unless it is the only item in the response.
present only if cMCStatus is failed.
Control) and Section 6.13 (Query Pending Control ).
requester is responsible to poll back on this Full PKI request.
pending may only be returned for certification request operations.
noSupport  indicates the requested operation is not supported.
badAlg  indicates unrecognized or unsupported algorithm.
badMessageCheck  indicates integrity check failed.
badRequest  indicates transaction was not permitted or supported.
supported by the recipient CA.
mustArchiveKeys  indicates private key material must be supplied.
badIdentity  indicates identification control failed to verify.
popFailed  indicates POP processing failed.
noKeyReuse  indicates server policy does not allow key reuse.
time and the client should try at a later time.
ExtendedFailureInfo item in the Extended CMC Status Info control.
However, for closed environments they can be defined using this type.
Such codes MUST be in the range from 1000 to 1999.
identity can be found in Appendix C of [CRMF].
additionally support bilateral methods of similar strength.
the shared-secret is used to compute the Identity Proof control.
witness  is the identity proof.
message and the value from Step 2 as the key.
the Identity Proof Version 2 control.
value contained in the PKI Request.
Response and MUST have a value of badIdentity.
potentially open the door for some types of attacks.
SHA-1 and the MAC algorithm is fixed to HMAC-SHA1.
holder of the hardware token device.
both the POP and proof-of-identity information.
requests from different entities in a single Full PKI Request.
certification request (PKCS #10 or CRMF).
could be a more complex algorithm.
witness  contains the computed witness value.
least 512 bits in length.
using the key computed in Step 2.
included in the controls field of the CertRequest structure.
For this control, SHA-1 is used as the key generation algorithm.
HMAC-SHA1 is used as the mac algorithm.
the shared-secret, in the Full PKI Request.
the server MUST return it as part of the PKI Response.
identifier of a hardware device containing the private key.
modification of subject and/or subject alternative names.
fields in a requested certificate.
certification request(s) to be modified.
a value of badRequest is returned that references this control.
is treated individually rather than as a single unit.
treated as a single field.
are they required to be able to process other, private extensions.
value with the value of unsupportedExt.
should be applied from the innermost layer to the outermost layer.
wrapping layer), the order of application is non-determinate.
certification request other than extensions could be modified.
extensions that are to be included in certificates.
certification request referenced in the certReferences sequence.
opposed to an "all or nothing" approach).
request would be rejected with a CMCFailInfo value of badRequest.
received transaction identifiers in the Full PKI Response.
The Transaction Identifier control identifies a given transaction.
It is used by client and server to manage the state of an operation.
Clients MAY include a Transaction Identifier control in a request.
message associated with the same transaction.
for any element within the PKIData.
here so the client need not keep a copy of the request).
SerialNumber as the bodyPartID of the certification request.
Value to create the field witness.
witness  is the hashed value of the POP Proof Value.
3.  The client decrypts the cms field to obtain the POP Proof Value.
thePOPAlgID  is copied from the encryptedPOP.
thePOPAlgID using the POP Proof Value and the request.
that a CA needs to keep in order to verify the returned POP value.
(or small set) of values.
1.  Server generates random seed x, constant across all requests.
Witness control addresses this issue.
TaggedContentInfo containing the client's Full PKI Request.
verification, it returns a CMCFailInfo with the value of popFailed.
Everything described in this section is optional to implement.
directory is either infeasible or undesirable.
issuerName  is the name of the certificate issuer.
serialNumber  identifies the certificate to be retrieved.
response should be a Simple PKI Response.
where a fully deployed directory is either infeasible or undesirable.
issuerName  is the name of the CRL issuer.
not contain such a value.
component, the CA always returns with the most recent CRL.
single CRL can aggregate information for one or more reasonFlags.
issuerName  is the issuerName of the certificate to be revoked.
serialNumber  is the serial number of the certificate to be revoked.
in the event of key loss.
comment  is a human-readable comment.
assigned the ability to revoke the certificate of a third party.
capable of accepting both forms of revocation requests.
secret after the certificate has been revoked is not a problem.
be used for multiple certificates.
A Full PKI Response MUST be returned for a revocation request.
additional information as part of a Full PKI Request.
information as part of a Full PKI Response.
1.  The client sends the certification request to the CA.
CMC Status Info of success.
validation algorithm in Section 6.1.1 of [PKIXCERT].
field.  All implementations MUST implement SHA-1 for this field.
certificates should be obtainable using normal discovery techniques.
Authenticated Data structure to allow for validation of the data.
(Section 6.15), but it may be used in other cases as well.
requests are not propagated up to the top level.
after which the client should ask for the additional results.
processed if a certificate failed to be issued.
-- pubInfos MUST NOT be present if action is "dontPublish"
compute the values in certHashes.
certificate if it is already published.
results in the same behavior.
PKI SHOULD publish the certificate.
attempting to deal with a control not defined in this document.
request on to the next server in the processing list.
o  Routing requests to different CAs.
existing layers and add a new wrapping layer.
in the RA's PKIData object along with all relevant controls.
lead to multiple wrapping layers on the request.
encryption layers and signing layers need to be removed.
NOT remove a signing layer from a PKI Request.
layer provided by the RA.
used to encrypt the private key material.
of this attack when doing parameter validations.
anchor accepted by the client the source of the trust anchor.
MACs in this document the following restrictions need to be observed.
can generate messages that will have a successful MAC validation.
This means that care must be taken to keep this value secret.
preference to the AuthenticatedData structure.
the original versions of this document.
Message Format", RFC 4211, January 2005.
Proof-of-Possession Algorithms", RFC 2875, June 2000.
v1.5", RFC 2314, October 1997.
to update to use 2003 ASN.1 syntax.
CMS (CMC): Transport Protocols", RFC 5273, June 2008.
Authentication Guideline", NIST SP 800-63, April 2006.
-- The content of this type conforms to RFC 2279.
-- The spelling of unsupportedExt is corrected in this version.
-- In RFC 2797, it was unsuportedExt.
--  Unauthenticated attribute to carry removable data.
between the client and server for several different common cases.
will modify the certification request before passing it on to the CA.
which is not displayed above.
certification requester already has a signing-only certificate.
POP exists for the certification request.
but can be used to produce the necessary signature value.
defined in Section 6.7 MUST be used.