TOC |
|
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 and RFC 5274.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on January 13, 2011.
Copyright (c) 2010 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 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.
1.
Introduction
1.1.
Requirements Terminology
2.
Updates to RFC 5272 - Certificate Management over CMS (CMC)
2.1.
New Section 1.3. Changes Since RFC 5272
2.2.
Replace Section 6.3. Linking Identity and POP Information
2.3.
Replace Section 6.3.3. Renewal and Rekey Messages
2.4.
New Section 6.20 RA Identity Proof Witness control
2.5.
New Section 6.21 Change Subject Name Control
2.6.
New Section 6.22 Response Body Control
2.7.
New Section 8. Certificate Requirements
2.8.
New Section 8.1. Extended Key Usage
2.9.
New Section 8.2. Subject Information Access
3.
Updates to RFC 5724 - Certificate Management Message over CMS (CMC): Compliance Requirements
3.1.
Update to Section 4.2 Controls
4.
Security Considerations
5.
Normative References
Appendix A.
ASN.1 Module
§
Author's Address
TOC |
While dealing with the Suite B profile of CMC [I‑D.turner‑suiteb‑cmc] (Zieglar, L., Peck, M., and S. Turner, “Suite B Profile of Certificate Management over CMS,” June 2010.), a number of defencies where noted in the current base CMC specification. This document has a set of updates to [RFC5272] (Schaad, J. and M. Myers, “Certificate Management over CMS (CMC),” June 2008.) to deal with those issues.
TOC |
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
TOC |
TOC |
This section is inserted before the current section 1.3.
The following changes were made in this document.
Addition of new controls:
- RA Identity Witness
- allows for an RA to perform the identity checking using the identity and shared-secret and then tell any following servers that the identity check was successfully performed.
- Change Subject Name
- allows for a client to request a change in the subject name and subject alternate name fields in a certificate.
- Response Body
- allows for an RA to identify a nested response for an EE to process.
Add Extended Key Usages for CMC - Define a new Subject Information Access to hold locations to contact the CMC server at.
TOC |
In a Full PKI Request, identity information about the client is carried in the signature of the SignedData containing all of the certification requests. Proof-of-possession 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 generated both the POP and proof-of-identity information.
This section describes three mechanisms for linking identity and POP information: witness values cryptographically derived from the shared-secret (Section 6.3.1), shared-secret/subject name matching (Section 6.3.2), and linking with an existing certificate (6.3.3). Clients and servers MUST support the witness value and certificate linking techniques. Clients and servers MAY support shared-secret/name matching or other bilateral techniques 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.
TOC |
New section title is "Existing Certificate Linking"
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 (name and subject alternative name) into the new certification request. The POP on the certificate is then performed by using the new key to sign the identity information. The identity information is then tied back by signing the POP proof as part of the PKIData with a certificate that has matching identity information.
Existing certificate linking can be used in the following circumstances:
When replacing a certificate by doing a renewal or rekey certification request.
Use of 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.
Use of a third party certificate to get a new certificate from a CA. An example of this would be to use a certificate and key pair distributed with a device to prove an identity. This would require that the CA have an out-of-band channel to map the device identity to the EE identity.
TOC |
Editors Note: The control is to be added to the table of controls in section 6.
The RA Identity Proof Witness control allows an RA to indicate to subsequence 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 within a department while the CA could be companywide. The RA would perform the identity proof, and potentially other tasks that require the secret to be used, while the CA would be prevented from knowing the same information. If the identity proof fails, then the RA returns an error to the client noting 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 TBD}
The object defined for this control is a CMC-CONTROL and is named cmc-raIdentityWitness. The object is added to the object set Cmc-Control-Set. The control is only permitted to occur in the control sequence of a PKIData object. It is not permitted to occur in the control sequence of a PKIRespones. The control is only permitted to be used by an RA. The control may occur multiple times in a control sequence.
The control is identified using the object identifier id-cmc-raIdentityWitness.
The type structure associated with the control is BodyPartPath. The path contains a sequence of body part identifiers one of the following items:
- Identity Proof control
- if the RA verified the identity proof in this control.
- Identity Proof Version 2
- 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 as the RA will frequently know the actual name to be assigned to the entity requesting the certificate and the entity will not know the actual details of the name. (The association would be setup 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 explicity know which identity proofs have been perform. The new control also allows an RA to state that out-of-band idenitity proofs have been performed.
When the identity proof is performed by an RA, the RA also needs to perform the linking between the identity proof and the name information wrapped inside of the key proof-of-possession.
TOC |
This item is to be added to the table in section 6.
The Client Name Change Request Control is designed for a client to ask for a change in its name as part of a certificate. This cannot be done in the simple way of just changing the requested subject name in the certificate template because of security issues. The name in the certificate request needs to match the name in the certificate used to sign the request in order that identity and possession proofs are correctly applied.
The relevant ASN.1 for the Client Name Change Request control is as follows:
at-cmc-changeSubjectName ATTRIBUTE ::= { ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName } id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc TBD} ChangeSubjectName ::= SEQUENCE { subject Name OPTIONAL, subjectAlt SubjectAltName OPTIONAL } (WITH COMPONENTS {..., subject PRESENT} | COMPONENTS {..., subjectAltPRESENT} )
The control is designed to be used as an ATTRIBUTE object. As such the control 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-changedSubjectName.
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:
TOC |
This item is to be added to the table in section 6.
The Response Body Control is designed for an RA to inform an EE that there is an embedded response message that needs to 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 on the certificate request such as key generation and needs to respond with both the original response message from the certificate issues as well as the response the RA is generating. Another case this is useful is the shared secret is between the RA and the EE and the RA needs to return a Publish Trust Anchors control in order to populate the correct trust points.
The relaveant 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 TBD}
This object id defined as a CMC control and is named cmc-responseBody. The control is added to the Cmc-Control-Set. The control is only permitted to occur in the control sequence of a PKIResponse object. It is not permitted to occur in the control sequence of a PKIData. The control is only permitted to be used by an RA (a CA has no need to generate nested responses targetted at the EE). The control may occur multiple times in a single control sequence.
The control is identified using the object identifier id-cmc-responseBody.
The type structure associated with the control is BodyPartID. This field controls the control number for the nested response.
TOC |
This section is to be inserted before the current section 8.
Certificates for servers used in the CMC protocol SHOULD conform with the profile defined in [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,” May 2008.). This document defines some additional items that can appear in CMC server certificates. Section 8.1 defines some additional Extended Key Usage values that can appear in certificates. Section 8.2 defines a new Subject Information Access value which allows for a CMC certificate to publish information on how to contact the services it provides.
TOC |
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 TBD } id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp TBD } id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp TBD }
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 the CA certificate or may be 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 public key for CMC protocol operations and for issuing Certificates and CRLs decreases the number of operations for which the private key 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.
TOC |
The subject information access extension indicates how to access the information and services for the subject of the certificate. We define a new value to go into 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 8.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. Where the CMC services are available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier. Where the CMC services are available via electronic mail, accessLocation MUST be an rfc822Name. Where CMC services are available using TCP/IP, the dNSName or iPAddress name forms may be used. The semantics of other name forms of accessLocation (when accessMethod is id-ad-cmc) are not defined by this specification.
The ASN.1 for this extension is:
id-ad-cmc OBJECT IDENTIFIER ::= { id-ad TBD }
TOC |
TOC |
The following lines should be added to the end of Table 1.
RaIdentityWitness N/A MUST (2)
ChangeSubjectName MAY N/A MUST
TOC |
To be supplied.
TOC |
[RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
[RFC5272] | Schaad, J. and M. Myers, “Certificate Management over CMS (CMC),” RFC 5272, June 2008 (TXT). |
[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 (TXT). |
[I-D.turner-suiteb-cmc] | Zieglar, L., Peck, M., and S. Turner, “Suite B Profile of Certificate Management over CMS,” draft-turner-suiteb-cmc-03 (work in progress), June 2010 (TXT). |
[RFC5912] | Hoffman, P. and J. Schaad, “New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX),” RFC 5912, June 2010 (TXT). |
TOC |
An updated 2009 ASN.1 module has been provided as part of this update. The module contains changes that were made as part of the re-write to current ASN.1 standards in [RFC5912] (Hoffman, P. and J. Schaad, “New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX),” June 2010.) as well as the changes for this document.
EnrollmentMessageSyntax-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002-02(53)} 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 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 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)} ContentInfo, IssuerAndSerialNumber, CONTENT-TYPE FROM CryptographicMessageSyntax-2009 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41)} 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 -- This is the content type for a request message in the protocol ct-PKIData CONTENT-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 } OTHER-REQUEST ::= TYPE-IDENTIFIER -- We do not define any other requests in this document -- examples might be attribute certification requests OtherRequests OTHER-REQUEST ::= {...} 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 ::= {...} 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 ::= { 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} 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 } 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} 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 } 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)} 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 -- 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 } 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, ...} cmc-raIdentityWitness CMC-CONTROL ::= { BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness } id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc TBD} -- -- Allow for an End-Entity to request a change in name -- This item is added to RegControlSet in CRMF -- at-cmc-changeSubjectName ATTRIBUTE ::= { ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName } id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc TBD} ChangeSubjectName ::= SEQUENCE { subject Name OPTIONAL, subjectAlt SubjectAltName OPTIONAL } (WITH COMPONENTS {..., subject PRESENT} | COMPONENTS {..., subjectAltPRESENT} ) id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp TBD } id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp TBD } id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp TBD } id-ad-cmc OBJECT IDENTIFIER ::= { id-ad TBD } END
TOC |
Jim Schaad | |
Soaring Hawk Consulting | |
Email: | jimsch@augustcellars.com |