CMP

1. Introduction

MTG Certificate Lifecycle Manager Server includes an implementation of the CMP protocol according to RFC 4210 [RFC4210] and RFC 4211 [RFC4211].

2. CMP Supported Operations

Listing 1 shows the requests and responses of CMP. MTG Certificate Lifecycle Manager Server supports the following requests:

  • Initialization Request [0]

  • Certification Request [2]

  • Key Update Request [7]

  • Revocation Request [11]

  • Certificate confirm [24]

MTG Certificate Lifecycle Manager Server supports the following responses:

  • Initialization Response [1]

  • Certification Response [3]

  • Key Update Response [8]

  • Revocation Response [12]

  • Confirmation [19]

Listing 1. Message-specific body elements
PKIBody ::= CHOICE {       -- message-specific body elements
    ir       [0]  CertReqMessages,        --Initialization Request
    ip       [1]  CertRepMessage,         --Initialization Response
    cr       [2]  CertReqMessages,        --Certification Request
    cp       [3]  CertRepMessage,         --Certification Response
    p10cr    [4]  CertificationRequest,   --imported from [PKCS10]
    popdecc  [5]  POPODecKeyChallContent, --pop Challenge
    popdecr  [6]  POPODecKeyRespContent,  --pop Response
    kur      [7]  CertReqMessages,        --Key Update Request
    kup      [8]  CertRepMessage,         --Key Update Response
    krr      [9]  CertReqMessages,        --Key Recovery Request
    krp      [10] KeyRecRepContent,       --Key Recovery Response
    rr       [11] RevReqContent,          --Revocation Request
    rp       [12] RevRepContent,          --Revocation Response
    ccr      [13] CertReqMessages,        --Cross-Cert. Request
    ccp      [14] CertRepMessage,         --Cross-Cert. Response
    ckuann   [15] CAKeyUpdAnnContent,     --CA Key Update Ann.
    cann     [16] CertAnnContent,         --Certificate Ann.
    rann     [17] RevAnnContent,          --Revocation Ann.
    crlann   [18] CRLAnnContent,          --CRL Announcement
    pkiconf  [19] PKIConfirmContent,      --Confirmation
    nested   [20] NestedMessageContent,   --Nested Message
    genm     [21] GenMsgContent,          --General Message
    genp     [22] GenRepContent,          --General Response
    error    [23] ErrorMsgContent,        --Error Message
    certConf [24] CertConfirmContent,     --Certificate confirm
    pollReq  [25] PollReqContent,         --Polling request
    pollRep  [26] PollRepContent          --Polling response
}

3. MTG-CLM integration

To enable integration with MTG-CLM, CMP uses the credentials of an API client as described in CMP Administration Manual. Additionally, CMP server uses a policy to handle certificate management. It identifies the CA that will issue the certificate, the template that will be used and also can contain additional restrictions and configurations for the certificate lifecycle.

CMP messages can be protected for authenticity and confidentiality. Currently, two mechanisms to protect the authenticity of the requests and responses are supported. The one is the Shared Secret Information (Section 5.1.3.1 [RFC4210]) and the second is Signature (Section 5.1.3.3 [RFC4210]).

In the case of Shared Secret Information an HMAC based mechanism is used. Both the client and the server perform a MAC operation over the request and response, respectively. A password-based MAC algorithm is used. Therefore, the client and the server must share the same password. This password is the password of the end-entity.

In Listing 2 the PKIHeader of a CMP Message is shown.

From the optional fields of the PKIHeader MTG Certificate Lifecycle Manager Server requires the presence of the following fields:

  • protectionAlg

  • transactionID

  • senderKID (for password-based MAC protected requests)

Listing 2. PKIHeader according to RFC4210
PKIHeader ::= SEQUENCE {
    pvno                INTEGER     { cmp1999(1), cmp2000(2) },
    sender              GeneralName,
    recipient           GeneralName,
    messageTime     [0] GeneralizedTime         OPTIONAL,
    protectionAlg   [1] AlgorithmIdentifier     OPTIONAL,
    senderKID       [2] KeyIdentifier           OPTIONAL,
    recipKID        [3] KeyIdentifier           OPTIONAL,
    transactionID   [4] OCTET STRING            OPTIONAL,
    senderNonce     [5] OCTET STRING            OPTIONAL,
    recipNonce      [6] OCTET STRING            OPTIONAL,
    freeText        [7] PKIFreeText             OPTIONAL,
    generalInfo     [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue  OPTIONAL
}

In protectionAlg the algorithm that protects the message is specified. For password-based MAC algorithms the one with the OID 1.2.840.113533.7.66.13 is supported. For signature based algorithms SHA256withRSA, SHA384withRSA, SHA512withRSA,SHA256withECDSA, SHA384withECDSA, and SHA512withECDSA are supported.

In transactionID a random identifier that correlates requests to each other is placed. This is helpful in the case where the client notifies the server of the acceptance of the certificate in a Certificate confirm message (see Listing 1).

In senderKID a pointer to the password used in the protection of the messages is provided. For MTG Certificate Lifecycle Manager Server this pointer is the UUID of the end-entity of CLM. Listing 3 shows an example of a client request protected with a password-based MAC. With the argument -ref the UUID of the CLM end-entity is provided, in this case the end-entity has the UUID 251069b7-bcc3-4911-b312-04327925a1aa. With the argument -secret the password of the CLM end-entity is provided, in this case the end-entity has the password GTTgcdagW:OGJ73_. The senderKID is a sequence of bytes. These bytes are the ASCII encoded representation of the UUID, in this case 32353130363962372D626363332D343931312D623331322D303433323739323561316161.

Listing 3. Request certificate with OpenSSL. The message is protected by a password-based MAC using the password and UUID of an end-entity.
openssl cmp -cmd ir -server cmp.example.com:8504 -path cmp -newkey key.pem -ref 251069b7-bcc3-4911-b312-04327925a1aa -secret pass:"GTTgcdagW:OGJ73_" -certout certOut.pem -subject "/CN=User/O=MTG/C=DE"

3.1. Defining default policy

API clients are optionally associated with a default policy. MTG Certificate Lifecycle Manager Server by default, uses the default policy of the associated API client to handle certificate management. In case the API client is not associated with a default policy and the client does not specify a different policy in the request (see Section 4.1), CMP server will respond with an invalid identifier error.

3.2. Defining different policy

CMP server supports specifying a different policy as the policy to be used instead of the API client’s default policy. The new policy’s ID has to be used in the requests towards CMP server as described in Section 4.1.

3.3. Set up password login

CMP server supports basic authentication (see [RFC7617]). The credentials for this type of authentication can be obtained by creating an end entity and an associated end entity password. More details can be found in End Entities Password. Configure the end entity ID of the end entity in username and the end entity password in password to execute basic authentication requests.

4. Custom features

4.1. Different policy endpoint

Per default the CMP server offers the following endpoints:

  • CMP_SERVER_BASE_URL/cmp

Client requests to these endpoints use the default policy.

CMP server provides two supplementary endpoints to support requests that require a different policy. Requests towards these endpoints specify a different policy to use, rather than the default policy of the associated API client:

  • CMP_SERVER_BASE_URL/<identifier>/cmp

  • CMP_SERVER_BASE_URL/cmp/<identifier>

The <identifier> needs to be replaced with a valid policy ID. For example to request a certificate that is issued under the policy ffc0d281-f9df-45cd-a30d-1881cd67012a use the URL: CMP_SERVER_BASE_URL/ffc0d281-f9df-45cd-a30d-1881cd67012a/cmp.

References