management protocols.
The columns in the table are:
Name: an identifier used for message profiles
Use: description of where and for what the algorithm is used
Mandatory: an AlgorithmIdentifier which MUST be supported by
conforming implementations
Others: alternatives to the mandatory AlgorithmIdentifier
Name Use Mandatory Others
MSG_SIG_ALG Protection of PKI DSA/SHA-1 RSA/MD5...
messages using signature
MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC,
messages using MACing X9.9...
SYM_PENC_ALG symmetric encryption of 3-DES (3-key- RC5,
an end entity's private EDE, CBC mode) CAST-128...
key where symmetric
key is distributed
out-of-band
PROT_ENC_ALG asymmetric algorithm D-H RSA
used for encryption of
(symmetric keys for
encryption of) private
keys transported in
PKIMessages
PROT_SYM_ALG symmetric encryption 3-DES (3-key- RC5,
algorithm used for EDE, CBC mode) CAST-128...
encryption of private
key bits (a key of this
type is encrypted using
PROT_ENC_ALG)
Mandatory AlgorithmIdentifiers and Specifications:
DSA/SHA-1:
AlgId: {1 2 840 10040 4 3};
NIST, FIPS PUB 186: Digital Signature Standard, 1994;
Public Modulus size: 1024 bits.
PasswordBasedMac:
{1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the owf
parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac parameter;
(this specification), along with
NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995;
H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message
Authentication", Internet Request for Comments 2104, February 1997.
3-DES:
{1 2 840 113549 3 7};
(used in RSA's BSAFE and in S/MIME).
D-H:
AlgId: {1 2 840 10046 2 1};
ANSI X9.42;
Public Modulus Size: 1024 bits.
DHParameter ::= SEQUENCE {
prime INTEGER, -- p
base INTEGER -- g
}
B3. "Self-signed" certificates
Profile of how a Certificate structure may be "self-signed". These
structures are used for distribution of "root" CA public keys. This
can occur in one of three ways (see Section 2.4 above for a
description of the use of these structures):
Type Function
newWithNew a true "self-signed" certificate; the contained public
key MUST be usable to verify the signature (though this
provides only integrity and no authentication whatsoever)
oldWithNew previous root CA public key signed with new private key
newWithOld new root CA public key signed with previous private key
<<Such certificates (including relevant extensions) must contain
"sensible" values for all fields. For example, when present
subjectAltName MUST be identical to issuerAltName, and when present
keyIdentifiers must contain appropriate values, et cetera.>>
B4. Proof of Possession Profile
POP fields for use (in signature field of pop field of
ProofOfPossession structure) when proving possession of a private
signing key which corresponds to a public verification key for which
a certificate has been requested.
Field Value Comment
algorithmIdentifier MSG_SIG_ALG only signature protection is
allowed for this proof
signature present bits calculated using MSG_SIG_ALG
<<Proof of possession of a private decryption key which corresponds
to a public encryption key for which a certificate has been requested
does not use this profile; instead the method given in protectionAlg
for PKIConfirm in Section B8 is used.>>
Not every CA/RA will do Proof-of-Possession (of signing key,
decryption key, or key agreement key) in the PKIX-CMP in-band
certification request protocol (how POP is done MAY ultimately be a
policy issue which is made explicit for any given CA in its
publicized Policy OID and Certification Practice Statement).
However, this specification MANDATES that CA/RA entities MUST do POP
(by some means) as part of the certification process. All end
entities MUST be prepared to provide POP (i.e., these components of
the PKIX-CMP protocol MUST be supported).
B5. Root CA Key Update
A root CA updates its key pair. It then produces a CA key update
announcement message which can be made available (via one of the
transport mechanisms) to the relevant end entities. A PKIConfirm
message is NOT REQUIRED from the end entities.
ckuann message:
Field Value Comment
sender CA name responding CA name
body ckuann(CAKeyUpdAnnContent)
oldWithNew present see Section B3 above
newWithOld present see Section B3 above
newWithNew present see Section B3 above
extraCerts optionally present can be used to "publish"
certificates (e.g.,
certificates signed using
the new private key)
B6. PKI Information request/response
The end entity sends general message to the PKI requesting details
which will be required for later PKI management operations. RA/CA
responds with general response. If an RA generates the response then
it will simply forward the equivalent message which it previously
received from the CA, with the possible addition of the certificates
to the extraCerts fields of the PKIMessage. A PKIConfirm message is
NOT REQUIRED from the end entity.
Message Flows:
Step# End entity PKI
1 format genm
2 -> genm ->
3 handle genm
4 produce genp
5 <- genp <-
6 handle genp
genm:
Field Value
recipient CA name
-- the name of the CA as contained in issuerAltName extensions or
-- issuer fields within certificates
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
SenderKID present if required
-- must be present if required for verification of message protection
freeText any valid value
body genr (GenReqContent)
GenMsgContent empty SEQUENCE
-- all relevant information requested
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
genp:
Field Value
sender CA name
-- name of the CA which produced the message
protectionAlg MSG_MAC_ALG or MSG_SIG_ALG
-- any authenticated protection alg.
senderKID present if required
-- must be present if required for verification of message protection
body genp (GenRepContent)
CAProtEncCert present (object identifier one
of PROT_ENC_ALG), with relevant
value
-- to be used if end entity needs to encrypt information for the CA
-- (e.g., private key for recovery purposes)
SignKeyPairTypes present, with relevant value
-- the set of signature algorithm identifiers which this CA will
-- certify for subject public keys
EncKeyPairTypes present, with relevant value
-- the set of encryption/key agreement algorithm identifiers which
-- this CA will certify for subject public keys
PreferredSymmAlg present (object identifier one
of PROT_SYM_ALG) , with relevant
value
-- the symmetric algorithm which this CA expects to be used in later
-- PKI messages (for encryption)
CAKeyUpdateInfo optionally present, with
relevant value
-- the CA MAY provide information about a relevant root CA key pair
-- using this field (note that this does not imply that the responding
-- CA is the root CA in question)
CurrentCRL optionally present, with relevant value
-- the CA MAY provide a copy of a complete CRL (i.e., fullest possible
-- one)
protection present
-- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
extraCerts optionally present
-- can be used to send some certificates to the end entity. An RA MAY
-- add its certificate here.
B7. Cross certification request/response (1-way)
Creation of a single cross-certificate (i.e., not two at once). The
requesting CA MAY choose who is responsible for publication of the
cross-certificate created by the responding CA through use of the
PKIPublicationInfo control.
Preconditions:
1. Responding CA can verify the origin of the request (possibly
requiring out-of-band means) before processing the request.
2. Requesting CA can authenticate the authenticity of the origin of
the response (possibly requiring out-of-band means) before
processing the response
Message Flows:
Step# Requesting CA Responding CA
1 format ccr
2 -> ccr ->
3 handle ccr
4 produce ccp
5 <- ccp <-
6 handle ccp
7 format conf
8 -> conf ->
9 handle conf
ccr:
Field Value
sender Requesting CA name
-- the name of the CA who produced the message
recipient Responding CA name
-- the name of the CA who is being asked to produce a certificate
messageTime time of production of message
-- current time at requesting CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this request
senderKID present if required
-- must be present if required for verification of message protection
transactionID present
-- implementation-specific value, meaningful to requesting CA.
-- [If already in use at responding CA then a rejection message
-- MUST be produced by responding CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ccr (CertReqMessages)
only one CertReqMsg
allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
certTemplate present
-- details follow
version v1 or v3
-- <<v3 STRONGLY RECOMMENDED>>
signingAlg present
-- the requesting CA must know in advance with which algorithm it
-- wishes the certificate to be signed
subject present
-- may be NULL-DN only if subjectAltNames extension value proposed
validity present
-- MUST be completely specified (i.e., both fields present)
issuer present
-- may be NULL-DN only if issuerAltNames extension value proposed
publicKey present
-- the key to be certified (which must be for a signing algorithm)
extensions optionally present
-- a requesting CA must propose values for all extensions which it
-- requires to be in the cross-certificate
POPOSigningKey present
-- see "Proof of possession profile" (Section B4)
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that requester wishes
-- to include
ccp:
Field Value
sender Responding CA name
-- the name of the CA who produced the message
recipient Requesting CA name
-- the name of the CA who asked for production of a certificate
messageTime time of production of message
-- current time at responding CA
protectionAlg MSG_SIG_ALG
-- only signature protection is allowed for this message
senderKID present if required
-- must be present if required for verification of message
-- protection
recipKID present if required
transactionID present
-- value from corresponding ccr message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- senderNonce from corresponding ccr message
freeText any valid value
body ccp (CertRepMessage)
only one CertResponse allowed
-- if multiple cross certificates are required they MUST be packaged
-- in separate PKIMessages
response present
status present
PKIStatusInfo.status present
-- if PKIStatusInfo.status is one of:
-- granted, or
-- grantedWithMods,
-- then certifiedKeyPair MUST be present and failInfo MUST be absent
failInfo present depending on
PKIStatusInfo.status
-- if PKIStatusInfo.status is:
-- rejection
-- then certifiedKeyPair MUST be absent and failInfo MUST be present
-- and contain appropriate bit settings
certifiedKeyPair present depending on
PKIStatusInfo.status
certificate present depending on
certifiedKeyPair
-- content of actual certificate must be examined by requesting CA
-- before publication
protection present
-- bits calculated using MSG_SIG_ALG
extraCerts optionally present
-- MAY contain any additional certificates that responder wishes
-- to include
B8. Initial Registration/Certification (Basic Authenticated Scheme)
An (uninitialized) end entity requests a (first) certificate from a
CA. When the CA responds with a message containing a certificate, the
end entity replies with a confirmation. All messages are
authenticated.
This scheme allows the end entity to request certification of a
locally-generated public key (typically a signature key). The end
entity MAY also choose to request the centralized generation and
certification of another key pair (typically an encryption key pair).
Certification may only be requested for one locally generated public
key (for more, use separate PKIMessages).
The end entity MUST support proof-of-possession of the private key
associated with the locally-generated public key.
Preconditions:
1. The end entity can authenticate the CA's signature based on
out-of-band means
2. The end entity and the CA share a symmetric MACing key
Message flow:
Step# End entity PKI
1 format ir
2 -> ir ->
3 handle ir
4 format ip
5 <- ip <-
6 handle ip
7 format conf
8 -> conf ->
9 handle conf
For this profile, we mandate that the end entity MUST include all
(i.e., one or two) CertReqMsg in a single PKIMessage and that the PKI
(CA) MUST produce a single response PKIMessage which contains the
complete response (i.e., including the OPTIONAL second key pair, if
it was requested and if centralized key generation is supported). For
simplicity, we also mandate that this message MUST be the final one
(i.e., no use of "waiting" status value).
ir:
Field Value
recipient CA name
-- the name of the CA who is being asked to produce a certificate
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this request, based on
-- initial authentication key
senderKID referenceNum
-- the reference number which the CA has previously issued to
-- the end entity (together with the MACing key)
transactionID present
-- implementation-specific value, meaningful to end entity.
-- [If already in use at the CA then a rejection message MUST be
-- produced by the CA]
senderNonce present
-- 128 (pseudo-)random bits
freeText any valid value
body ir (CertReqMessages)
only one or two CertReqMsg
are allowed
-- if more certificates are required requests MUST be packaged in
-- separate PKIMessages
CertReqMsg one or two present
-- see below for details, note: crm[0] means the first (which MUST
-- be present), crm[1] means the second (which is OPTIONAL, and used
-- to ask for a centrally-generated key)
crm[0].certReq. fixed value of zero
certReqId
-- this is the index of the template within the message
crm[0].certReq present
certTemplate
-- MUST include subject public key value, otherwise unconstrained
crm[0].pop... optionally present if public key
POPOSigningKey from crm[0].certReq.certTemplate is
a signing key
-- proof of possession MAY be required in this exchange (see Section
-- B4 for details)
crm[0].certReq. optionally present
controls.archiveOptions
-- the end entity MAY request that the locally-generated private key
-- be archived
crm[0].certReq. optionally present
controls.publicationInfo
-- the end entity MAY ask for publication of resulting cert.
crm[1].certReq fixed value of one
certReqId
-- the index of the template within the message
crm[1].certReq present
certTemplate
-- MUST NOT include actual public key bits, otherwise unconstrained
-- (e.g., the names need not be the same as in crm[0])
crm[0].certReq. present [object identifier MUST be PROT_ENC_ALG]
controls.protocolEncKey
-- if centralized key generation is supported by this CA, this
-- short-term asymmetric encryption key (generated by the end entity)
-- will be used by the CA to encrypt (a symmetric key used to encrypt)
-- a private key generated by the CA on behalf of the end entity
crm[1].certReq. optionally present
controls.archiveOptions
crm[1].certReq. optionally present
controls.publicationInfo
protection present
-- bits calculated using MSG_MAC_ALG
ip:
Field Value
sender CA name
-- the name of the CA who produced the message
messageTime present
-- time at which CA produced message
protectionAlg MS_MAC_ALG
-- only MAC protection is allowed for this response
recipKID referenceNum
-- the reference number which the CA has previously issued to the
-- end entity (together with the MACing key)
transactionID present
-- value from corresponding ir message
senderNonce present
-- 128 (pseudo-)random bits
recipNonce present
-- value from senderNonce in corresponding ir message
freeText any valid value
body ir (CertRepMessage)
contains exactly one response
for each request
-- The PKI (CA) responds to either one or two requests as appropriate.
-- crc[0] denotes the first (always present); crc[1] denotes the
-- second (only present if the ir message contained two requests and
-- if the CA supports centralized key generation).
crc[0]. fixed value of zero
certReqId
-- MUST contain the response to the first request in the corresponding
-- ir message
crc[0].status. present, positive values allowed:
status "granted", "grantedWithMods"
negative values allowed:
"rejection"
crc[0].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[0]. present if and only if
certifiedKeyPair crc[0].status.status is
"granted" or "grantedWithMods"
certificate present unless end entity's public
key is an encryption key and POP
is done in this in-band exchange
encryptedCert present if and only if end entity's
public key is an encryption key and
POP done in this in-band exchange
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
crc[1]. fixed value of one
certReqId
-- MUST contain the response to the second request in the
-- corresponding ir message
crc[1].status. present, positive values allowed:
status "granted", "grantedWithMods"
negative values allowed:
"rejection"
crc[1].status. present if and only if
failInfo crc[0].status.status is "rejection"
crc[1]. present if and only if
certifiedKeyPair crc[0].status.status is "granted"
or "grantedWithMods"
certificate present
privateKey present
publicationInfo optionally present
-- indicates where certificate has been published (present at
-- discretion of CA)
protection present
-- bits calculated using MSG_MAC_ALG
extraCerts optionally present
-- the CA MAY provide additional certificates to the end entity
conf:
Field Value
recipient CA name
-- the name of the CA who was asked to produce a certificate
transactionID present
-- value from corresponding ir and ip messages
senderNonce present
-- value from recipNonce in corresponding ip message
recipNonce present
-- value from senderNonce in corresponding ip message
protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message. The MAC is
-- based on the initial authentication key if only a signing key
-- pair has been sent in ir for certification, or if POP is not
-- done in this in-band exchange. Otherwise, the MAC is based on
-- a key derived from the symmetric key used to decrypt the
-- returned encryptedCert.
senderKID referenceNum
-- the reference number which the CA has previously issued to the
-- end entity (together with the MACing key)
body conf (PKIConfirmContent)
-- this is an ASN.1 NULL
protection present
-- bits calculated using MSG_MAC_ALG
B9. Certificate Request
An (initialized) end entity requests a certificate from a CA (for any
reason). When the CA responds with a message containing a
certificate, the end entity replies with a confirmation. All messages
are authenticated.
The profile for this exchange is identical to that given in Section
B8 with the following exceptions:
- protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request,
response, and confirm messages (the determination in the confirm
message being dependent upon POP considerations for key-
encipherment and key- agreement certificate requests);
- senderKID and recipKID are only present if required for message
verification;
- body is cr or cp;
- protocolEncKey is not present;
- protection bits are calculated according to the protectionAlg
field.
B10. Key Update Request
An (initialized) end entity requests a certificate from a CA (to
update the key pair and corresponding certificate that it already
possesses). When the CA responds with a message containing a
certificate, the end entity replies with a confirmation. All messages
are authenticated.
The profile for this exchange is identical to that given in Section
B8 with the following exceptions:
- protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request,
response, and confirm messages (the determination in the confirm
message being dependent upon POP considerations for key-
encipherment and key- agreement certificate requests);
- senderKID and recipKID are only present if required for message
verification;
- body is kur or kup;
- protection bits are calculated according to the protectionAlg
field.
Appendix C: "Compilable" ASN.1 Module using 1988 Syntax
PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
Certificate, CertificateList, Extensions, AlgorithmIdentifier
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}}
GeneralName, KeyIdentifier, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
CertTemplate, PKIPublicationInfo, EncryptedValue, CertId,
CertReqMessages
FROM PKIXCRMF {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-mod-crmf(5)}}
-- CertificationRequest
-- FROM PKCS10 {no standard ASN.1 module defined;
-- implementers need to create their own module to import
-- from, or directly include the PKCS10 syntax in this module}
-- Locally defined OIDs --
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
}
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName,
-- identifies the sender
recipient GeneralName,
-- identifies the intended recipient
messageTime [0] GeneralizedTime OPTIONAL,
-- time of production of this message (used when sender
-- believes that the transport will be "suitable"; i.e.,
-- that the time will still be meaningful upon receipt)
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
-- algorithm used for calculation of protection bits
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
-- to identify specific keys used for protection
transactionID [4] OCTET STRING OPTIONAL,
-- identifies the transaction; i.e., this will be the same in
-- corresponding request, response and confirmation messages
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message
freeText [7] PKIFreeText OPTIONAL,
-- this may be used to indicate context-specific instructions
-- (this field is intended for human consumption)
generalInfo [8] SEQUENCE SIZE (1..MAX) OF
InfoTypeAndValue OPTIONAL
-- this may be used to convey context-specific information
-- (this field not primarily intended for human consumption)
}
PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
-- text encoded as UTF-8 String (note: each UTF8String SHOULD
-- include an RFC1766 language tag to indicate the language
-- of the contained text)
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
conf [19] PKIConfirmContent, --Confirmation
nested [20] NestedMessageContent, --Nested Message
genm [21] GenMsgContent, --General Message
genp [22] GenRepContent, --General Response
error [23] ErrorMsgContent --Error Message
}
PKIProtection ::= BIT STRING
ProtectedPart ::= SEQUENCE {
header PKIHeader,
body PKIBody
}
PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
iterationCount INTEGER,
-- number of times the OWF is applied
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}
DHBMParameter ::= SEQUENCE {
owf AlgorithmIdentifier,
-- AlgId for a One-Way Function (SHA-1 recommended)
mac AlgorithmIdentifier
-- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
} -- or HMAC [RFC2104, RFC2202])
NestedMessageContent ::= PKIMessage
PKIStatus ::= INTEGER {
granted (0),
-- you got exactly what you asked for
grantedWithMods (1),
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
rejection (2),
-- you don't get it, more information elsewhere in the message
waiting (3),
-- the request body part has not yet been processed,
-- expect to hear more later
revocationWarning (4),
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5),
-- notification that a revocation has occurred
keyUpdateWarning (6)
-- update already done for the oldCertId specified in
-- CertReqMsg
}
PKIFailureInfo ::= BIT STRING {
-- since we can fail in more than one way!
-- More codes may be added in the future if/when required.
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)
badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the authority indicated in the request is different from the
-- one creating the response token
incorrectData (7),
-- the requester's data is incorrect (for notary services)
missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy)
badPOP (9)
-- the proof-of-possession failed
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
OOBCert ::= Certificate
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
-- hashVal is calculated over DER encoding of the
-- subjectPublicKey field of the corresponding cert.
}
POPODecKeyChallContent ::= SEQUENCE OF Challenge
-- One Challenge per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages).
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
-- MUST be present in the first Challenge; MAY be omitted in any
-- subsequent Challenge in POPODecKeyChallContent (if omitted,
-- then the owf used in the immediately preceding Challenge is
-- to be used).
witness OCTET STRING,
-- the result of applying the one-way function (owf) to a
-- randomly-generated INTEGER, A. [Note that a different
-- INTEGER MUST be used for each Challenge.]
challenge OCTET STRING
-- the encryption (under the public key for which the cert.
-- request is being made) of Rand, where Rand is specified as
-- Rand ::= SEQUENCE {
-- int INTEGER,
-- - the randomly-generated INTEGER A (above)
-- sender GeneralName
-- - the sender's name (as included in PKIHeader)
-- }
}
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
-- One INTEGER per encryption key certification request (in the
-- same order as these requests appear in CertReqMessages). The
-- retrieved INTEGER A (above) is returned to the sender of the
-- corresponding Challenge.
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
response SEQUENCE OF CertResponse
}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
-- to match this response with corresponding request (a value
-- of -1 is to be used if certReqId is not specified in the
-- corresponding request)
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL
-- analogous to the id-regInfo-asciiPairs OCTET STRING defined
-- for regInfo in CertReqMsg [CRMF]
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
KeyRecRepContent ::= SEQUENCE {
status PKIStatusInfo,
newSigCert [0] Certificate OPTIONAL,
caCerts [1] SEQUENCE SIZE (1..MAX) OF
Certificate OPTIONAL,
keyPairHist [2] SEQUENCE SIZE (1..MAX) OF
CertifiedKeyPair OPTIONAL
}
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
revocationReason ReasonFlags OPTIONAL,
-- the reason that revocation is requested
badSinceDate GeneralizedTime OPTIONAL,
-- indicates best knowledge of sender
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
-- in same order as was sent in RevReqContent
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
-- IDs for which revocation was requested (same order as status)
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL
-- the resulting CRLs (there may be more than one)
}
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
CertAnnContent ::= Certificate
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
-- extra CRL details(e.g., crl number, reason, location, etc.)
}
CRLAnnContent ::= SEQUENCE OF CertificateList
PKIConfirmContent ::= NULL
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- Example InfoTypeAndValue contents include, but are not limited to:
-- { CAProtEncCert = {id-it 1}, Certificate }
-- { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
-- { EncKeyPairTypes = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
-- { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier }
-- { CAKeyUpdateInfo = {id-it 5}, CAKeyUpdAnnContent }
-- { CurrentCRL = {id-it 6}, CertificateList }
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
-- This construct MAY also be used to define new PKIX Certificate
-- Management Protocol request and response messages, or general-
-- purpose (e.g., announcement) messages for future needs or for
-- specific environments.
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
-- May be sent by EE, RA, or CA (depending on message content).
-- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically
-- be omitted for some of the examples given above. The receiver is
-- free to ignore any contained OBJ. IDs that it does not recognize.
-- If sent from EE to CA, the empty set indicates that the CA may send
-- any/all information that it wishes.
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
-- The receiver is free to ignore any contained OBJ. IDs that it does
-- not recognize.
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
-- implementation-specific error codes
errorDetails PKIFreeText OPTIONAL
-- implementation-specific error details
}
-- The following definition is provided for compatibility reasons with
-- 1988 and 1993 ASN.1 compilers which allow the use of UNIVERSAL class
-- tags (not a part of formal ASN.1); 1997 and subsequent compilers
-- SHOULD comment out this line.
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
END
Appendix D: Registration of MIME Type for Section 5
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkixcmp
MIME media type name: application
MIME subtype name: pkixcmp
Required parameters: -
Optional parameters: -
Encoding considerations:
Content may contain arbitrary octet values (the ASN.1 DER encoding of
a PKI message, as defined in the IETF PKIX Working Group
specifications). base64 encoding is required for MIME e-mail; no
encoding is necessary for HTTP.
Security considerations:
This MIME type may be used to transport Public-Key Infrastructure
(PKI) messages between PKI entities. These messages are defined by
the IETF PKIX Working Group and are used to establish and maintain an
Internet X.509 PKI. There is no requirement for specific security
mechanisms to be applied at this level if the PKI messages themselves
are protected as defined in the PKIX specifications.
Interoperability considerations: -
Published specification: this document
Applications which use this media type:
Applications using certificate management, operational, or ancillary
protocols (as defined by the IETF PKIX Working Group) to send PKI
messages via E-Mail or HTTP.
Additional information:
Magic number (s): -
File extension (s): ".PKI"
Macintosh File Type Code (s): -
Person and email address to contact for further information:
Carlisle Adams, cadams@entrust.com
Intended usage: COMMON
Author/Change controller: Carlisle Adams
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.