doc: Add RFC documents

1 files changed, 2075 insertions, 0 deletions

diff --git a/doc/rfc/rfc6402.txt b/doc/rfc/rfc6402.txt
new file mode 100644
index 0000000..0aaafec
--- /dev/null
+++ b/doc/rfc/rfc6402.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         J. Schaad
+Request for Comments: 6402                       Soaring Hawk Consulting
+Updates: 5272, 5273, 5274                                  November 2011
+Category: Standards Track
+ISSN: 2070-1721
+
+
+             Certificate Management over CMS (CMC) Updates
+
+Abstract
+
+   This document contains a set of updates to the base syntax for CMC, a
+   Certificate Management protocol using the Cryptographic Message
+   Syntax (CMS).  This document updates RFC 5272, RFC 5273, and RFC
+   5274.
+
+   The new items in this document are: new controls for future work in
+   doing server side key generation, definition of a Subject Information
+   Access value to identify CMC servers, and the registration of a port
+   number for TCP/IP for the CMC service to run on.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   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/rfc6402.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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
+
+
+
+
+
+Schaad                       Standards Track                    [Page 1]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+   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.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Requirements Terminology . . . . . . . . . . . . . . . . .  3
+     1.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Updates to RFC 5272 - "Certificate Management over CMS
+       (CMC)" . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  New Section 1.3 - "Updates Made by RFC 6402" . . . . . . .  3
+     2.2.  Update Section 6 - "Controls"  . . . . . . . . . . . . . .  4
+     2.3.  Replace Section 6.3 - "Linking Identity and POP
+           Information" . . . . . . . . . . . . . . . . . . . . . . .  4
+     2.4.  Replace Section 6.3.3 - "Renewal and Rekey Messages" . . .  5
+     2.5.  New Section 6.20 - "RA Identity Proof Witness Control" . .  5
+     2.6.  New Section 6.21 - "Response Body Control" . . . . . . . .  7
+     2.7.  New Section 7 - "Other Attributes" . . . . . . . . . . . .  8
+     2.8.  New Section 7.1 - "Change Subject Name Attribute"  . . . .  8
+     2.9.  New Section 9 - "Certificate Requirements" . . . . . . . . 10
+     2.10. New Section 9.1 - "Extended Key Usage" . . . . . . . . . . 10
+     2.11. New Section 9.2 - "Subject Information Access" . . . . . . 11
+     2.12. Update Section 8 - "Security Considerations" . . . . . . . 11
+   3.  Updates to RFC 5273 - "Certificate Management over CMS
+       (CMC): Transport Protocols"  . . . . . . . . . . . . . . . . . 12
+     3.1.  Update Section 5 - "TCP-Based Protocol"  . . . . . . . . . 12
+     3.2.  New Section 6 - "IANA Considerations"  . . . . . . . . . . 12
+   4.  Updates to RFC 5274 - "Certificate Management Message over
+       CMS (CMC): Compliance Requirements"  . . . . . . . . . . . . . 13
+     4.1.  Update to Section 4.2 - "Controls" . . . . . . . . . . . . 13
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 14
+   Appendix A.  ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 15
+     A.1.  1988 ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 15
+     A.2.  2008 ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+
+
+
+
+
+
+
+
+
+Schaad                       Standards Track                    [Page 2]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+1.  Introduction
+
+   While dealing with the Suite B profile of CMC [RFC6403], a number of
+   deficiencies were noted in the current base CMC specification.  This
+   document has a set of updates to [RFC5272], [RFC5273], and [RFC5274]
+   to deal with those issues.
+
+1.1.  Requirements Terminology
+
+   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].
+
+1.2.  Abbreviations
+
+   The following abbreviations are used in this document.  Terms are
+   used as defined in Section 2.1 of RFC 5272.
+
+      CA   - Certification Authority
+      CRL  - Certificate Revocation List
+      CRMF - Certificate Request Message Format
+      EE   - End-Entity
+      MAC  - Message Authentication Code
+      PKI  - Public Key Infrastructure
+      RA   - Registration Authority
+
+2.  Updates to RFC 5272 - "Certificate Management over CMS (CMC)"
+
+2.1.  New Section 1.3 - "Updates Made by RFC 6402"
+
+   Insert this section before the current Section 1.3.
+
+   The following updates were made by RFC 6402.
+
+   o  Add new controls:
+
+      RA Identity Witness  allows for an RA to perform identity checking
+         using the identity and shared-secret, and then tell any
+         following servers that the identity check was successfully
+         performed.
+
+      Response Body  allows for an RA to identify a nested response for
+         an EE to process.
+
+   o  Create a new attribute, Change Subject Name, that allows a client
+      to request a change in the subject name and subject alternate name
+      fields in a certificate.
+
+
+
+
+Schaad                       Standards Track                    [Page 3]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+   o  Add Extended Key Usages for CMC to distinguish server types.
+
+   o  Define a new Subject Information Access type to hold locations to
+      contact the CMC server.
+
+   o  Clarify that the use of a pre-existing certificate is not limited
+      to just renewal and rekey messages and is required for support.
+      This formalizes a requirement for the ability to do renewal and
+      rekey that previously was implicit.
+
+2.2.  Update Section 6 - "Controls"
+
+   Update Table 1 by adding the following rows:
+
+   +--------------------------+-----------+-----------------+---------+
+   | Identifier Description   | OID       | ASN.1 Structure | Section |
+   +--------------------------+-----------+-----------------+---------+
+   | id-cmc-raIdentityWitness | id-cmc 35 | BodyPartPath    | 6.20    |
+   |                          |           |                 |         |
+   | id-cmc-responseBody      | id-cmc 37 | BodyPartPath    | 6.21    |
+   +--------------------------+-----------+-----------------+---------+
+
+                Addition to Table 1: CMC Control Attributes
+
+2.3.  Replace Section 6.3 - "Linking Identity and POP Information"
+
+   Replace the text of the section with the following text.
+
+   In a CMC Full PKI Request, identity proof information about the
+   client is carried in the certificate associated with the signature of
+   the SignedData containing the certification requests, one of the two
+   identity proof controls or the MAC computed for the AuthenticatedData
+   containing the certification requests.  Proof-of-possession (POP)
+   information for key pairs, however, is carried separately for each
+   PKCS #10 or CRMF certification request.  (For keys capable of
+   generating a digital signature, the POP is provided by the signature
+   on the PKCS #10 or CRMF request.  For encryption-only keys, the
+   controls described in Section 6.7 are used.)  In order to prevent
+   substitution-style attacks, the protocol must guarantee that the same
+   entity supplied both the POP and proof-of-identity information.
+
+   We describe three mechanisms for linking identity and POP
+   information: witness values cryptographically derived from a shared-
+   secret (Section 6.3.1), shared-secret/subject name matching (Section
+   6.3.2), and subject name matching to an existing certificate (Section
+   6.3.3).  Clients and servers MUST support the witness value and the
+   certificate linking techniques.  Clients and servers MAY support
+   shared-secret/name matching or MAY support other bilateral techniques
+
+
+
+Schaad                       Standards Track                    [Page 4]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+   of similar strength.  The idea behind the first two mechanisms is to
+   force the client to sign some data into each certification request
+   that can be directly associated with the shared-secret; this will
+   defeat attempts to include certification requests from different
+   entities in a single Full PKI Request.
+
+2.4.  Replace Section 6.3.3 - "Renewal and Rekey Messages"
+
+   Make the new section title "Existing Certificate Linking".  Replace
+   all text in this section with this text.
+
+   Linking between the POP and an identity is easy when an existing
+   certificate is used.  The client copies all of the naming information
+   from the existing certificate (subject name and subject alternative
+   name) into the new certification request.  The POP on the new public
+   key is then performed by using the new key to sign the identity
+   information (linking the POP to a specific identity).  The identity
+   information is then tied to the POP information by signing the entire
+   enrollment request with the private key of the existing certificate.
+
+   Existing certificate linking can be used in the following
+   circumstances:
+
+      When replacing a certificate by doing a renewal or rekey
+      certification request.
+
+      Using an existing certificate to get a new certificate.  An
+      example of this would be to get a key establishment certificate
+      after having gotten a signature certificate.
+
+      Using a third-party certificate to get a new certificate from a
+      CA.  An example of this would be using a certificate and key pair
+      distributed with a device to prove an identity.  This requires
+      that the CA have an out-of-band channel to map the identity in the
+      device certificate to the new EE identity.
+
+2.5.  New Section 6.20 - "RA Identity Proof Witness Control"
+
+   Insert this section.
+
+   The RA Identity Proof Witness control allows an RA to indicate to
+   subsequent control processors that all of the identity proof
+   requirements have been met.  This permits the identity proof to be
+   performed at a location closer to the end-entity.  For example, the
+   identity proof could be done at multiple physical locations, while
+   the CA could operate on a company-wide basis.  The RA performs the
+   identity proof, and potentially other tasks that require the secret
+
+
+
+
+Schaad                       Standards Track                    [Page 5]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+   to be used, while the CA is prevented from knowing the secret.  If
+   the identity proof fails, then the RA returns an error to the client
+   denoting that fact.
+
+   The relevant ASN.1 for the RA Identity Proof Witness control is as
+   follows:
+
+      cmc-raIdentityWitness CMC-CONTROL ::=
+         { BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness }
+
+      id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35}
+
+   The above ASN.1 defines the following items:
+
+   cmc-raIdentityWitness  is a CMC-CONTROL associating the object
+      identifier id-cmc-raIdentityWitness and the type BodyPartPath.
+      This object is omitted from the 1988 module.  The object is added
+      to the object set Cmc-Control-Set.  The control is permitted to
+      appear only in the control sequence of a PKIData object.  It MUST
+      NOT appear in the control sequence of a PKIResponse.  The control
+      is permitted to be used only by an RA.  The control may appear
+      multiple times in a control sequence with each occurrence pointing
+      to a different object.
+
+   id-cmc-raIdentityWitness  is the object identifier used to identify
+      this CMC control.
+
+   BodyPartPath  is the type structure associated with the control.  The
+      syntax of BodyPartPath is defined in Section 3.2.2.  The path
+      contains a sequence of body part identifiers leading to one of the
+      following items:
+
+      Identity Proof control  if the RA verified the identity proof in
+         this control.
+
+      Identity Proof Version 2 control  if the RA verified the identity
+         proof in this control.
+
+      Full PKI Request  if the RA performed an out-of-band identity
+         proof for this request.  The request SHOULD NOT contain either
+         Identity Proof control.
+
+      Simple PKI Request  if the RA performed an out-of-band identity
+         proof for this request.
+
+   The RA Identity Proof Witness control will frequently be associated
+   with a Modify Certification Request control, which changes the name
+   fields in the associated certification requests.  This is because the
+
+
+
+Schaad                       Standards Track                    [Page 6]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+   RA knows the actual name to be assigned to the entity requesting the
+   certificate, and the end-entity does not yet have the details of the
+   name.  (The association would be set up by the operator at the time
+   the shared-secret was generated by the RA.)
+
+   When this control is placed in a message, it is RECOMMENDED that the
+   Control Processed control be placed in the body sequence as well.
+   Using the explicit new control, rather than implicitly relying on the
+   Control Processed control is important due to the need to know
+   explicitly which identity proofs have been performed.  The new
+   control also allows an RA to state that out-of-band identity proofs
+   have been performed.
+
+   When the identity proof is performed by an RA, the RA also MUST
+   validate the linking between the identity proof and the name
+   information wrapped inside of the key proof-of-possession.
+
+2.6.  New Section 6.21 - "Response Body Control"
+
+   Insert this section.
+
+   The Response Body Control is designed to enable an RA to inform an EE
+   that there is an embedded response message that MUST be processed as
+   part of the processing of this message.  This control is designed to
+   be used in a couple of different cases where an RA has done some
+   additional processing for the certification request, e.g., as key
+   generation.  When an RA performs key generation on behalf of an EE,
+   the RA MUST respond with both the original response message from the
+   certificate issuer (containing the certificate issuance) as part of
+   the response generated by the RA (containing the new key).  Another
+   case where this is useful is when the secret is shared between the RA
+   and the EE (rather than between the CA and the EE) and the RA returns
+   the Publish Trust Anchors control (to populate the correct trust
+   points).
+
+   The relevant ASN.1 for the Response Body Control is as follows:
+
+     cmc-responseBody CMC-CONTROL ::= {
+        BodyPartPath IDENTIFIED BY id-cmc-responseBody
+     }
+
+     id-cmc-responseBody OBJECT IDENTIFIER ::= {id-cmc 37}
+
+
+
+
+
+
+
+
+
+Schaad                       Standards Track                    [Page 7]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+   The above ASN.1 defines the following items:
+
+   cmc-responseBody  is a CMC-CONTROL associating the object identifier
+      id-cmc-responseBody with the type BodyPartPath.  This object is
+      omitted from the 1988 module.  The object is added to the object
+      set Cmc-Control-Set.  The control is permitted to appear only in
+      the control sequence of a PKIResponse.  The control MUST NOT
+      appear in the control sequence of a PKIData.  It is expected that
+      only an intermediary RA will use this control; a CA generally does
+      not need the control as it is creating the original innermost
+      message.
+
+   id-cmc-responseBody  is the object identifier used to identify this
+      CMC control.
+
+   BodyPartPath  is the type structure associated with the control.  The
+      syntax of BodyPartPath is defined in Section 3.2.2.  The path
+      contains a sequence of body part identifiers leading to a
+      cmsSequence item which contains a PKIResponse within it.
+
+2.7.  New Section 7 - "Other Attributes"
+
+   Insert this section before the current Section 7.
+
+   There are a number of different locations where various types of
+   attributes can be placed in either a CMC request or a CMC response
+   message.  These places include the attribute sequence of a PKCS #10
+   request, controls in CRMF (Section 6 of [RFC4211]), and the various
+   CMS attribute sequences.
+
+2.8.  New Section 7.1 - "Change Subject Name Attribute"
+
+   Insert this section.
+
+   The Client Name Change Request attribute is designed for a client to
+   ask for a change in its name as part of a certification request.
+   Because of security issues, this cannot be done in the simple way of
+   just changing the requested subject name in the certificate template.
+   The name in the certification request MUST match the name in the
+   certificate used to verify the request, in order that identity and
+   possession proofs are correctly applied.
+
+
+
+
+
+
+
+
+
+
+Schaad                       Standards Track                    [Page 8]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+   The relevant ASN.1 for the Client Name Change Request attribute is as
+   follows:
+
+      at-cmc-changeSubjectName ATTRIBUTE ::=
+         { ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }
+
+      id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc 36}
+
+      ChangeSubjectName ::= SEQUENCE {
+          subject             Name OPTIONAL,
+          subjectAlt          SubjectAltName OPTIONAL
+      }
+      (WITH COMPONENTS {..., subject PRESENT} |
+            COMPONENTS {..., subjectAlt PRESENT} )
+
+   The attribute is designed to be used as an ATTRIBUTE object.  As
+   such, the attribute is placed in one of the following two places:
+
+      The attributes field in a CertificationRequest.
+
+      The controls field of a CertRequest for a CRMF certification
+      request.
+
+   The control is identified by the Object Identifier
+   id-cmc-changeSubjectName.
+
+   The ASN.1 type associated with control is ChangeSubjectName.  The
+   fields of the structure are configured as follows:
+
+   subject  contains the requested subject name for the new certificate.
+
+   subjectAlt  contains the requested subject alternative name for the
+      new certificate.
+
+   At least one of the fields in the sequence MUST be present when
+   encoding the structure.
+
+   When the CA processes this attribute in a certification request, it
+   will do the following:
+
+   1.  If present, the subject field is copied to the name field of the
+       template.  If the subject field is absent, the name field of the
+       template will be set to a empty sequence.
+
+   2.  If present, the subjectAlt field is used as the content of a
+       SubjectAltName extension in the certificate.  If the subjectAlt
+       field is absent, the subjectAltName extension is removed from the
+       certificate template.
+
+
+
+Schaad                       Standards Track                    [Page 9]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+2.9.  New Section 9 - "Certificate Requirements"
+
+   Insert this section before the current Section 8.
+
+   Certificates for servers used in the CMC protocol SHOULD conform to
+   the profile defined in [RFC5280].  This document defines some
+   additional items that MAY appear in CMC server certificates.  Section
+   9.1 defines some additional values for the Extended Key Usage
+   extension.  Section 9.2 defines a new Subject Information Access
+   value that allows for a CMC certificate to publish information on how
+   to contact the services it provides.
+
+2.10.  New Section 9.1 - "Extended Key Usage"
+
+   Insert this section.
+
+   The Extended Key Usage (EKU) extension is used to restrict the use of
+   a certificate to specific applications.  We define three different
+   EKUs in this document.  The ASN.1 to define these EKUs is:
+
+      id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
+      id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
+      id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 }
+
+   The usage description for each of the EKUs is as follows:
+
+   CMC Certification Authorities  are identified by the id-kp-cmcCA
+      extended key usage.  The certificate may be the same as or
+      different than the CA certificate.  If a different certificate is
+      used, the certificates containing the id-kp-cmcCA extended key
+      usage SHOULD have the same name as the certificate used for
+      issuing the certificates.  (Using a separate key pair for CMC
+      protocol operations and for issuing certificates and CRLs
+      decreases the number of operations for which the private key used
+      to sign certificates and CRLs would be used.)
+
+   CMC Registration Authorities  are identified by the id-kp-cmcRA
+      extended key usage.  This usage is placed into RA certificates.
+
+   CMC Archive Servers  are identified by the id-kp-cmcArchive extended
+      key usage.  CMC Archive Servers and the associated protocol are to
+      be defined in a future document.
+
+
+
+
+
+
+
+
+
+Schaad                       Standards Track                   [Page 10]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+2.11.  New Section 9.2 - "Subject Information Access"
+
+   Insert this section.
+
+   The subject information access extension indicates how to access
+   information and services for the subject of the certificate.  We
+   define a new value for use in this extension, to identify the
+   different locations that CMC services will be available.  If this
+   value is placed in a certificate, an appropriate extended key usage
+   defined in Section 9.1 MUST be included in the certificate as well.
+
+   The id-ad-cmc OID is used when the subject offers certification
+   services using the CMC protocol.  If the CMC services are available
+   via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier.
+   If the CMC services are available via electronic mail, accessLocation
+   MUST be an rfc822Name.  If CMC services are available using TCP/IP,
+   the dNSName or iPAddress name forms MUST be used.  Since the
+   GeneralName data structure does not permit the inclusion of a port
+   number, in the absence of other external configuration information,
+   the value of 5318 should be used.  (The port registration is in
+   Section 3.2.)  The semantics of other name forms of accessLocation
+   (when accessMethod is id-ad-cmc) are not defined by this
+   specification.
+
+   The ASN.1 type for this extension is GeneralName (see Section 4.2.1.8
+   of [RFC5280]).
+
+   id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }
+
+2.12.  Update Section 8 - "Security Considerations"
+
+   Add the following paragraphs to the end of Section 8.
+
+   A number of controls such as the RA Identity Proof Witness control
+   exist for an RA to either make assertions about or modify a
+   certification request.  Any upstream request processor, such as a CA,
+   MUST verify that the RA is fully identified and authorized to make
+   the assertion or modification it is claiming.  If it is not
+   identified or authorized, then any request MUST be rejected.
+
+   CMC servers, both RAs and CAs, need to perform due diligence in
+   checking the contents of a certification request.  At an absolute
+   minimum, all fields should be checked to ensure that the policies of
+   the CA/RA are correctly enforced.  While all fields need to be
+   checked, special care should be taken with names, name forms,
+   algorithm choices, and algorithm parameters.
+
+
+
+
+
+Schaad                       Standards Track                   [Page 11]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+3.  Updates to RFC 5273 - "Certificate Management over CMS (CMC):
+    Transport Protocols"
+
+3.1.  Update Section 5 - "TCP-Based Protocol"
+
+   Replace paragraph 3 in Section 5 with the following.
+
+   CMC requires a registered port number to send and receive CMC
+   messages over TCP.  The title of this IP Protocol number is
+   "pkix-cmc".  The value of this TCP port is 5318.
+
+   Prior to this update, CMC did not have a registered port number and
+   used an externally configured port from the Private Port range.
+   Client implementations MAY want to continue to allow for this to
+   occur.  Servers SHOULD change to use the new port.  It is expected
+   that HTTP will continue to be the primary transport method used by
+   CMC installations.
+
+3.2.  New Section 6 - "IANA Considerations"
+
+   Insert this new section before the current Section 6.
+
+   IANA has assigned a TCP port number in the Registered Port Number
+   range for the use of CMC.
+
+   Service name: pkix-cmc
+   Port Number: 5318
+   Transport protocol: TCP
+   Description: PKIX Certificate Management using CMS (CMC)
+   Reference: RFC 6402
+   Assignee: iesg@ietf.org
+   Contact: chair@ietf.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schaad                       Standards Track                   [Page 12]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+4.  Updates to RFC 5274 - "Certificate Management Message over CMS
+    (CMC): Compliance Requirements"
+
+4.1.  Update to Section 4.2 - "Controls"
+
+   Add the following lines to the end of Table 1.
+
+   The following table lists the name and level of support required for
+   each control.
+
+             +---------------------------+-----+------+-----+
+             | Control                   | EE  | RA   | CA  |
+             +---------------------------+-----+------+-----+
+             | RA Identity Proof Witness | N/A | MUST | (2) |
+             |                           |     |      |     |
+             | Response Body             | (6) | (6)  | N/A |
+             +---------------------------+-----+------+-----+
+
+                Addition to Table 1: CMC Control Attributes
+
+   The following note should be added.
+
+   6. EE's SHOULD implement if designed to work with RAs and MUST
+      implement if intended to be used in environments where RAs are
+      used for identity validation or key generation.  RAs SHOULD
+      implement and validate responses for consistency.
+
+5.  IANA Considerations
+
+   This document contains a new IANA Considerations section to be added
+   to [RFC5273] as part of this update.
+
+6.  Security Considerations
+
+   No changes are made to the existing security considerations of RFC
+   5273 and RFC 5274.  The security considerations for RFC 5272 have
+   been slightly modified (Section 2.12).
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5272]     Schaad, J. and M. Myers, "Certificate Management over
+                 CMS (CMC)", RFC 5272, June 2008.
+
+
+
+
+Schaad                       Standards Track                   [Page 13]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+   [RFC5273]     Schaad, J. and M. Myers, "Certificate Management over
+                 CMS (CMC): Transport Protocols", RFC 5273, June 2008.
+
+   [RFC5274]     Schaad, J. and M. Myers, "Certificate Management
+                 Messages over CMS (CMC): Compliance Requirements",
+                 RFC 5274, June 2008.
+
+   [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.
+
+7.2.  Informative References
+
+   [CMS]         Housley, R., "Cryptographic Message Syntax (CMS)",
+                 STD 70, RFC 5652, September 2009.
+
+   [RFC6403]     Zieglar, L., Turner, S., and M. Peck, "Suite B Profile
+                 of Certificate Management over CMS", RFC 6403, November
+                 2011.
+
+   [RFC4211]     Schaad, J., "Internet X.509 Public Key Infrastructure
+                 Certificate Request Message Format (CRMF)", RFC 4211,
+                 September 2005.
+
+   [RFC5912]     Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
+                 Public Key Infrastructure Using X.509 (PKIX)",
+                 RFC 5912, June 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schaad                       Standards Track                   [Page 14]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+Appendix A.  ASN.1 Modules
+
+A.1.  1988 ASN.1 Module
+
+   This section contains the updated ASN.1 module for [RFC5272].  This
+   module replaces the module in Appendix A of that document.  Although
+   a 2008 ASN.1 module is provided, this remains the normative module as
+   per the policy of the PKIX working group.
+
+   EnrollmentMessageSyntax-2011-v88
+    { iso(1) identified-organization(3) dod(6) internet(1)
+      security(5) mechanisms(5) pkix(7) id-mod(0)
+      id-mod-enrollMsgSyntax-2011-88(76) }
+
+   DEFINITIONS IMPLICIT TAGS ::=
+   BEGIN
+
+    -- EXPORTS All --
+    -- The types and values defined in this module are exported for use
+    -- in the other ASN.1 modules.  Other applications may use them for
+    -- their own purposes.
+
+    IMPORTS
+
+      -- PKIX Part 1 - Implicit    From [RFC5280]
+         GeneralName, CRLReason, ReasonFlags, GeneralNames
+         FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
+                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                 id-pkix1-implicit(19)}
+
+      -- PKIX Part 1 - Explicit    From [RFC5280]
+         AlgorithmIdentifier, Extension, Name, CertificateSerialNumber,
+         id-ad, id-kp
+         FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
+                 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+                 id-pkix1-explicit(18)}
+
+      -- Cryptographic Message Syntax   FROM [CMS]
+         ContentInfo, Attribute, IssuerAndSerialNumber
+           FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
+                us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
+                modules(0) cms-2004(24)}
+
+    -- CRMF                         FROM [RFC4211]
+       CertReqMsg, PKIPublicationInfo, CertTemplate
+       FROM PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6)
+              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+              id-mod-crmf2005(36)};
+
+
+
+Schaad                       Standards Track                   [Page 15]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+      -- Global Types
+         -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
+           -- The content of this type conforms to RFC 3629.
+
+     id-pkix OBJECT IDENTIFIER  ::= { iso(1) identified-organization(3)
+         dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
+
+    id-cmc OBJECT IDENTIFIER ::= {id-pkix 7}   -- CMC controls
+    id-cct OBJECT IDENTIFIER ::= {id-pkix 12}  -- CMC content types
+
+    -- The following controls have the type OCTET STRING
+
+    id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
+    id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
+    id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
+    id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
+    id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
+    id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22}
+    id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23}
+
+    -- The following controls have the type UTF8String
+
+    id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
+
+    -- The following controls have the type INTEGER
+
+    id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
+
+    -- The following controls have the type OCTET STRING
+
+    id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
+    id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
+
+    -- This is the content type used for a request message
+    --     in the protocol
+
+    id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
+
+    PKIData ::= SEQUENCE {
+        controlSequence    SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
+        reqSequence        SEQUENCE SIZE(0..MAX) OF TaggedRequest,
+        cmsSequence        SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
+        otherMsgSequence   SEQUENCE SIZE(0..MAX) OF OtherMsg
+    }
+
+     bodyIdMax INTEGER ::= 4294967295
+
+     BodyPartID ::= INTEGER(0..bodyIdMax)
+
+
+
+Schaad                       Standards Track                   [Page 16]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+    TaggedAttribute ::= SEQUENCE {
+        bodyPartID         BodyPartID,
+        attrType           OBJECT IDENTIFIER,
+        attrValues         SET OF AttributeValue
+    }
+
+     AttributeValue ::= ANY
+
+     TaggedRequest ::= CHOICE {
+         tcr               [0] TaggedCertificationRequest,
+         crm               [1] CertReqMsg,
+         orm               [2] SEQUENCE {
+             bodyPartID            BodyPartID,
+             requestMessageType    OBJECT IDENTIFIER,
+             requestMessageValue   ANY DEFINED BY requestMessageType
+         }
+     }
+
+     TaggedCertificationRequest ::= SEQUENCE {
+         bodyPartID            BodyPartID,
+         certificationRequest  CertificationRequest
+     }
+
+     CertificationRequest ::= SEQUENCE {
+       certificationRequestInfo  SEQUENCE {
+         version                   INTEGER,
+         subject                   Name,
+         subjectPublicKeyInfo      SEQUENCE {
+           algorithm                 AlgorithmIdentifier,
+           subjectPublicKey          BIT STRING },
+         attributes                [0] IMPLICIT SET OF Attribute },
+       signatureAlgorithm        AlgorithmIdentifier,
+       signature                 BIT STRING
+     }
+
+    TaggedContentInfo ::= SEQUENCE {
+        bodyPartID              BodyPartID,
+        contentInfo             ContentInfo
+    }
+
+    OtherMsg ::= SEQUENCE {
+        bodyPartID        BodyPartID,
+        otherMsgType      OBJECT IDENTIFIER,
+        otherMsgValue     ANY DEFINED BY otherMsgType }
+
+    --  This defines the response message in the protocol
+    id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
+
+
+
+
+Schaad                       Standards Track                   [Page 17]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+    ResponseBody ::= PKIResponse
+
+    PKIResponse ::= SEQUENCE {
+        controlSequence   SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
+        cmsSequence       SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
+        otherMsgSequence  SEQUENCE SIZE(0..MAX) OF OtherMsg
+
+    }
+
+    -- Used to return status state in a response
+
+    id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
+
+    CMCStatusInfo ::= SEQUENCE {
+        cMCStatus       CMCStatus,
+        bodyList        SEQUENCE SIZE (1..MAX) OF BodyPartID,
+        statusString    UTF8String OPTIONAL,
+        otherInfo        CHOICE {
+          failInfo         CMCFailInfo,
+          pendInfo         PendInfo } OPTIONAL
+    }
+
+    PendInfo ::= SEQUENCE {
+        pendToken        OCTET STRING,
+        pendTime         GeneralizedTime
+    }
+
+    CMCStatus ::= INTEGER {
+        success         (0),
+        failed          (2),
+        pending         (3),
+        noSupport       (4),
+        confirmRequired (5),
+        popRequired     (6),
+        partial                (7)
+    }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schaad                       Standards Track                   [Page 18]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+    -- Note:
+    -- The spelling of unsupportedExt is corrected in this version.
+    -- In RFC 2797, it was unsuportedExt.
+
+    CMCFailInfo ::= INTEGER {
+        badAlg          (0),
+        badMessageCheck (1),
+        badRequest      (2),
+        badTime         (3),
+        badCertId       (4),
+        unsupportedExt  (5),
+        mustArchiveKeys (6),
+        badIdentity     (7),
+        popRequired     (8),
+        popFailed       (9),
+        noKeyReuse      (10),
+        internalCAError (11),
+        tryLater        (12),
+        authDataFail    (13)
+    }
+
+    -- Used for RAs to add extensions to certification requests
+    id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
+
+    AddExtensions ::= SEQUENCE {
+        pkiDataReference    BodyPartID,
+        certReferences      SEQUENCE OF BodyPartID,
+        extensions          SEQUENCE OF Extension
+    }
+
+
+    id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
+    id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
+
+    EncryptedPOP ::= SEQUENCE {
+        request       TaggedRequest,
+        cms             ContentInfo,
+        thePOPAlgID     AlgorithmIdentifier,
+        witnessAlgID    AlgorithmIdentifier,
+        witness         OCTET STRING
+    }
+
+    DecryptedPOP ::= SEQUENCE {
+        bodyPartID      BodyPartID,
+        thePOPAlgID     AlgorithmIdentifier,
+        thePOP          OCTET STRING
+    }
+
+
+
+
+Schaad                       Standards Track                   [Page 19]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+     id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
+
+     LraPopWitness ::= SEQUENCE {
+         pkiDataBodyid   BodyPartID,
+         bodyIds         SEQUENCE OF BodyPartID
+     }
+
+    --
+    id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
+
+    GetCert ::= SEQUENCE {
+        issuerName      GeneralName,
+        serialNumber    INTEGER }
+
+    id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
+
+    GetCRL ::= SEQUENCE {
+        issuerName    Name,
+        cRLName       GeneralName OPTIONAL,
+        time          GeneralizedTime OPTIONAL,
+        reasons       ReasonFlags OPTIONAL }
+
+    id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
+
+    RevokeRequest ::= SEQUENCE {
+        issuerName            Name,
+        serialNumber          INTEGER,
+        reason                CRLReason,
+        invalidityDate        GeneralizedTime OPTIONAL,
+        passphrase            OCTET STRING OPTIONAL,
+        comment               UTF8String OPTIONAL }
+
+    id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}
+
+    CMCCertId ::= IssuerAndSerialNumber
+
+    -- The following is used to request V3 extensions be added to a
+    -- certificate
+
+    id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2)
+         us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 14}
+
+    ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
+
+    -- The following exists to allow Diffie-Hellman Certification
+    -- Request Messages to be well-formed
+
+    id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
+
+
+
+Schaad                       Standards Track                   [Page 20]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+    NoSignatureValue ::= OCTET STRING
+
+    --  Unauthenticated attribute to carry removable data.
+    --    This could be used in an update of "CMC Extensions: Server
+    --    Side Key Generation and Key Escrow" (February 2005) and in
+    --    other documents.
+
+    id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+          rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)}
+    id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
+
+    CMCUnsignedData ::= SEQUENCE {
+        bodyPartPath        BodyPartPath,
+        identifier          OBJECT IDENTIFIER,
+        content             ANY DEFINED BY identifier
+    }
+
+    --  Replaces CMC Status Info
+    --
+
+    id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25}
+
+    CMCStatusInfoV2 ::= SEQUENCE {
+       cMCStatus             CMCStatus,
+       bodyList              SEQUENCE SIZE (1..MAX) OF
+                                      BodyPartReference,
+       statusString          UTF8String OPTIONAL,
+       otherInfo             CHOICE {
+         failInfo               CMCFailInfo,
+         pendInfo               PendInfo,
+         extendedFailInfo       SEQUENCE {
+            failInfoOID            OBJECT IDENTIFIER,
+            failInfoValue          AttributeValue
+         }
+       } OPTIONAL
+    }
+
+    BodyPartReference ::= CHOICE {
+       bodyPartID           BodyPartID,
+       bodyPartPath         BodyPartPath
+    }
+
+    BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
+
+    --  Allow for distribution of trust anchors
+    --
+
+    id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26}
+
+
+
+Schaad                       Standards Track                   [Page 21]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+    PublishTrustAnchors ::= SEQUENCE {
+        seqNumber      INTEGER,
+        hashAlgorithm  AlgorithmIdentifier,
+        anchorHashes     SEQUENCE OF OCTET STRING
+    }
+
+    id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27}
+
+    AuthPublish ::= BodyPartID
+
+    --   These two items use BodyPartList
+    id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}
+    id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}
+
+    BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
+
+    --
+    id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30}
+
+    CMCPublicationInfo ::= SEQUENCE {
+        hashAlg                      AlgorithmIdentifier,
+        certHashes                   SEQUENCE OF OCTET STRING,
+        pubInfo                          PKIPublicationInfo
+    }
+
+    id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31}
+
+    ModCertTemplate ::= SEQUENCE {
+        pkiDataReference             BodyPartPath,
+        certReferences               BodyPartList,
+        replace                      BOOLEAN DEFAULT TRUE,
+        certTemplate                 CertTemplate
+    }
+
+    -- Inform follow-on servers that one or more controls have already
+    -- been processed
+
+    id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32}
+
+    ControlsProcessed ::= SEQUENCE {
+        bodyList        SEQUENCE SIZE(1..MAX) OF BodyPartReference
+    }
+
+    --  Identity Proof control w/ algorithm agility
+
+    id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
+
+
+
+
+
+Schaad                       Standards Track                   [Page 22]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+    IdentifyProofV2 ::= SEQUENCE {
+        proofAlgID       AlgorithmIdentifier,
+        macAlgId         AlgorithmIdentifier,
+        witness          OCTET STRING
+    }
+
+    id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
+    PopLinkWitnessV2 ::= SEQUENCE {
+        keyGenAlgorithm   AlgorithmIdentifier,
+        macAlgorithm      AlgorithmIdentifier,
+        witness           OCTET STRING
+    }
+
+    --
+
+    id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35}
+
+
+    --
+    --  Allow for an End-Entity to request a change in name.
+    --  This item is added to RegControlSet in CRMF.
+    --
+
+    id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc 36}
+
+    ChangeSubjectName ::= SEQUENCE {
+        subject             Name OPTIONAL,
+        subjectAlt          GeneralNames OPTIONAL
+    }
+    -- (WITH COMPONENTS {..., subject PRESENT} |
+    --  WITH COMPONENTS {..., subjectAlt PRESENT} )
+
+    --
+    --  Embedded response from a third party for processing
+    --
+
+    id-cmc-responseBody OBJECT IDENTIFIER ::= {id-cmc 37}
+
+    --
+    --  Key purpose identifiers are in the Extended Key Usage extension
+    --
+
+    id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
+    id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
+    id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 28 }
+
+
+
+
+
+
+Schaad                       Standards Track                   [Page 23]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+    --
+    --  Subject Information Access identifier
+    --
+
+    id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }
+
+   END
+
+A.2.  2008 ASN.1 Module
+
+   An updated 2008 ASN.1 module has been provided as part of this
+   update.  The module contains those changes that were done to update
+   the current ASN.1 standards (done for [RFC5912]) as well as changes
+   made for this document.
+
+EnrollmentMessageSyntax-2011-v08
+    {iso(1) identified-organization(3) dod(6) internet(1)
+    security(5) mechanisms(5) pkix(7) id-mod(0)
+    id-mod-enrollMsgSyntax-2011-08(76)}
+DEFINITIONS IMPLICIT TAGS ::=
+BEGIN
+  EXPORTS ALL;
+  IMPORTS
+
+  AttributeSet{}, Extension{}, EXTENSION, ATTRIBUTE
+  FROM PKIX-CommonTypes-2009
+      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
+      mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}
+
+  AlgorithmIdentifier{}, DIGEST-ALGORITHM, KEY-WRAP, KEY-DERIVATION,
+      MAC-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
+  FROM AlgorithmInformation-2009
+      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
+      mechanisms(5) pkix(7) id-mod(0)
+      id-mod-algorithmInformation-02(58)}
+
+  CertificateSerialNumber, GeneralName, CRLReason, ReasonFlags,
+      CertExtensions, GeneralNames
+  FROM PKIX1Implicit-2009
+      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
+      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
+
+  Name, id-pkix, PublicKeyAlgorithms, SignatureAlgorithms, id-ad, id-kp
+  FROM PKIX1Explicit-2009
+      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
+      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}
+
+
+
+
+
+Schaad                       Standards Track                   [Page 24]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  ContentInfo, IssuerAndSerialNumber, CONTENT-TYPE
+  FROM CryptographicMessageSyntax-2010
+    { iso(1) member-body(2) us(840) rsadsi(113549)
+       pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
+
+  CertReqMsg, PKIPublicationInfo, CertTemplate
+  FROM PKIXCRMF-2009
+      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
+      mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005-02(55)}
+
+  mda-sha1
+  FROM PKIXAlgs-2009
+       { iso(1) identified-organization(3) dod(6)
+       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+       id-mod-pkix1-algorithms2008-02(56)}
+
+  kda-PBKDF2, maca-hMAC-SHA1
+  FROM CryptographicMessageSyntaxAlgorithms-2009
+      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+      smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
+
+  mda-sha256
+  FROM PKIX1-PSS-OAEP-Algorithms-2009
+       { iso(1) identified-organization(3) dod(6)
+         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+         id-mod-pkix1-rsa-pkalgs-02(54) } ;
+
+  --  CMS content types defined in this document
+
+  CMC-ContentTypes CONTENT-TYPE ::= { ct-PKIData | ct-PKIResponse, ... }
+
+  --  Signature Algorithms defined in this document
+
+  SignatureAlgs SIGNATURE-ALGORITHM ::= { sa-noSignature }
+
+  --  CMS Unsigned Attributes
+
+  CMC-UnsignedAtts ATTRIBUTE ::= { aa-cmc-unsignedData }
+
+  --
+  --
+
+  id-cmc OBJECT IDENTIFIER ::= {id-pkix 7}   -- CMC controls
+  id-cct OBJECT IDENTIFIER ::= {id-pkix 12}  -- CMC content types
+
+
+
+
+
+
+
+Schaad                       Standards Track                   [Page 25]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  -- This is the content type for a request message in the protocol
+
+  ct-PKIData CONTENT-TYPE ::=
+      { TYPE PKIData IDENTIFIED BY id-cct-PKIData }
+  id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
+
+  PKIData ::= SEQUENCE {
+      controlSequence    SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
+      reqSequence        SEQUENCE SIZE(0..MAX) OF TaggedRequest,
+      cmsSequence        SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
+      otherMsgSequence   SEQUENCE SIZE(0..MAX) OF OtherMsg
+  }
+
+  BodyPartID ::= INTEGER(0..4294967295)
+
+  TaggedAttribute ::= SEQUENCE {
+      bodyPartID         BodyPartID,
+      attrType           CMC-CONTROL.&id({Cmc-Control-Set}),
+      attrValues         SET OF CMC-CONTROL.
+                             &Type({Cmc-Control-Set}{@attrType})
+  }
+
+  Cmc-Control-Set CMC-CONTROL ::= {
+      cmc-identityProof | cmc-dataReturn | cmc-regInfo |
+      cmc-responseInfo | cmc-queryPending | cmc-popLinkRandom |
+      cmc-popLinkWitness | cmc-identification | cmc-transactionId |
+      cmc-senderNonce | cmc-recipientNonce | cmc-statusInfo |
+      cmc-addExtensions | cmc-encryptedPOP | cmc-decryptedPOP |
+      cmc-lraPOPWitness | cmc-getCert | cmc-getCRL |
+      cmc-revokeRequest | cmc-confirmCertAcceptance |
+      cmc-statusInfoV2 | cmc-trustedAnchors | cmc-authData |
+      cmc-batchRequests | cmc-batchResponses | cmc-publishCert |
+      cmc-modCertTemplate | cmc-controlProcessed |
+      cmc-identityProofV2 | cmc-popLinkWitnessV2, ...,
+      cmc-raIdentityWitness | cmc-responseBody }
+
+  OTHER-REQUEST ::= TYPE-IDENTIFIER
+
+  --  We do not define any other requests in this document.
+  --     Examples might be attribute certification requests.
+
+  OtherRequests OTHER-REQUEST ::= {...}
+
+
+
+
+
+
+
+
+
+Schaad                       Standards Track                   [Page 26]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  TaggedRequest ::= CHOICE {
+      tcr               [0] TaggedCertificationRequest,
+      crm               [1] CertReqMsg,
+      orm               [2] SEQUENCE {
+          bodyPartID            BodyPartID,
+          requestMessageType    OTHER-REQUEST.&id({OtherRequests}),
+          requestMessageValue   OTHER-REQUEST.&Type({OtherRequests}
+                                    {@.requestMessageType})
+      }
+  }
+
+  TaggedCertificationRequest ::= SEQUENCE {
+      bodyPartID            BodyPartID,
+      certificationRequest  CertificationRequest
+  }
+
+  AttributeList ATTRIBUTE ::= {at-extension-req, ...,
+      at-cmc-changeSubjectName}
+
+  CertificationRequest ::= SEQUENCE {
+     certificationRequestInfo  SEQUENCE {
+         version                   INTEGER,
+         subject                   Name,
+         subjectPublicKeyInfo      SEQUENCE {
+             algorithm                 AlgorithmIdentifier{PUBLIC-KEY,
+                                           {PublicKeyAlgorithms}},
+             subjectPublicKey          BIT STRING
+         },
+         attributes                [0] IMPLICIT SET OF
+                                       AttributeSet{{AttributeList}}
+      },
+      signatureAlgorithm        AlgorithmIdentifier
+                                    {SIGNATURE-ALGORITHM,
+                                        {SignatureAlgorithms}},
+      signature                 BIT STRING
+  }
+
+  TaggedContentInfo ::= SEQUENCE {
+      bodyPartID              BodyPartID,
+      contentInfo             ContentInfo
+  }
+
+  OTHER-MSG ::= TYPE-IDENTIFIER
+
+  --  No other messages currently defined
+
+  OtherMsgSet OTHER-MSG ::= {...}
+
+
+
+
+Schaad                       Standards Track                   [Page 27]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  OtherMsg ::= SEQUENCE {
+      bodyPartID        BodyPartID,
+      otherMsgType      OTHER-MSG.&id({OtherMsgSet}),
+      otherMsgValue     OTHER-MSG.&Type({OtherMsgSet}{@otherMsgType}) }
+
+  --  This defines the response message in the protocol
+
+  ct-PKIResponse CONTENT-TYPE ::=
+      { TYPE PKIResponse IDENTIFIED BY id-cct-PKIResponse }
+  id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
+
+  ResponseBody ::= PKIResponse
+
+  PKIResponse ::= SEQUENCE {
+      controlSequence   SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
+      cmsSequence       SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
+      otherMsgSequence  SEQUENCE SIZE(0..MAX) OF OtherMsg
+  }
+
+  CMC-CONTROL ::= TYPE-IDENTIFIER
+
+  -- The following controls have the type OCTET STRING
+
+  cmc-identityProof CMC-CONTROL ::=
+      { OCTET STRING IDENTIFIED BY id-cmc-identityProof }
+  id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
+
+  cmc-dataReturn CMC-CONTROL ::=
+      { OCTET STRING IDENTIFIED BY id-cmc-dataReturn }
+  id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
+
+  cmc-regInfo CMC-CONTROL ::=
+      { OCTET STRING IDENTIFIED BY id-cmc-regInfo }
+  id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
+
+  cmc-responseInfo CMC-CONTROL ::=
+      { OCTET STRING IDENTIFIED BY id-cmc-responseInfo }
+  id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
+
+  cmc-queryPending CMC-CONTROL ::=
+      { OCTET STRING IDENTIFIED BY id-cmc-queryPending }
+  id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
+
+  cmc-popLinkRandom CMC-CONTROL ::=
+      { OCTET STRING IDENTIFIED BY id-cmc-popLinkRandom }
+  id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22}
+
+
+
+
+
+Schaad                       Standards Track                   [Page 28]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  cmc-popLinkWitness CMC-CONTROL ::=
+      { OCTET STRING IDENTIFIED BY id-cmc-popLinkWitness }
+  id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23}
+
+  -- The following controls have the type UTF8String
+
+  cmc-identification CMC-CONTROL ::=
+      { UTF8String IDENTIFIED BY id-cmc-identification }
+  id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
+
+  -- The following controls have the type INTEGER
+
+  cmc-transactionId CMC-CONTROL ::=
+      { INTEGER IDENTIFIED BY id-cmc-transactionId }
+  id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
+
+  -- The following controls have the type OCTET STRING
+
+  cmc-senderNonce CMC-CONTROL ::=
+      { OCTET STRING IDENTIFIED BY id-cmc-senderNonce }
+  id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
+
+  cmc-recipientNonce CMC-CONTROL ::=
+      { OCTET STRING IDENTIFIED BY id-cmc-recipientNonce }
+
+  id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
+
+  -- Used to return status in a response
+
+  cmc-statusInfo CMC-CONTROL ::=
+      { CMCStatusInfo IDENTIFIED BY id-cmc-statusInfo }
+  id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
+
+  CMCStatusInfo ::= SEQUENCE {
+      cMCStatus       CMCStatus,
+      bodyList        SEQUENCE SIZE (1..MAX) OF BodyPartID,
+      statusString    UTF8String OPTIONAL,
+      otherInfo       CHOICE {
+         failInfo         CMCFailInfo,
+         pendInfo         PendInfo
+      } OPTIONAL
+  }
+
+  PendInfo ::= SEQUENCE {
+      pendToken        OCTET STRING,
+      pendTime         GeneralizedTime
+  }
+
+
+
+
+Schaad                       Standards Track                   [Page 29]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  CMCStatus ::= INTEGER {
+      success         (0),
+      failed          (2),
+      pending         (3),
+      noSupport       (4),
+      confirmRequired (5),
+      popRequired     (6),
+      partial         (7)
+  }
+
+  CMCFailInfo ::= INTEGER {
+      badAlg          (0),
+      badMessageCheck (1),
+      badRequest      (2),
+      badTime         (3),
+      badCertId       (4),
+      unsuportedExt   (5),
+      mustArchiveKeys (6),
+      badIdentity     (7),
+      popRequired     (8),
+      popFailed       (9),
+      noKeyReuse      (10),
+      internalCAError (11),
+      tryLater        (12),
+      authDataFail    (13)
+  }
+
+  -- Used for RAs to add extensions to certification requests
+
+  cmc-addExtensions CMC-CONTROL ::=
+      { AddExtensions IDENTIFIED BY id-cmc-addExtensions }
+  id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
+
+  AddExtensions ::= SEQUENCE {
+      pkiDataReference    BodyPartID,
+      certReferences      SEQUENCE OF BodyPartID,
+      extensions          SEQUENCE OF Extension{{CertExtensions}}
+  }
+
+  cmc-encryptedPOP CMC-CONTROL ::=
+      { EncryptedPOP IDENTIFIED BY id-cmc-encryptedPOP }
+  cmc-decryptedPOP CMC-CONTROL ::=
+      { DecryptedPOP IDENTIFIED BY id-cmc-decryptedPOP }
+  id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
+  id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
+
+
+
+
+
+
+Schaad                       Standards Track                   [Page 30]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  EncryptedPOP ::= SEQUENCE {
+      request       TaggedRequest,
+      cms             ContentInfo,
+      thePOPAlgID     AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
+      witnessAlgID    AlgorithmIdentifier{DIGEST-ALGORITHM,
+                          {WitnessAlgs}},
+      witness         OCTET STRING
+  }
+
+  POPAlgs MAC-ALGORITHM ::= {maca-hMAC-SHA1, ...}
+  WitnessAlgs DIGEST-ALGORITHM ::= {mda-sha1, ...}
+
+  DecryptedPOP ::= SEQUENCE {
+      bodyPartID      BodyPartID,
+      thePOPAlgID     AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
+      thePOP          OCTET STRING
+  }
+
+  cmc-lraPOPWitness CMC-CONTROL ::=
+      { LraPopWitness IDENTIFIED BY id-cmc-lraPOPWitness }
+
+  id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
+
+  LraPopWitness ::= SEQUENCE {
+      pkiDataBodyid   BodyPartID,
+      bodyIds         SEQUENCE OF BodyPartID
+  }
+
+  --
+
+  cmc-getCert CMC-CONTROL ::=
+      { GetCert IDENTIFIED BY id-cmc-getCert }
+  id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
+
+  GetCert ::= SEQUENCE {
+      issuerName      GeneralName,
+      serialNumber    INTEGER }
+
+
+  cmc-getCRL CMC-CONTROL ::=
+      { GetCRL IDENTIFIED BY id-cmc-getCRL }
+  id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
+
+  GetCRL ::= SEQUENCE {
+      issuerName    Name,
+      cRLName       GeneralName OPTIONAL,
+      time          GeneralizedTime OPTIONAL,
+      reasons       ReasonFlags OPTIONAL }
+
+
+
+Schaad                       Standards Track                   [Page 31]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  cmc-revokeRequest CMC-CONTROL ::=
+      { RevokeRequest IDENTIFIED BY id-cmc-revokeRequest}
+  id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
+
+  RevokeRequest ::= SEQUENCE {
+      issuerName            Name,
+      serialNumber          INTEGER,
+      reason                CRLReason,
+      invalidityDate         GeneralizedTime OPTIONAL,
+      passphrase            OCTET STRING OPTIONAL,
+      comment               UTF8String OPTIONAL }
+
+
+  cmc-confirmCertAcceptance CMC-CONTROL ::=
+      { CMCCertId IDENTIFIED BY id-cmc-confirmCertAcceptance }
+  id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}
+
+  CMCCertId ::= IssuerAndSerialNumber
+
+  -- The following is used to request V3 extensions be added
+  --     to a certificate
+
+  at-extension-req ATTRIBUTE ::=
+      { TYPE ExtensionReq IDENTIFIED BY id-ExtensionReq }
+  id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
+      rsadsi(113549) pkcs(1) pkcs-9(9) 14}
+
+  ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF
+      Extension{{CertExtensions}}
+
+  -- The following allows Diffie-Hellman Certification Request
+  --     Messages to be well-formed
+
+  sa-noSignature SIGNATURE-ALGORITHM ::= {
+      IDENTIFIER id-alg-noSignature
+      VALUE NoSignatureValue
+      PARAMS TYPE NULL ARE required
+      HASHES { mda-sha1 }
+  }
+  id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
+
+  NoSignatureValue ::= OCTET STRING
+
+  --  Unauthenticated attribute to carry removable data.
+
+  id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+      rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)}
+
+
+
+
+Schaad                       Standards Track                   [Page 32]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  aa-cmc-unsignedData ATTRIBUTE ::=
+      { TYPE CMCUnsignedData IDENTIFIED BY id-aa-cmc-unsignedData }
+  id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
+
+  CMCUnsignedData ::= SEQUENCE {
+      bodyPartPath        BodyPartPath,
+      identifier          TYPE-IDENTIFIER.&id,
+      content             TYPE-IDENTIFIER.&Type
+  }
+
+  --  Replaces CMC Status Info
+  --
+
+  cmc-statusInfoV2 CMC-CONTROL ::=
+      { CMCStatusInfoV2 IDENTIFIED BY id-cmc-statusInfoV2 }
+  id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25}
+
+
+  EXTENDED-FAILURE-INFO ::= TYPE-IDENTIFIER
+
+  ExtendedFailures EXTENDED-FAILURE-INFO ::= {...}
+
+  CMCStatusInfoV2 ::= SEQUENCE {
+     cMCStatus             CMCStatus,
+     bodyList              SEQUENCE SIZE (1..MAX) OF
+                                    BodyPartReference,
+     statusString          UTF8String OPTIONAL,
+     otherInfo             CHOICE {
+         failInfo               CMCFailInfo,
+         pendInfo               PendInfo,
+         extendedFailInfo       [1] SEQUENCE {
+            failInfoOID            TYPE-IDENTIFIER.&id
+                                       ({ExtendedFailures}),
+            failInfoValue          TYPE-IDENTIFIER.&Type
+                                       ({ExtendedFailures}
+                                           {@.failInfoOID})
+         }
+      } OPTIONAL
+  }
+
+  BodyPartReference ::= CHOICE {
+     bodyPartID           BodyPartID,
+     bodyPartPath         BodyPartPath
+  }
+
+  BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
+
+
+
+
+
+Schaad                       Standards Track                   [Page 33]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  --  Allow for distribution of trust anchors
+  --
+
+  cmc-trustedAnchors CMC-CONTROL ::=
+      { PublishTrustAnchors IDENTIFIED BY id-cmc-trustedAnchors }
+  id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26}
+
+  PublishTrustAnchors ::= SEQUENCE {
+      seqNumber      INTEGER,
+      hashAlgorithm  AlgorithmIdentifier{DIGEST-ALGORITHM,
+                         {HashAlgorithms}},
+      anchorHashes   SEQUENCE OF OCTET STRING
+  }
+
+  HashAlgorithms DIGEST-ALGORITHM ::= {
+     mda-sha1 | mda-sha256, ...
+  }
+
+  cmc-authData CMC-CONTROL ::=
+      { AuthPublish IDENTIFIED BY id-cmc-authData }
+  id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27}
+
+  AuthPublish ::= BodyPartID
+
+  --   These two items use BodyPartList
+
+  cmc-batchRequests CMC-CONTROL ::=
+      { BodyPartList IDENTIFIED BY id-cmc-batchRequests }
+
+  id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}
+
+  cmc-batchResponses CMC-CONTROL ::=
+      { BodyPartList IDENTIFIED BY id-cmc-batchResponses }
+  id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}
+
+  BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
+
+  cmc-publishCert CMC-CONTROL ::=
+      { CMCPublicationInfo IDENTIFIED BY id-cmc-publishCert }
+  id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30}
+
+  CMCPublicationInfo ::= SEQUENCE {
+      hashAlg        AlgorithmIdentifier{DIGEST-ALGORITHM,
+                           {HashAlgorithms}},
+      certHashes     SEQUENCE OF OCTET STRING,
+      pubInfo        PKIPublicationInfo
+  }
+
+
+
+
+Schaad                       Standards Track                   [Page 34]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  cmc-modCertTemplate CMC-CONTROL ::=
+      { ModCertTemplate IDENTIFIED BY id-cmc-modCertTemplate }
+
+  id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31}
+
+  ModCertTemplate ::= SEQUENCE {
+      pkiDataReference             BodyPartPath,
+      certReferences               BodyPartList,
+      replace                      BOOLEAN DEFAULT TRUE,
+      certTemplate                 CertTemplate
+  }
+
+  -- Inform follow-on servers that one or more controls have
+  --     already been processed
+
+  cmc-controlProcessed CMC-CONTROL ::=
+      { ControlsProcessed IDENTIFIED BY id-cmc-controlProcessed }
+  id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32}
+
+  ControlsProcessed ::= SEQUENCE {
+      bodyList              SEQUENCE SIZE(1..MAX) OF BodyPartReference
+  }
+
+  --  Identity Proof control w/ algorithm agility
+
+  cmc-identityProofV2 CMC-CONTROL ::=
+      { IdentityProofV2 IDENTIFIED BY id-cmc-identityProofV2 }
+  id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
+
+  IdentityProofV2 ::= SEQUENCE {
+      proofAlgID       AlgorithmIdentifier{DIGEST-ALGORITHM,
+                           {WitnessAlgs}},
+      macAlgId         AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
+      witness          OCTET STRING
+  }
+
+  cmc-popLinkWitnessV2 CMC-CONTROL ::=
+      { PopLinkWitnessV2 IDENTIFIED BY id-cmc-popLinkWitnessV2 }
+  id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
+
+  PopLinkWitnessV2 ::= SEQUENCE {
+      keyGenAlgorithm   AlgorithmIdentifier{KEY-DERIVATION,
+                            {KeyDevAlgs}},
+      macAlgorithm      AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
+      witness           OCTET STRING
+  }
+
+  KeyDevAlgs KEY-DERIVATION ::= {kda-PBKDF2, ...}
+
+
+
+Schaad                       Standards Track                   [Page 35]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+  cmc-raIdentityWitness CMC-CONTROL ::=
+     { BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness }
+
+  id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35}
+
+
+  --
+  --  Allow for an End-Entity to request a change in name.
+  --  This item is added to RegControlSet in CRMF.
+  --
+  at-cmc-changeSubjectName ATTRIBUTE ::=
+     { TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }
+
+  id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc 36}
+
+  ChangeSubjectName ::= SEQUENCE {
+      subject             Name OPTIONAL,
+      subjectAlt          GeneralNames OPTIONAL
+  }
+  (WITH COMPONENTS {..., subject PRESENT} |
+   WITH COMPONENTS {..., subjectAlt PRESENT} )
+
+  --
+  --  Embedded response from a third party for processing
+  --
+
+  cmc-responseBody CMC-CONTROL ::= {
+     BodyPartPath IDENTIFIED BY id-cmc-responseBody
+  }
+
+  id-cmc-responseBody OBJECT IDENTIFIER ::= {id-cmc 37}
+
+  --
+  --  Key purpose identifiers are in the Extended Key Usage extension
+  --
+
+  id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
+  id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
+  id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 }
+
+  --
+  --  Subject Information Access identifier
+  --
+
+  id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }
+
+END
+
+
+
+
+Schaad                       Standards Track                   [Page 36]
+
+RFC 6402                      CMC: Updates                 November 2011
+
+
+Author's Address
+
+   Jim Schaad
+   Soaring Hawk Consulting
+
+   EMail: jimsch@augustcellars.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schaad                       Standards Track                   [Page 37]
+