diff --git a/doc/source/api/index.rst b/doc/source/api/index.rst
index e11f79dd2..fb2bd9f4f 100644
--- a/doc/source/api/index.rst
+++ b/doc/source/api/index.rst
@@ -12,7 +12,8 @@ Quick Start
    ./quickstart/containers
    ./quickstart/acls
    ./quickstart/pkcs11keygeneration
-
+   ./quickstart/certificates
+   ./quickstart/dogtag_setup
 
 API Reference
 #############
@@ -23,3 +24,4 @@ API Reference
     ./reference/secrets
     ./reference/containers
     ./reference/acls
+    ./reference/certificates
diff --git a/doc/source/api/quickstart/certificates.rst b/doc/source/api/quickstart/certificates.rst
new file mode 100644
index 000000000..2645ca283
--- /dev/null
+++ b/doc/source/api/quickstart/certificates.rst
@@ -0,0 +1,329 @@
+******************************
+Certificates API - Quick Start
+******************************
+
+Barbican will be used to manage the lifecycle of x509 certificates covering
+operations such as initial certificate issuance, certificate re-issuance,
+certificate renewal and certificate revocation.  At present, only the issuance of
+certificates is implemented.
+
+This guide will provide some examples on how to use each of the supported operations.
+It assumes that you will be using a local running development environment of Barbican.
+If you need assistance with getting set up, please reference the :doc:`development guide </setup/dev>`.
+
+Barbican can be used to request certificate issuance from a number of private and
+public Certificate Authorities (CAs).  This is done through the Orders interface.
+
+There are several types of certificate orders available:
+    * :ref:`Simple CMC<simple_cmc_order>`
+    * :ref:`Full CMC<full_cmc_order>`
+    * :ref:`Stored Key<stored_key_order>`
+    * :ref:`Custom<custom_certificate_order>`
+
+An example of each kind of certificate request will be provided below.
+
+When the certificate order is received, a certificate order is generated and the client
+will be provided an order reference.  This order will be in PENDING state.  Once the
+certificate order has been fulfilled and the certificate is issued, the
+order state will be updated to ACTIVE, and the order will be updated to include
+a reference to a Certificate Container.
+
+.. _what_is_a_cert_container:
+
+What is a Certificate Container?
+################################
+
+A completed certificate order contains a reference to certificate container
+as shown below:
+
+.. code-block:: bash
+
+    curl -H 'content-type:application/json' -H 'X-Project-Id: 12345' \
+        http://localhost:9311/v1/orders/df1d1a0f-8454-46ca-9287-c57ced0418e7
+
+.. code-block:: javascript
+
+    {
+        "status": "ACTIVE",
+        "sub_status": "cert_generated",
+        "updated": "2015-05-09T22:40:05.007512",
+        "created": "2015-05-09T22:40:01.556689",
+        "container_ref": "http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493",
+        "order_ref": "http://localhost:9311/v1/orders/df1d1a0f-8454-46ca-9287-c57ced0418e7",
+        "meta": {
+            "profile": "caServerCert",
+            "request_data": "LS0tLS1CRUdJ...VC0tLS0tCg==",
+            "request_type": "simple-cmc",
+            "ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded"
+         },
+        "sub_status_message": "Certificate has been generated",
+        "type": "certificate"
+    }
+
+Getting the container provides references to secrets for the certificate,
+any intermediate certificate chain in PKCS7 format, and potentially references
+to the private and any passphrase used to encrypt the private key (if it is stored in
+Barbican).
+
+.. code-block:: bash
+
+     curl -H 'content-type:application/json' -H 'X-Project-Id: 12345' \
+        http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493
+
+.. code-block:: javascript
+
+    {
+        "status": "ACTIVE",
+        "updated": "2015-05-09T22:40:05.003296",
+        "name": null,
+        "consumers": [],
+        "created": "2015-05-09T22:40:05.003296",
+        "container_ref": "http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493",
+        "creator_id": null,
+        "secret_refs": [
+            {
+                "secret_ref": "http://localhost:9311/v1/secrets/acd47891-9e72-4542-b9de-be66cc343610",
+                "name": "certificate"
+            },
+            {
+                "secret_ref": "http://localhost:9311/v1/secrets/a871baa4-6ef2-42db-ba01-13414ab60d9e",
+                "name": "intermediates"
+            }
+        ],
+        "type": "certificate"
+    }
+
+You can get the certificate itself by extracting the payload of the secret_ref pointed to by the label "certificate".
+
+.. code-block:: bash
+
+    curl -H 'content-type:application/json' -H 'X-Project-Id: 12345' \
+        -H 'Accept:application/pkix-cert' \
+        http://localhost:9311/v1/secrets/acd47891-9e72-4542-b9de-be66cc343610/payload
+
+.. code-block:: bash
+
+    -----BEGIN CERTIFICATE-----
+    MIIDcTCCAlmgAwIBAgIBWDANBgkqhkiG9w0BAQsFADA/MRwwGgYDVQQKDBNwa2kt
+    dG9tY2F0MjYgZG9tYWluMR8wHQYDVQQDDBZDQSBTaWduaW5nIENlcnRpZmljYXRl
+    MB4XDTE1MDUwOTIyNDAwMVoXDTE3MDQyODIyNDAwMVowIDEeMBwGA1UEAwwVc2Vy
+    ....
+    HIG28XVygTC93uQmk1mAUTsIpFsk
+    -----END CERTIFICATE-----
+
+.. _finding_the_cas:
+
+What CAs are Available?
+#######################
+
+Barbican communicates with public and private CAs through CA plugins that are
+configured to communicate with one or more CAs.  CA plugins are configured and
+enabled in **barbican-api.conf**.
+
+To see the list of CA's that are currently configured, you can query the cas
+resource:
+
+.. code-block:: bash
+
+    curl  -H 'content-type:application/json' -H 'X-Project-Id:12345' \
+        http://localhost:9311/v1/cas
+
+This should provide a response like the following:
+
+.. code-block:: bash
+
+    {"cas": ["http://localhost:9311/v1/cas/3a2a533d-ed4d-4c68-a418-2ee79f4c9581"], "total": 1}
+
+More details on each CA can be obtained by querying the specific CA:
+
+.. code-block:: bash
+
+    curl  -H 'content-type:application/json' -H 'X-Project-Id:12345' \
+        http://localhost:9311/v1/cas/3a2a533d-ed4d-4c68-a418-2ee79f4c9581
+
+The output shows the status of the CA and the plugin used to communicate with it:
+
+.. code-block:: javascript
+
+    {
+        "status": "ACTIVE",
+        "updated": "2015-05-09T05:55:37.745132",
+        "created": "2015-05-09T05:55:37.745132",
+        "plugin_name": "barbican.plugin.dogtag.DogtagCAPlugin",
+        "meta": [
+            {"name": "Dogtag CA"},
+            {"description": "Certificate Authority - Dogtag CA"}
+        ],
+        "ca_id": "3a2a533d-ed4d-4c68-a418-2ee79f4c9581",
+        "plugin_ca_id": "Dogtag CA",
+        "expiration": "2015-05-10T05:55:37.740211"
+    }
+
+A snake-oil CA plugin is included with the Barbican source code for basic testing.
+In addition, a robust, enterprise-ready CA plugin is provided for the Dogtag CA.
+Instructions for setting up the CA are provided at :doc:`Dogtag Setup Instructions <./dogtag_setup>`.
+
+More details can be found in the :doc:`certificate reference <../reference/certificates>`.
+
+.. _order_certificate:
+
+How to Order a Certificate
+##########################
+
+As mentioned above, several types of certificate orders are available. This
+section details each one.
+
+.. _simple_cmc_order:
+
+Simple CMC Certificate Order
+****************************
+
+The easiest way to obtain a certificate is to provide a simple CMC request to the
+server using a Simple CMC Order type.  In the example below, we will use openssl
+commands to generate an RSA key pair and use that key pair to create a CSR.
+
+.. code-block:: bash
+
+    openssl genrsa -out private.pem 2048
+
+    openssl req -new -key private.pem -out csr.pem -subj '/CN=server1,o=example.com'
+
+    base64 ./csr.pem |tr -d '\r\n'
+
+The output of the last command will be a base64 encoded string that can be pasted
+into a JSON request for a Simple CMC Certificate order.
+
+.. code-block:: bash
+
+    curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{
+         "type": "certificate",
+         "meta": {
+            "request_data": "LS0tLS1CRUdJT..... oK2Fkh6dXBTVC0tLS0tCg==",
+            "request_type": "simple-cmc",
+            "ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded",
+            "profile": "caServerCert"
+         }
+    }' http://localhost:9311/v1/orders
+
+The ca_id and profile parameters are not required.  The profile represents a specific
+kind of certificate product (a three year server cert, for instance) as defined by the
+CA and CA plugin.  For a Dogtag CA, "caServerCert" is usually a profile that corresponds
+to a server cert and which is automatically approved and issued.  More details can be
+found in :doc:`Dogtag Setup Instructions <./dogtag_setup>`.
+
+The result of this JSON request will be an order reference, which, when fulfilled
+will contain a reference to a certificate container.  The certificate can be extracted
+as shown above.
+
+.. code-block:: bash
+
+    {"order_ref": "http://localhost:9311/v1/orders/df1d1a0f-8454-46ca-9287-c57ced0418e7"}
+
+.. _full_cmc_order:
+
+Full CMC Certificate Order
+**************************
+
+This type has not yet been implemented.
+
+.. _stored_key_order:
+
+Stored Key Certificate Order
+****************************
+
+Stored Key certificate orders take advantage of the fact that Barbican is also
+a repository for secrets.  RSA private keys can be either generated on the client
+and stored in Barbican beforehand using the secrets interface, or generated in
+Barbican directly using the orders interface.
+
+All that is required for the certificate order is the reference to the secret container
+for the RSA key pair and any parameters needed to generate a CSR.  Barbican will
+retrieve the RSA key pair (assuming the user has permission to access it) and will generate
+the CSR on the user's behalf.  The CSR will then be submitted to a back-end CA.  This
+may be particularly useful for provisioning flows.
+
+In the example below, we will generate a RSA key pair using the Orders interface, and
+use this generated secret to create a Stored Key Order.
+
+.. code-block:: bash
+
+    curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{
+        "type": "asymmetric",
+        "meta": {
+            "algorithm": "rsa",
+            "bit_length": "2048"
+        }
+    }' http://localhost:9311/v1/orders
+
+This should provide a response as follows:
+
+.. code-block:: bash
+
+    {"order_ref": "http://localhost:9311/v1/orders/cb3c43d6-e30c-40c0-b28c-b0dd58a6209d"}
+
+We can retrieve the reference to the container containing the RSA key pair from the order.
+
+.. code-block:: bash
+
+    curl -H 'content-type:application/json' -H 'X-Project-Id: 12345' \
+    http://localhost:9311/v1/orders/cb3c43d6-e30c-40c0-b28c-b0dd58a6209d
+
+.. code-block:: javascript
+
+    {
+        "status": "ACTIVE",
+        "updated": "2015-05-09T22:40:05.007512",
+        "created": "2015-05-09T22:40:01.556689",
+        "container_ref": "http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493",
+        "order_ref": "http://localhost:9311/v1/orders/cb3c43d6-e30c-40c0-b28c-b0dd58a6209d",
+        "meta": {
+            "algorithm": "rsa",
+            "bit_length": "2048"
+        },
+        "type": "asymmetric"
+    }
+
+Now that we have a reference to the container, we can create a stored-key request.
+
+.. code-block:: bash
+
+    curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{
+        "type": "certificate",
+        "meta": {
+            "source_container_ref": "http://localhost:9311/v1/containers/1e71dc2b-cf63-4aa4-91f7-41ea1a9e5493",
+            "subject_dn": "cn=server1, o=example.com",
+            "request_type": "stored-key",
+            "ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded",
+            "profile": "caServerCert"
+        }
+    }' http://localhost:9311/v1/orders
+
+As noted in the previous section, ca_id and profile are optional.  The response will be a reference to the
+created order.
+
+
+.. _custom_certificate_order:
+
+Custom Certificate Order
+########################
+
+A custom certificate order (which is also the order type assumed when no certificate
+order type is provided) is an order in which any request attributes are submitted to
+the back-end CA unchanged.  This is useful if you wish to communicate with a specific CA
+and wish to provide parameters that are specific to that CA.  Because this request
+contains parameters that are CA specific, the ca_id is required.
+
+The example below is a custom request for a server cert from a Dogtag CA.  As usual,
+the response is an order reference.
+
+.. code-block:: bash
+
+    curl -X POST -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d '{
+        "type": "certificate",
+        "meta": {
+            "request_data": "LS0tLS1CRUdJT..... oK2Fkh6dXBTVC0tLS0tCg==",
+            "request_type": "custom",
+            "ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded",
+            "profile": "caServerCert"
+        }
+    }' http://localhost:9311/v1/orders
diff --git a/doc/source/api/quickstart/containers.rst b/doc/source/api/quickstart/containers.rst
index 557ae1e72..28c8b8588 100644
--- a/doc/source/api/quickstart/containers.rst
+++ b/doc/source/api/quickstart/containers.rst
@@ -99,6 +99,12 @@ certificates:
         "updated": "2015-03-30T21:10:45.417835"
     }
 
+The payload for the secret referenced as the "certificate" is expected to be a
+PEM formatted x509 certificate.
+
+The payload for the secret referenced as the "intermediates" is expected to be a
+PEM formatted PKCS7 certificate chain.
+
 For more information on creating a certificate container, reference the
 :ref:`Creating a Certificate Container <create_certificate_container>` section.
 
diff --git a/doc/source/api/quickstart/dogtag_setup.rst b/doc/source/api/quickstart/dogtag_setup.rst
new file mode 100644
index 000000000..fe10ff9ed
--- /dev/null
+++ b/doc/source/api/quickstart/dogtag_setup.rst
@@ -0,0 +1,210 @@
+**************************
+Dogtag Setup - Quick Start
+**************************
+
+Dogtag is the Open Source upstream community version of the Red Hat Certificate
+System, an enterprise certificate management system that has been deployed in some
+of the largest PKI deployments worldwide.  RHCS is FIPS 140-2 and Common Criteria certified.
+
+The Dogtag Certificate Authority (CA) subsystem issues, renews and revokes many different
+kinds of certificates.  It can be used as a private CA back-end to Barbican, and interacts
+with Barbican through the Dogtag CA plugin.
+
+The Dogtag KRA subsystem is used to securely store secrets after being encrypted by
+storage keys that are stored either in a software NSS database or in an HSM.  It
+can serve as a secret store for Barbican, and interacts with Barbican core through
+the Dogtag KRA plugin.
+
+In this guide, we will provide instructions on how to set up a basic Dogtag instance
+containing a CA and a KRA, and how to configure Barbican to use this instance for a
+secret store and a certificate plugin.  Much more detail about Dogtag, its deployment
+options and its administration are available in the `RHCS documentation
+<https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System>`_.
+
+**Note:** The code below is taken from the devstack Barbican-Dogtag gate job.  You can
+extract this code by looking at the Dogtag functions in contrib/devstack/lib/barbican.
+
+Installing the Dogtag Packages
+******************************
+
+Dogtag packages are available in Fedora/RHEL/Centos and on Ubuntu/Debian distributions.
+This guide will include instructions applicable to Fedora/RHEL/Centos.
+
+If installing on a Fedora platform, use at least Fedora 21.
+To install the required packages:
+
+.. code-block:: bash
+
+    yum install -y pki-ca pki-kra 389-ds-base
+
+Creating the Directory Server Instance for the Dogtag Internal DB
+*****************************************************************
+
+The Dogtag CA and KRA subsystems use a 389 directory server as an internal database.
+Configure one as follows:
+
+.. code-block:: bash
+
+    mkdir -p /etc/389-ds
+
+    cat > /etc/389-ds/setup.inf <<EOF
+
+    [General]
+    FullMachineName= localhost.localdomain
+    SuiteSpotUserID= nobody
+    SuiteSpotGroup= nobody
+
+    [slapd]
+    ServerPort= 389
+    ServerIdentifier= pki-tomcat
+    Suffix= dc=example,dc=com
+    RootDN= cn=Directory Manager
+    RootDNPwd= PASSWORD
+    EOF
+
+    setup-ds.pl --silent --file=/etc/389-ds/setup.inf
+
+Creating the Dogtag CA
+**********************
+
+The following bash code sets up a Dogtag CA using some reasonable defaults to run in
+an Apache Tomcat instance on ports 8373 and 8370.  Detailed version-specific documentation
+is packaged and installed with the Dogtag packages as Linux man pages.  For more
+details on how to customize a Dogtag instance, see the man pages for *pkispawn* or
+consult the `RHCS documentation <https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System>`_.
+
+.. code-block:: bash
+
+    mkdir -p /etc/dogtag
+
+    cat > /etc/dogtag/ca.cfg <<EOF
+
+    [CA]
+    pki_admin_email=caadmin@example.com
+    pki_admin_name=caadmin
+    pki_admin_nickname=caadmin
+    pki_admin_password=PASSWORD
+    pki_admin_uid=caadmin
+    pki_backup_password=PASSWORD
+    pki_client_database_password=PASSWORD
+    pki_client_database_purge=False
+    pki_client_pkcs12_password=PASSWORD
+    pki_clone_pkcs12_password=PASSWORD
+    pki_ds_base_dn=dc=ca,dc=example,dc=com
+    pki_ds_database=ca
+    pki_ds_password=PASSWORD
+    pki_security_domain_name=EXAMPLE
+    pki_token_password=PASSWORD
+    pki_https_port=8373
+    pki_http_port=8370
+    pki_ajp_port=8379
+    pki_tomcat_server_port=8375
+    EOF
+
+    pkispawn -v -f /etc/dogtag/ca.cfg -s CA
+
+Creating the Dogtag KRA
+***********************
+
+The following bash code sets up the Dogtag KRA in the same Apache Tomcat instance
+as above.  In this simple example, it is required to set up the CA even if only
+the KRA is being used for a secret store.
+
+Note that the actual hostname of the machine should be used in the script (rather
+than localhost) because the hostname is used in the subject name for the SSL
+server certificate for the KRA.
+
+.. code-block:: bash
+
+    mkdir -p /etc/dogtag
+
+    hostname=$(hostname)
+    cat > /etc/dogtag/kra.cfg <<EOF
+
+    [KRA]
+    pki_admin_cert_file=/root/.dogtag/pki-tomcat/ca_admin.cert
+    pki_admin_email=kraadmin@example.com
+    pki_admin_name=kraadmin
+    pki_admin_nickname=kraadmin
+    pki_admin_password=PASSWORD
+    pki_admin_uid=kraadmin
+    pki_backup_password=PASSWORD
+    pki_client_database_password=PASSWORD
+    pki_client_database_purge=False
+    pki_client_pkcs12_password=PASSWORD
+    pki_clone_pkcs12_password=PASSWORD
+    pki_ds_base_dn=dc=kra,dc=example,dc=com
+    pki_ds_database=kra
+    pki_ds_password=PASSWORD
+    pki_security_domain_name=EXAMPLE
+    pki_security_domain_user=caadmin
+    pki_security_domain_password=PASSWORD
+    pki_token_password=PASSWORD
+    pki_https_port=8373
+    pki_http_port=8370
+    pki_ajp_port=8379
+    pki_tomcat_server_port=8375
+    pki_security_domain_hostname=$hostname
+    pki_security_domain_https_port=8373
+    EOF
+
+    pkispawn -v -f /etc/dogtag/kra.cfg -s KRA
+
+Configuring Barbican to Communicate with the Dogtag CA and KRA
+**************************************************************
+
+In order for Barbican to interact with the Dogtag CA and KRA, a PEM file must be
+created with trusted agent credentials.
+
+.. code-block:: bash
+
+    PASSWORD=password
+    USER=barbican
+    BARBICAN_CONF_DIR=/etc/barbican
+    openssl pkcs12 -in /root/.dogtag/pki-tomcat/ca_admin_cert.p12 -passin pass:PASSWORD \
+        -out $BARBICAN_CONF_DIR/kra_admin_cert.pem -nodes
+    chown $USER $BARBICAN_CONF_DIR/kra_admin_cert.pem
+
+The Barbican config file (/etc/barbican/barbican-api.conf) needs to be modified.
+The modifications below set the Dogtag plugins as the only enabled secret store and
+certificate plugins.  Be sure to restart Barbican once these changes are made.
+
+Note that the actual hostname of the machine should be used in the script (rather
+than localhost) because the hostname is used in the subject name for the SSL
+server certificate for the CA.
+
+.. code-block:: bash
+
+    [dogtag_plugin]
+    pem_path = '/etc/barbican/kra_admin_cert.pem'
+    dogtag_host = $(hostname)
+    dogtag_port = 8373
+    nss_db_path = '/etc/barbican/alias'
+    nss_db_path_ca = '/etc/barbican/alias-ca'
+    nss_password = 'password'
+    simple_cmc_profile = 'caOtherCert'
+    approved_profile_list = 'caServerCert'
+
+    [secretstore]
+    namespace = barbican.secretstore.plugin
+    enabled_secretstore_plugins = dogtag_crypto
+
+    [certificate]
+    namespace = barbican.certificate.plugin
+    enabled_certificate_plugins = dogtag
+
+
+Testing the Setup
+*****************
+
+Once all the above is set up, you can test the CA and KRA plugins by making a
+request for a certificate using a pre-approved profile.  As the issued certs are
+stored in the secret_store, this indirectly tests the KRA plugin as well.
+
+First, follow the instructions in :ref:`finding_the_cas` to find the ca_id of
+the Dogtag CA.
+
+Second, submit a simple CMC request as detailed in :ref:`simple_cmc_order`.
+
+The request should be automatically approved, and you should be able to extract
+the certificate from the certificate container in the order.
diff --git a/doc/source/api/reference/certificates.rst b/doc/source/api/reference/certificates.rst
new file mode 100644
index 000000000..d471a8779
--- /dev/null
+++ b/doc/source/api/reference/certificates.rst
@@ -0,0 +1,147 @@
+****************************
+Certificates API - Reference
+****************************
+
+.. _reference_post_certificate_orders:
+
+POST /v1/orders
+################
+Certificates are requested using the Orders interface.  Detailed description of this interface
+is deferred to the Orders API reference.  This reference identifies the parameters that are specific
+to each of the certificate order types i.e. those orders for which the parameter *type*
+is "certificate".
+
+All orders contain a required parameter *meta*, which is a dictionary containing key-value
+parameters which specify the details of an order request.  All the parameters below are passed
+in the *meta* dictionary.
+
+The result of this operation is an order for a certificate, returned to the client as an order
+reference.  Upon completion, the order will contain a reference to a Certificate Container,
+see :ref:`certificate_containers`.
+
+
+Common Attributes
+*****************
+
+Certificate orders have the same attributes that are common to all orders.  The table below lists
+those parameters that are specific to certificate orders in particular.
+
++----------------------------+---------+----------------------------------------------+------------+
+| Attribute Name             | Type    | Description                                  | Default    |
++============================+=========+==============================================+============+
+| request_type               | string  | (optional) The type of certificate order     | custom     |
+|                            |         | Possible values are stored-key, simple-cmc,  |            |
+|                            |         | full-cmc and custom                          |            |
++----------------------------+---------+----------------------------------------------+------------+
+| ca_id                      | string  | (optional) The UUID of the CA to which this  | None       |
+|                            |         | certificate order should be sent.  This      |            |
+|                            |         | UUID can be obtained from the cas interface. |            |
++----------------------------+---------+----------------------------------------------+------------+
+| profile                    | string  | (optional) Identifier indicating the         | None       |
+|                            |         | certificate product being requested.         |            |
+|                            |         | eg. a 3 year server certificate with certain |            |
+|                            |         | extensions.  This identifier is CA specific. |            |
+|                            |         | Therefore, ca_id is required if the profile  |            |
+|                            |         | is provided.                                 |            |
++----------------------------+---------+----------------------------------------------+------------+
+| requestor_name             | string  | (optional) Requestor name                    | None       |
++----------------------------+---------+----------------------------------------------+------------+
+| requestor_email            | string  | (optional) Requestor email                   | None       |
++----------------------------+---------+----------------------------------------------+------------+
+| requestor_phone            | string  | (optional) Requestor phone                   | None       |
++----------------------------+---------+----------------------------------------------+------------+
+
+Attributes for Simple CMC Orders
+********************************
+
++----------------------------+---------+----------------------------------------------+------------+
+| Attribute Name             | Type    | Description                                  | Default    |
++============================+=========+==============================================+============+
+| request_data               | string  | The base64 encoded simple CMC request with   | None       |
+|                            |         | no line breaks.   Simple CMC is the same as  |            |
+|                            |         | a PKCS10 CSR. (RFC 5272)                     |            |
++----------------------------+---------+----------------------------------------------+------------+
+
+Attributes for Stored Key Requests
+**********************************
+
++----------------------------+---------+----------------------------------------------+------------+
+| Attribute Name             | Type    | Description                                  | Default    |
++============================+=========+==============================================+============+
+| source_container_ref       | string  |  Reference to the RSA container already      | None       |
+|                            |         |  stored in Barbican containing the private   |            |
+|                            |         |  and public keys.                            |            |
++----------------------------+---------+----------------------------------------------+------------+
+| subject_dn                 | string  | Subject DN for the certificate.  This        | None       |
+|                            |         | value must comply with RFC 1485.             |            |
++----------------------------+---------+----------------------------------------------+------------+
+| extensions                 | string  | (optional) Base 64 DER encoded ASN.1 values  | None       |
+|                            |         | for requested certificate extensions,        |            |
+|                            |         | Currently, this value is not parsed.         |            |
++----------------------------+---------+----------------------------------------------+------------+
+
+Attributes for Custom Orders
+****************************
+
++----------------------------+---------+----------------------------------------------+------------+
+| Attribute Name             | Type    | Description                                  | Default    |
++============================+=========+==============================================+============+
+| (Varies - depends on CA)   | (Varies)| Custom certificate orders pass arbitrary     | None       |
+|                            |         | parameters through the CA unchanged.  It is  |            |
+|                            |         | up to the CA to interpret the parameters.    |            |
+|                            |         | Note that as the request parameters are CA   |            |
+|                            |         | specific, *ca_id* is required for this       |            |
+|                            |         | request type.                                |            |
++----------------------------+---------+----------------------------------------------+------------+
+
+
+Request:
+********
+
+The request below shows a simple CMC request.  For examples of each type,
+see the :doc:`Certificate Quick Start Guide <../quickstart/certificates>`.
+
+.. code-block:: javascript
+
+    POST /v1/orders
+    Headers:
+        Content-Type: application/json
+        X-Project-Id: {project_id}
+
+    Content:
+    {
+        "type": "certificate",
+        "meta": {
+            "request_data": "... base 64 encoded simple CMC ...",
+            "request_type": "simple-cmc",
+            "ca_id": "422e6ad3-24ae-45e3-b165-4e9487cd0ded",
+            "profile": "caServerCert"
+         }
+    }
+
+Response:
+*********
+
+.. code-block:: none
+
+    201 Created
+
+    {
+        "order_ref": "https://{barbican_host}/v1/orders/{order_uuid}"
+    }
+
+
+HTTP Status Codes
+*****************
+
++------+-----------------------------------------------------------------------------+
+| Code | Description                                                                 |
++======+=============================================================================+
+| 201  | Successfully created an Order                                               |
++------+-----------------------------------------------------------------------------+
+| 400  | Bad Request                                                                 |
++------+-----------------------------------------------------------------------------+
+| 401  | Invalid X-Auth-Token or the token doesn't have permissions to this resource |
++------+-----------------------------------------------------------------------------+
+| 415  | Unsupported media type                                                      |
++------+-----------------------------------------------------------------------------+