RFC 2510
Internet X.509 Public Key Infrastructure Certificate Management Protocols
4. Mandatory PKI Management functions
The PKI management functions outlined in Section 1 above are described in this section. This section deals with functions that are "mandatory" in the sense that all end entity and CA/RA implementations MUST be able to provide the functionality described (perhaps via one of the transport mechanisms defined in Section 5). This part is effectively the profile of the PKI management functionality that MUST be supported. Note that not all PKI management functions result in the creation of a PKI message.4.1 Root CA initialization
[See Section 1.2.2 for this document's definition of "root CA".] A newly created root CA must produce a "self-certificate" which is a Certificate structure with the profile defined for the "newWithNew" certificate issued following a root CA key update. In order to make the CA's self certificate useful to end entities that do not acquire the self certificate via "out-of-band" means, the CA must also produce a fingerprint for its public key. End entities that acquire this fingerprint securely via some "out-of-band" means can then verify the CA's self-certificate and hence the other attributes contained therein.
The data structure used to carry the fingerprint is the OOBCertHash.4.2 Root CA key update
CA keys (as all other keys) have a finite lifetime and will have to be updated on a periodic basis. The certificates NewWithNew, NewWithOld, and OldWithNew (see Section 2.4.1) are issued by the CA to aid existing end entities who hold the current self-signed CA certificate (OldWithOld) to transition securely to the new self- signed CA certificate (NewWithNew), and to aid new end entities who will hold NewWithNew to acquire OldWithOld securely for verification of existing data.4.3 Subordinate CA initialization
[See Section 1.2.2 for this document's definition of "subordinate CA".] From the perspective of PKI management protocols the initialization of a subordinate CA is the same as the initialization of an end entity. The only difference is that the subordinate CA must also produce an initial revocation list.4.4 CRL production
Before issuing any certificates a newly established CA (which issues CRLs) must produce "empty" versions of each CRL which is to be periodically produced.4.5 PKI information request
When a PKI entity (CA, RA, or EE) wishes to acquire information about the current status of a CA it MAY send that CA a request for such information. The CA must respond to the request by providing (at least) all of the information requested by the requester. If some of the information cannot be provided then an error must be conveyed to the requester. If PKIMessages are used to request and supply this PKI information, then the request must be the GenMsg message, the response must be the GenRep message, and the error must be the Error message. These messages are protected using a MAC based on shared secret information (i.e., PasswordBasedMAC) or any other authenticated means (if the end entity has an existing certificate).
4.6 Cross certification
The requester CA is the CA that will become the subject of the cross-certificate; the responder CA will become the issuer of the cross-certificate. The requester CA must be "up and running" before initiating the cross-certification operation.4.6.1 One-way request-response scheme:
The cross-certification scheme is essentially a one way operation; that is, when successful, this operation results in the creation of one new cross-certificate. If the requirement is that cross- certificates be created in "both directions" then each CA in turn must initiate a cross-certification operation (or use another scheme). This scheme is suitable where the two CAs in question can already verify each other's signatures (they have some common points of trust) or where there is an out-of-band verification of the origin of the certification request. Detailed Description: Cross certification is initiated at one CA known as the responder. The CA administrator for the responder identifies the CA it wants to cross certify and the responder CA equipment generates an authorization code. The responder CA administrator passes this authorization code by out-of-band means to the requester CA administrator. The requester CA administrator enters the authorization code at the requester CA in order to initiate the on- line exchange. The authorization code is used for authentication and integrity purposes. This is done by generating a symmetric key based on the authorization code and using the symmetric key for generating Message Authentication Codes (MACs) on all messages exchanged. The requester CA initiates the exchange by generating a random number (requester random number). The requester CA then sends to the responder CA the cross certification request (ccr) message. The fields in this message are protected from modification with a MAC based on the authorization code. Upon receipt of the ccr message, the responder CA checks the protocol version, saves the requester random number, generates its own random number (responder random number) and validates the MAC. It then
generates (and archives, if desired) a new requester certificate that
contains the requester CA public key and is signed with the responder
CA signature private key. The responder CA responds with the cross
certification response (ccp) message. The fields in this message are
protected from modification with a MAC based on the authorization
code.
Upon receipt of the ccp message, the requester CA checks that its own
system time is close to the responder CA system time, checks the
received random numbers and validates the MAC. The requester CA
responds with the PKIConfirm message. The fields in this message are
protected from modification with a MAC based on the authorization
code. The requester CA writes the requester certificate to the
Repository.
Upon receipt of the PKIConfirm message, the responder CA checks the
random numbers and validates the MAC.
Notes:
1. The ccr message must contain a "complete" certification request,
that is, all fields (including, e.g., a BasicConstraints
extension) must be specified by the requester CA.
2. The ccp message SHOULD contain the verification certificate of the
responder CA - if present, the requester CA must then verify this
certificate (for example, via the "out-of-band" mechanism).
4.7 End entity initialization
As with CAs, end entities must be initialized. Initialization of end
entities requires at least two steps:
- acquisition of PKI information
- out-of-band verification of one root-CA public key
(other possible steps include the retrieval of trust condition
information and/or out-of-band verification of other CA public keys).
4.7.1 Acquisition of PKI information
The information REQUIRED is:
- the current root-CA public key
- (if the certifying CA is not a root-CA) the certification path
from the root CA to the certifying CA together with appropriate
revocation lists
- the algorithms and algorithm parameters which the certifying CA
supports for each relevant usage
Additional information could be required (e.g., supported extensions or CA policy information) in order to produce a certification request which will be successful. However, for simplicity we do not mandate that the end entity acquires this information via the PKI messages. The end result is simply that some certification requests may fail (e.g., if the end entity wants to generate its own encryption key but the CA doesn't allow that). The required information MAY be acquired as described in Section 4.5.4.7.2 Out-of-Band Verification of Root-CA Key
An end entity must securely possess the public key of its root CA. One method to achieve this is to provide the end entity with the CA's self-certificate fingerprint via some secure "out-of-band" means. The end entity can then securely use the CA's self-certificate. See Section 4.1 for further details.4.8 Certificate Request
An initialized end entity MAY request a certificate at any time (as part of an update procedure, or for any other purpose). This request will be made using the certification request (cr) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this cr message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a CertRepMessage.4.9 Key Update
When a key pair is due to expire the relevant end entity MAY request a key update - that is, it MAY request that the CA issue a new certificate for a new key pair. The request is made using a key update request (kur) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a key update response (kup) message, which is syntactically identical to a CertRepMessage.5. Transports
The transport protocols specified below allow end entities, RAs and CAs to pass PKI messages between them. There is no requirement for specific security mechanisms to be applied at this level if the PKI messages are suitably protected (that is, if the OPTIONAL PKIProtection parameter is used as specified for each message).
5.1 File based protocol
A file containing a PKI message MUST contain only the DER encoding of one PKI message, i.e., there MUST be no extraneous header or trailer information in the file. Such files can be used to transport PKI messages using, e.g., FTP.5.2 Direct TCP-Based Management Protocol
The following simple TCP-based protocol is to be used for transport of PKI messages. This protocol is suitable for cases where an end entity (or an RA) initiates a transaction and can poll to pick up the results. If a transaction is initiated by a PKI entity (RA or CA) then an end entity must either supply a listener process or be supplied with a polling reference (see below) in order to allow it to pick up the PKI message from the PKI management component. The protocol basically assumes a listener process on an RA or CA which can accept PKI messages on a well-defined port (port number 829). Typically an initiator binds to this port and submits the initial PKI message for a given transaction ID. The responder replies with a PKI message and/or with a reference number to be used later when polling for the actual PKI message response. If a number of PKI response messages are to be produced for a given request (say if some part of the request is handled more quickly than another) then a new polling reference is also returned. When the final PKI response message has been picked up by the initiator then no new polling reference is supplied. The initiator of a transaction sends a "direct TCP-based PKI message" to the recipient. The recipient responds with a similar message. A "direct TCP-based PKI message" consists of: length (32-bits), flag (8-bits), value (defined below) The length field contains the number of octets of the remainder of the message (i.e., number of octets of "value" plus one). All 32-bit values in this protocol are specified to be in network byte order. Message name flag value pkiMsg '00'H DER-encoded PKI message
-- PKI message
pollRep '01'H polling reference (32 bits),
time-to-check-back (32 bits)
-- poll response where no PKI message response ready; use polling
-- reference value (and estimated time value) for later polling
pollReq '02'H polling reference (32 bits)
-- request for a PKI message response to initial message
negPollRep '03'H '00'H
-- no further polling responses (i.e., transaction complete)
partialMsgRep '04'H next polling reference (32 bits),
time-to-check-back (32 bits),
DER-encoded PKI message
-- partial response to initial message plus new polling reference
-- (and estimated time value) to use to get next part of response
finalMsgRep '05'H DER-encoded PKI message
-- final (and possibly sole) response to initial message
errorMsgRep '06'H human readable error message
-- produced when an error is detected (e.g., a polling reference is
-- received which doesn't exist or is finished with)
Where a PKIConfirm message is to be transported (always from the
initiator to the responder) then a pkiMsg message is sent and a
negPollRep is returned.
The sequence of messages which can occur is then:
a) end entity sends pkiMsg and receives one of pollRep, negPollRep,
partialMsgRep or finalMsgRep in response. b) end entity sends
pollReq message and receives one of negPollRep, partialMsgRep,
finalMsgRep or errorMsgRep in response.
The "time-to-check-back" parameter is a 32-bit integer, defined to be
the number of seconds which have elapsed since midnight, January 1,
1970, coordinated universal time. It provides an estimate of the
time that the end entity should send its next pollReq.
5.3 Management Protocol via E-mail
This subsection specifies a means for conveying ASN.1-encoded
messages for the protocol exchanges described in Section 4 via
Internet mail.
A simple MIME object is specified as follows.
Content-Type: application/pkixcmp
Content-Transfer-Encoding: base64
<<the ASN.1 DER-encoded PKIX-CMP message, base64-encoded>>
This MIME object can be sent and received using common MIME processing engines and provides a simple Internet mail transport for PKIX-CMP messages. Implementations MAY wish to also recognize and use the "application/x-pkixcmp" MIME type (specified in earlier versions of this document) in order to support backward compatibility wherever applicable.5.4 Management Protocol via HTTP
This subsection specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 via the HyperText Transfer Protocol. A simple MIME object is specified as follows. Content-Type: application/pkixcmp <<the ASN.1 DER-encoded PKIX-CMP message>> This MIME object can be sent and received using common HTTP processing engines over WWW links and provides a simple browser- server transport for PKIX-CMP messages. Implementations MAY wish to also recognize and use the "application/x-pkixcmp" MIME type (specified in earlier versions of this document) in order to support backward compatibility wherever applicable. SECURITY CONSIDERATIONS This entire memo is about security mechanisms. One cryptographic consideration is worth explicitly spelling out. In the protocols specified above, when an end entity is required to prove possession of a decryption key, it is effectively challenged to decrypt something (its own certificate). This scheme (and many others!) could be vulnerable to an attack if the possessor of the decryption key in question could be fooled into decrypting an arbitrary challenge and returning the cleartext to an attacker. Although in this specification a number of other failures in security are required in order for this attack to succeed, it is conceivable that some future services (e.g., notary, trusted time) could potentially be vulnerable to such attacks. For this reason we re- iterate the general rule that implementations should be very careful about decrypting arbitrary "ciphertext" and revealing recovered "plaintext" since such a practice can lead to serious security vulnerabilities.
Note also that exposing a private key to the CA/RA as a proof-of- possession technique can carry some security risks (depending upon whether or not the CA/RA can be trusted to handle such material appropriately). Implementers are advised to exercise caution in selecting and using this particular POP mechanism.References
[COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC 9594-8: 1990 & 1993 (1995:E), July 1995. [CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Certificate Request Message Format", RFC 2511, March 1999. [MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997. [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release. [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release. [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - PKCS #11: Cryptographic token interface standard", RSA Data Security Inc., Redwood City, California, April 28, 1995. [RFC1847] Galvin, J., Murphy, S. Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/ Encrypted", RFC 1847, October 1995. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- SHA-1", RFC 2202, September 1997. [X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1 December, 1996.
Acknowledgements
The authors gratefully acknowledge the contributions of various members of the PKIX Working Group. Many of these contributions significantly clarified and improved the utility of this specification.Authors' Addresses
Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08, Ottawa, Ontario Canada K1V 1A7 EMail: cadams@entrust.com Stephen Farrell Software and Systems Engineering Ltd. Fitzwilliam Court Leeson Close Dublin 2 IRELAND EMail: stephen.farrell@sse.ie
APPENDIX A: Reasons for the presence of RAs
The reasons which justify the presence of an RA can be split into
those which are due to technical factors and those which are
organizational in nature. Technical reasons include the following.
-If hardware tokens are in use, then not all end entities will have
the equipment needed to initialize these; the RA equipment can
include the necessary functionality (this may also be a matter of
policy).
-Some end entities may not have the capability to publish
certificates; again, the RA may be suitably placed for this.
-The RA will be able to issue signed revocation requests on behalf
of end entities associated with it, whereas the end entity may not
be able to do this (if the key pair is completely lost).
Some of the organizational reasons which argue for the presence of an
RA are the following.
-It may be more cost effective to concentrate functionality in the
RA equipment than to supply functionality to all end entities
(especially if special token initialization equipment is to be
used).
-Establishing RAs within an organization can reduce the number of
CAs required, which is sometimes desirable.
-RAs may be better placed to identify people with their
"electronic" names, especially if the CA is physically remote from
the end entity.
-For many applications there will already be in place some
administrative structure so that candidates for the role of RA are
easy to find (which may not be true of the CA).
Appendix B. PKI Management Message Profiles.
This appendix contains detailed profiles for those PKIMessages which MUST be supported by conforming implementations (see Section 4). Profiles for the PKIMessages used in the following PKI management operations are provided: - root CA key update - information request/response - cross-certification request/response (1-way) - initial registration/certification - basic authenticated scheme - certificate request - key update <<Later versions of this document may extend the above to include profiles for the operations listed below (along with other operations, if desired).>> - revocation request - certificate publication - CRL publication B1. General Rules for interpretation of these profiles. 1. Where OPTIONAL or DEFAULT fields are not mentioned in individual profiles, they SHOULD be absent from the relevant message (i.e., a receiver can validly reject a message containing such fields as being syntactically incorrect). Mandatory fields are not mentioned if they have an obvious value (e.g., pvno). 2. Where structures occur in more than one message, they are separately profiled as appropriate. 3. The algorithmIdentifiers from PKIMessage structures are profiled separately. 4. A "special" X.500 DN is called the "NULL-DN"; this means a DN containing a zero-length SEQUENCE OF RelativeDistinguishedNames (its DER encoding is then '3000'H). 5. Where a GeneralName is required for a field but no suitable value is available (e.g., an end entity produces a request before knowing its name) then the GeneralName is to be an X.500 NULL-DN (i.e., the Name field of the CHOICE is to contain a NULL-DN). This special value can be called a "NULL-GeneralName". 6. Where a profile omits to specify the value for a GeneralName then the NULL-GeneralName value is to be present in the relevant PKIMessage field. This occurs with the sender field of the PKIHeader for some messages.
7. Where any ambiguity arises due to naming of fields, the profile
names these using a "dot" notation (e.g., "certTemplate.subject"
means the subject field within a field called certTemplate).
8. Where a "SEQUENCE OF types" is part of a message, a zero-based
array notation is used to describe fields within the SEQUENCE OF
(e.g., crm[0].certReq.certTemplate.subject refers to a
subfield of the first CertReqMsg contained in a request message).
9. All PKI message exchanges in Sections B7-B10 require a PKIConfirm
message to be sent by the initiating entity. This message is not
included in some of the profiles given since its body is NULL and
its header contents are clear from the context. Any authenticated
means can be used for the protectionAlg (e.g., password-based MAC,
if shared secret information is known, or signature).
B2. Algorithm Use Profile
The following table contains definitions of algorithm uses within PKI
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 RFC 1766 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.