-- analogous to the id-regInfo-utf8Pairs string defined
-- for regInfo in CertReqMsg [CRMF]
}
CertifiedKeyPair ::= SEQUENCE {
certOrEncCert CertOrEncCert,
privateKey [0] EncryptedValue OPTIONAL,
-- see [CRMF] for comment on encoding
publicationInfo [1] PKIPublicationInfo OPTIONAL
}
CertOrEncCert ::= CHOICE {
certificate [0] Certificate,
encryptedCert [1] EncryptedValue
}
Only one of the failInfo (in PKIStatusInfo) and certificate (in
CertifiedKeyPair) fields can be present in each CertResponse
(depending on the status). For some status values (e.g., waiting),
neither of the optional fields will be present.
Given an EncryptedCert and the relevant decryption key, the
certificate may be obtained. The purpose of this is to allow a CA to
return the value of a certificate, but with the constraint that only
the intended recipient can obtain the actual certificate. The
benefit of this approach is that a CA may reply with a certificate
even in the absence of a proof that the requester is the end entity
that can use the relevant private key (note that the proof is not
obtained until the certConf message is received by the CA). Thus,
the CA will not have to revoke that certificate in the event that
something goes wrong with the proof-of-possession (but MAY do so
anyway, depending upon policy).
5.3.5. Key Update Request Content
For key update requests the CertReqMessages syntax is used.
Typically, SubjectPublicKeyInfo, KeyId, and Validity are the template
fields that may be supplied for each key to be updated. This message
is intended to be used to request updates to existing (non-revoked
and non-expired) certificates (therefore, it is sometimes referred to
as a "Certificate Update" operation). An update is a replacement
certificate containing either a new subject public key or the current
subject public key (although the latter practice may not be
appropriate for some environments).
See Appendix C and [CRMF] for CertReqMessages syntax.
5.3.6. Key Update Response Content
For key update responses, the CertRepMessage syntax is used. The
response is identical to the initialization response.
See Section 5.3.4 for CertRepMessage syntax.
5.3.7. Key Recovery Request Content
For key recovery requests the syntax used is identical to the
initialization request CertReqMessages. Typically,
SubjectPublicKeyInfo and KeyId are the template fields that may be
used to supply a signature public key for which a certificate is
required (see Appendix D profiles for further information).
See Appendix C and [CRMF] for CertReqMessages syntax. Note that if a
key history is required, the requester must supply a Protocol
Encryption Key control in the request message.
5.3.8. Key Recovery Response Content
For key recovery responses, the following syntax is used. For some
status values (e.g., waiting) none of the optional fields will be
present.
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
}
5.3.9. Revocation Request Content
When requesting revocation of a certificate (or several
certificates), the following data structure is used. The name of the
requester is present in the PKIHeader structure.
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
crlEntryDetails Extensions OPTIONAL
}
5.3.10. Revocation Response Content
The revocation response is the response to the above message. If
produced, this is sent to the requester of the revocation. (A
separate revocation announcement message MAY be sent to the subject
of the certificate for which revocation was requested.)
RevRepContent ::= SEQUENCE {
status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList
OPTIONAL
}
5.3.11. Cross Certification Request Content
Cross certification requests use the same syntax (CertReqMessages) as
normal certification requests, with the restriction that the key pair
MUST have been generated by the requesting CA and the private key
MUST NOT be sent to the responding CA. This request MAY also be used
by subordinate CAs to get their certificates signed by the parent CA.
See Appendix C and [CRMF] for CertReqMessages syntax.
5.3.12. Cross Certification Response Content
Cross certification responses use the same syntax (CertRepMessage) as
normal certification responses, with the restriction that no
encrypted private key can be sent.
See Section 5.3.4 for CertRepMessage syntax.
5.3.13. CA Key Update Announcement Content
When a CA updates its own key pair, the following data structure MAY
be used to announce this event.
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate,
newWithOld Certificate,
newWithNew Certificate
}
5.3.14. Certificate Announcement
This structure MAY be used to announce the existence of certificates.
Note that this message is intended to be used for those cases (if
any) where there is no pre-existing method for publication of
certificates; it is not intended to be used where, for example, X.500
is the method for publication of certificates.
CertAnnContent ::= Certificate
5.3.15. Revocation Announcement
When a CA has revoked, or is about to revoke, a particular
certificate, it MAY issue an announcement of this (possibly upcoming)
event.
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
willBeRevokedAt GeneralizedTime,
badSinceDate GeneralizedTime,
crlDetails Extensions OPTIONAL
}
A CA MAY use such an announcement to warn (or notify) a subject that
its certificate is about to be (or has been) revoked. This would
typically be used where the request for revocation did not come from
the subject concerned.
The willBeRevokedAt field contains the time at which a new entry will
be added to the relevant CRLs.
5.3.16. CRL Announcement
When a CA issues a new CRL (or set of CRLs) the following data
structure MAY be used to announce this event.
CRLAnnContent ::= SEQUENCE OF CertificateList
5.3.17. PKI Confirmation Content
This data structure is used in the protocol exchange as the final
PKIMessage. Its content is the same in all cases -- actually there
is no content since the PKIHeader carries all the required
information.
PKIConfirmContent ::= NULL
Use of this message for certificate confirmation is NOT RECOMMENDED;
certConf SHOULD be used instead. Upon receiving a PKIConfirm for a
certificate response, the recipient MAY treat it as a certConf with
all certificates being accepted.
5.3.18. Certificate Confirmation Content
This data structure is used by the client to send a confirmation to
the CA/RA to accept or reject certificates.
CertConfirmContent ::= SEQUENCE OF CertStatus
CertStatus ::= SEQUENCE {
certHash OCTET STRING,
certReqId INTEGER,
statusInfo PKIStatusInfo OPTIONAL
}
For any particular CertStatus, omission of the statusInfo field
indicates ACCEPTANCE of the specified certificate. Alternatively,
explicit status details (with respect to acceptance or rejection) MAY
be provided in the statusInfo field, perhaps for auditing purposes at
the CA/RA.
Within CertConfirmContent, omission of a CertStatus structure
corresponding to a certificate supplied in the previous response
message indicates REJECTION of the certificate. Thus, an empty
CertConfirmContent (a zero-length SEQUENCE) MAY be used to indicate
rejection of all supplied certificates. See Section 5.2.8, item (2),
for a discussion of the certHash field with respect to proof-of-
possession.
5.3.19. PKI General Message Content
InfoTypeAndValue ::= SEQUENCE {
infoType OBJECT IDENTIFIER,
infoValue ANY DEFINED BY infoType OPTIONAL
}
-- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
5.3.19.1. CA Protocol Encryption Certificate
This MAY be used by the EE to get a certificate from the CA to use to
protect sensitive information during the protocol.
GenMsg: {id-it 1}, < absent >
GenRep: {id-it 1}, Certificate | < absent >
EEs MUST ensure that the correct certificate is used for this
purpose.
5.3.19.2. Signing Key Pair Types
This MAY be used by the EE to get the list of signature algorithms
(e.g., RSA, DSA) whose subject public key values the CA is willing to
certify. Note that for the purposes of this exchange, rsaEncryption
and rsaWithSHA1, for example, are considered to be equivalent; the
question being asked is, "Is the CA willing to certify an RSA public
key?"
GenMsg: {id-it 2}, < absent >
GenRep: {id-it 2}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
5.3.19.3. Encryption/Key Agreement Key Pair Types
This MAY be used by the client to get the list of encryption/key
agreement algorithms whose subject public key values the CA is
willing to certify.
GenMsg: {id-it 3}, < absent >
GenRep: {id-it 3}, SEQUENCE SIZE (1..MAX) OF
AlgorithmIdentifier
5.3.19.4. Preferred Symmetric Algorithm
This MAY be used by the client to get the CA-preferred symmetric
encryption algorithm for any confidential information that needs to
be exchanged between the EE and the CA (for example, if the EE wants
to send its private decryption key to the CA for archival purposes).
GenMsg: {id-it 4}, < absent >
GenRep: {id-it 4}, AlgorithmIdentifier
5.3.19.5. Updated CA Key Pair
This MAY be used by the CA to announce a CA key update event.
GenMsg: {id-it 5}, CAKeyUpdAnnContent
5.3.19.6. CRL
This MAY be used by the client to get a copy of the latest CRL.
GenMsg: {id-it 6}, < absent >
GenRep: {id-it 6}, CertificateList
5.3.19.7. Unsupported Object Identifiers
This is used by the server to return a list of object identifiers
that it does not recognize or support from the list submitted by the
client.
GenRep: {id-it 7}, SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER
5.3.19.8. Key Pair Parameters
This MAY be used by the EE to request the domain parameters to use
for generating the key pair for certain public-key algorithms. It
can be used, for example, to request the appropriate P, Q, and G to
generate the DH/DSA key, or to request a set of well-known elliptic
curves.
GenMsg: {id-it 10}, OBJECT IDENTIFIER -- (Algorithm object-id)
GenRep: {id-it 11}, AlgorithmIdentifier | < absent >
An absent infoValue in the GenRep indicates that the algorithm
specified in GenMsg is not supported.
EEs MUST ensure that the parameters are acceptable to it and that the
GenRep message is authenticated (to avoid substitution attacks).
5.3.19.9. Revocation Passphrase
This MAY be used by the EE to send a passphrase to a CA/RA for the
purpose of authenticating a later revocation request (in the case
that the appropriate signing private key is no longer available to
authenticate the request). See Appendix B for further details on the
use of this mechanism.
GenMsg: {id-it 12}, EncryptedValue
GenRep: {id-it 12}, < absent >
5.3.19.10. ImplicitConfirm
See Section 5.1.1.1 for the definition and use of {id-it 13}.
5.3.19.11. ConfirmWaitTime
See Section 5.1.1.2 for the definition and use of {id-it 14}.
5.3.19.12 Original PKIMessage
See Section 5.1.3 for the definition and use of {id-it 15}.
5.3.19.13. Supported Language Tags
This MAY be used to determine the appropriate language tag to use in
subsequent messages. The sender sends its list of supported
languages (in order, most preferred to least); the receiver returns
the one it wishes to use. (Note: each UTF8String MUST include a
language tag.) If none of the offered tags are supported, an error
MUST be returned.
GenMsg: {id-it 16}, SEQUENCE SIZE (1..MAX) OF UTF8String
GenRep: {id-it 16}, SEQUENCE SIZE (1) OF UTF8String
5.3.20. PKI General Response Content
GenRepContent ::= SEQUENCE OF InfoTypeAndValue
Examples of GenReps that MAY be supported include those listed in the
subsections of Section 5.3.19.
5.3.21. Error Message Content
This data structure MAY be used by EE, CA, or RA to convey error
info.
ErrorMsgContent ::= SEQUENCE {
pKIStatusInfo PKIStatusInfo,
errorCode INTEGER OPTIONAL,
errorDetails PKIFreeText OPTIONAL
}
This message MAY be generated at any time during a PKI transaction.
If the client sends this request, the server MUST respond with a
PKIConfirm response, or another ErrorMsg if any part of the header is
not valid. Both sides MUST treat this message as the end of the
transaction (if a transaction is in progress).
If protection is desired on the message, the client MUST protect it
using the same technique (i.e., signature or MAC) as the starting
message of the transaction. The CA MUST always sign it with a
signature key.
5.3.22. Polling Request and Response
This pair of messages is intended to handle scenarios in which the
client needs to poll the server in order to determine the status of
an outstanding ir, cr, or kur transaction (i.e., when the "waiting"
PKIStatus has been received).
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER }
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason PKIFreeText OPTIONAL }
The following clauses describe when polling messages are used, and
how they are used. It is assumed that multiple certConf messages can
be sent during transactions. There will be one sent in response to
each ip, cp, or kup that contains a CertStatus for an issued
certificate.
1. In response to an ip, cp, or kup message, an EE will send a
certConf for all issued certificates and, following the ack, a
pollReq for all pending certificates.
2. In response to a pollReq, a CA/RA will return an ip, cp, or kup
if one or more of the pending certificates is ready; otherwise,
it will return a pollRep.
3. If the EE receives a pollRep, it will wait for at least as long
as the checkAfter value before sending another pollReq.
4. If an ip, cp, or kup is received in response to a pollReq, then
it will be treated in the same way as the initial response.
START
|
v
Send ir
| ip
v
Check status
of returned <------------------------+
certs |
| |
+------------------------>|<------------------+ |
| | | |
| (issued) v (waiting) | |
Add to <----------- Check CertResponse ------> Add to |
conf list for each certificate pending list |
/ |
/ |
(conf list) / (empty conf list) |
/ ip |
/ +----------------+
(empty pending list) / | pRep
END <---- Send certConf Send pReq------------>Wait
| ^ ^ |
| | | |
+-----------------+ +---------------+
(pending list)
In the following exchange, the end entity is enrolling for two
certificates in one request.
Step End Entity PKI
--------------------------------------------------------------------
1 Format ir
2 -> ir ->
3 Handle ir
4 Manual intervention is
required for both certs.
5 <- ip <-
6 Process ip
7 Format pReq
8 -> pReq ->
9 Check status of cert requests
10 Certificates not ready
11 Format pRep
12 <- pRep <-
13 Wait
14 Format pReq
15 -> pReq ->
16 Check status of cert requests
17 One certificate is ready
18 Format ip
19 <- ip <-
20 Handle ip
21 Format certConf
22 -> certConf ->
23 Handle certConf
24 Format ack
25 <- pkiConf <-
26 Format pReq
27 -> pReq ->
28 Check status of certificate
29 Certificate is ready
30 Format ip
31 <- ip <-
31 Handle ip
32 Format certConf
33 -> certConf ->
34 Handle certConf
35 Format ack
36 <- pkiConf <-
6. Mandatory PKI Management Functions
Some of the PKI management functions outlined in Section 3.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. This part is effectively the profile of
the PKI management functionality that MUST be supported. Note,
however, that the management functions described in this section do
not need to be accomplished using the PKI messages defined in Section
5 if alternate means are suitable for a given environment (see
Appendix D for profiles of the PKIMessages that MUST be supported).
6.1. Root CA Initialization
[See Section 3.1.1.2 for this document’s definition of "root CA".]