mac AlgorithmIdentifier
}
In the above protectionAlg, the salt value is appended to the shared
secret input. The OWF is then applied iterationCount times, where
the salted secret is the input to the first iteration and, for each
successive iteration, the input is set to be the output of the
previous iteration. The output of the final iteration (called
"BASEKEY" for ease of reference, with a size of "H") is what is used
to form the symmetric key. If the MAC algorithm requires a K-bit key
and K <= H, then the most significant K bits of BASEKEY are used. If
K > H, then all of BASEKEY is used for the most significant H bits of
the key, OWF("1" || BASEKEY) is used for the next most significant H
bits of the key, OWF("2" || BASEKEY) is used for the next most
significant H bits of the key, and so on, until all K bits have been
derived. [Here "N" is the ASCII byte encoding the number N and "||"
represents concatenation.]
Note: it is RECOMMENDED that the fields of PBMParameter remain
constant throughout the messages of a single transaction (e.g.,
ir/ip/certConf/pkiConf) in order to reduce the overhead associated
with PasswordBasedMac computation).
5.1.3.2. DH Key Pairs
Where the sender and receiver possess Diffie-Hellman certificates
with compatible DH parameters, in order to protect the message the
end entity must generate a symmetric key based on its private DH key
value and the DH public key of the recipient of the PKI message.
PKIProtection will contain a MAC value keyed with this derived
symmetric key and the protectionAlg will be the following:
id-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])
In the above protectionAlg, OWF is applied to the result of the
Diffie-Hellman computation. The OWF output (called "BASEKEY" for
ease of reference, with a size of "H") is what is used to form the
symmetric key. If the MAC algorithm requires a K-bit key and K <= H,
then the most significant K bits of BASEKEY are used. If K > H, then
all of BASEKEY is used for the most significant H bits of the key,
OWF("1" || BASEKEY) is used for the next most significant H bits of
the key, OWF("2" || BASEKEY) is used for the next most significant H
bits of the key, and so on, until all K bits have been derived.
[Here "N" is the ASCII byte encoding the number N and "||" represents
concatenation.]
5.1.3.3. Signature
In this case, the sender possesses a signature key pair and simply
signs the PKI message. PKIProtection will contain the signature
value and the protectionAlg will be an AlgorithmIdentifier for a
digital signature (e.g., md5WithRSAEncryption or dsaWithSha-1).
5.1.3.4. Multiple Protection
In cases where an end entity sends a protected PKI message to an RA,
the RA MAY forward that message to a CA, attaching its own protection
(which MAY be a MAC or a signature, depending on the information and
certificates shared between the RA and the CA). This is accomplished
by nesting the entire message sent by the end entity within a new PKI
message. The structure used is as follows.
NestedMessageContent ::= PKIMessages
(The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch
the requests of several EEs in a single new message. For simplicity,
all messages in the batch MUST be of the same type (e.g., ir).) If
the RA wishes to modify the message(s) in some way (e.g., add
particular field values or new extensions), then it MAY create its
own desired PKIBody. The original PKIMessage from the EE MAY be
included in the generalInfo field of PKIHeader (to accommodate, for
example, cases in which the CA wishes to check POP or other
information on the original EE message). The infoType to be used in
this situation is {id-it 15} (see Section 5.3.19 for the value of
id-it) and the infoValue is PKIMessages (contents MUST be in the same
order as the requests in PKIBody).
5.2. Common Data Structures
Before specifying the specific types that may be placed in a PKIBody,
we define some data structures that are used in more than one case.
5.2.1. Requested Certificate Contents
Various PKI management messages require that the originator of the
message indicate some of the fields that are required to be present
in a certificate. The CertTemplate structure allows an end entity or
RA to specify as much as it wishes about the certificate it requires.
CertTemplate is identical to a Certificate, but with all fields
optional.
Note that even if the originator completely specifies the contents of
a certificate it requires, a CA is free to modify fields within the
certificate actually issued. If the modified certificate is
unacceptable to the requester, the requester MUST send back a
certConf message that either does not include this certificate (via a
CertHash), or does include this certificate (via a CertHash) along
with a status of "rejected". See Section 5.3.18 for the definition
and use of CertHash and the certConf message.
See Appendix C and [CRMF] for CertTemplate syntax.
5.2.2. Encrypted Values
Where encrypted values (restricted, in this specification, to be
either private keys or certificates) are sent in PKI messages, the
EncryptedValue data structure is used.
See [CRMF] for EncryptedValue syntax.
Use of this data structure requires that the creator and intended
recipient be able to encrypt and decrypt, respectively. Typically,
this will mean that the sender and recipient have, or are able to
generate, a shared secret key.
If the recipient of the PKIMessage already possesses a private key
usable for decryption, then the encSymmKey field MAY contain a
session key encrypted using the recipient’s public key.
5.2.3. Status codes and Failure Information for PKI Messages
All response messages will include some status information. The
following values are defined.
PKIStatus ::= INTEGER {
accepted (0),
grantedWithMods (1),
rejection (2),
waiting (3),
revocationWarning (4),
revocationNotification (5),
keyUpdateWarning (6)
}
Responders may use the following syntax to provide more information
about failure cases.
PKIFailureInfo ::= BIT STRING {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
badDataFormat (5),
wrongAuthority (6),
incorrectData (7),
missingTimeStamp (8),
badPOP (9),
certRevoked (10),
certConfirmed (11),
wrongIntegrity (12),
badRecipientNonce (13),
timeNotAvailable (14),
unacceptedPolicy (15),
unacceptedExtension (16),
addInfoNotAvailable (17),
badSenderNonce (18),
badCertTemplate (19),
signerNotTrusted (20),
transactionIdInUse (21),
unsupportedVersion (22),
notAuthorized (23),
systemUnavail (24),
systemFailure (25),
duplicateCertReq (26)
}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL
}
5.2.4. Certificate Identification
In order to identify particular certificates, the CertId data
structure is used.
See [CRMF] for CertId syntax.
5.2.5. Out-of-band root CA Public Key
Each root CA must be able to publish its current public key via some
"out-of-band" means. While such mechanisms are beyond the scope of
this document, we define data structures that can support such
mechanisms.
There are generally two methods available: either the CA directly
publishes its self-signed certificate, or this information is
available via the Directory (or equivalent) and the CA publishes a
hash of this value to allow verification of its integrity before use.
OOBCert ::= Certificate
The fields within this certificate are restricted as follows:
o The certificate MUST be self-signed (i.e., the signature must be
verifiable using the SubjectPublicKeyInfo field);
o The subject and issuer fields MUST be identical;
o If the subject field is NULL, then both subjectAltNames and
issuerAltNames extensions MUST be present and have exactly the
same value;
o The values of all other extensions must be suitable for a self-
signed certificate (e.g., key identifiers for subject and issuer
must be the same).
OOBCertHash ::= SEQUENCE {
hashAlg [0] AlgorithmIdentifier OPTIONAL,
certId [1] CertId OPTIONAL,
hashVal BIT STRING
}
The intention of the hash value is that anyone who has securely
received the hash value (via the out-of-band means) can verify a
self-signed certificate for that CA.
5.2.6. Archive Options
Requesters may indicate that they wish the PKI to archive a private
key value using the PKIArchiveOptions structure.
See [CRMF] for PKIArchiveOptions syntax.
5.2.7. Publication Information
Requesters may indicate that they wish the PKI to publish a
certificate using the PKIPublicationInfo structure.
See [CRMF] for PKIPublicationInfo syntax.
5.2.8. Proof-of-Possession Structures
If the certification request is for a signing key pair (i.e., a
request for a verification certificate), then the proof-of-possession
of the private signing key is demonstrated through use of the
POPOSigningKey structure.
See Appendix C and [CRMF] for POPOSigningKey syntax, but note that
POPOSigningKeyInput has the following semantic stipulations in this
specification.
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
publicKeyMAC PKMACValue
},
publicKey SubjectPublicKeyInfo
}
On the other hand, if the certification request is for an encryption
key pair (i.e., a request for an encryption certificate), then the
proof-of-possession of the private decryption key may be demonstrated
in one of three ways.
5.2.8.1. Inclusion of the Private Key
By the inclusion of the private key (encrypted) in the CertRequest
(in the thisMessage field of POPOPrivKey (see Appendix C) or in the
PKIArchiveOptions control structure, depending upon whether or not
archival of the private key is also desired).
5.2.8.2. Indirect Method
By having the CA return not the certificate, but an encrypted
certificate (i.e., the certificate encrypted under a randomly-
generated symmetric key, and the symmetric key encrypted under the
public key for which the certification request is being made) -- this
is the "indirect" method mentioned previously in Section 4.3.2. The
end entity proves knowledge of the private decryption key to the CA
by providing the correct CertHash for this certificate in the
certConf message. This demonstrates POP because the EE can only
compute the correct CertHash if it is able to recover the
certificate, and it can only recover the certificate if it is able to
decrypt the symmetric key using the required private key. Clearly,
for this to work, the CA MUST NOT publish the certificate until the
certConf message arrives (when certHash is to be used to demonstrate
POP). See Section 5.3.18 for further details.
5.2.8.3. Challenge-Response Protocol
By having the end entity engage in a challenge-response protocol
(using the messages POPODecKeyChall and POPODecKeyResp; see below)
between CertReqMessages and CertRepMessage -- this is the "direct"
method mentioned previously in Section 4.3.2. (This method would
typically be used in an environment in which an RA verifies POP and
then makes a certification request to the CA on behalf of the end
entity. In such a scenario, the CA trusts the RA to have done POP
correctly before the RA requests a certificate for the end entity.)
The complete protocol then looks as follows (note that req’ does not
necessarily encapsulate req as a nested message):
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req’ --->
<--- rep -----
---- conf --->
<--- ack -----
<--- rep -----
---- conf --->
<--- ack -----
This protocol is obviously much longer than the 3-way exchange given
in choice (2) above, but allows a local Registration Authority to be
involved and has the property that the certificate itself is not
actually created until the proof-of-possession is complete. In some
environments, a different order of the above messages may be
required, such as the following (this may be determined by policy):
EE RA CA
---- req ---->
<--- chall ---
---- resp --->
---- req’ --->
<--- rep -----
<--- rep -----
---- conf --->
---- conf --->
<--- ack -----
<--- ack -----
If the cert. request is for a key agreement key (KAK) pair, then the
POP can use any of the 3 ways described above for enc. key pairs,
with the following changes: (1) the parenthetical text of bullet 2)
is replaced with "(i.e., the certificate encrypted under the
symmetric key derived from the CA’s private KAK and the public key
for which the certification request is being made)"; (2) the first
parenthetical text of the challenge field of "Challenge" below is
replaced with "(using PreferredSymmAlg (see Section 5.3.19.4 and
Appendix E.5) and a symmetric key derived from the CA’s private KAK
and the public key for which the certification request is being
made)". Alternatively, the POP can use the POPOSigningKey structure
given in [CRMF] (where the alg field is DHBasedMAC and the signature
field is the MAC) as a fourth alternative for demonstrating POP if
the CA already has a D-H certificate that is known to the EE.
The challenge-response messages for proof-of-possession of a private
decryption key are specified as follows (see [MvOV97], p.404 for
details). Note that this challenge-response exchange is associated
with the preceding cert. request message (and subsequent cert.
response and confirmation messages) by the transactionID used in the
PKIHeader and by the protection (MACing or signing) applied to the
PKIMessage.
POPODecKeyChallContent ::= SEQUENCE OF Challenge
Challenge ::= SEQUENCE {
owf AlgorithmIdentifier OPTIONAL,
witness OCTET STRING,
challenge OCTET STRING
}
Note that the size of Rand needs to be appropriate for encryption
under the public key of the requester. Given that "int" will
typically not be longer than 64 bits, this leaves well over 100 bytes
of room for the "sender" field when the modulus is 1024 bits. If, in
some environment, names are so long that they cannot fit (e.g., very
long DNs), then whatever portion will fit should be used (as long as
it includes at least the common name, and as long as the receiver is
able to deal meaningfully with the abbreviation).
POPODecKeyRespContent ::= SEQUENCE OF INTEGER
5.2.8.4. Summary of PoP Options
The text in this section provides several options with respect to POP
techniques. Using "SK" for "signing key", "EK" for "encryption key",
and "KAK" for "key agreement key", the techniques may be summarized
as follows:
RAVerified;
SKPOP;
EKPOPThisMessage;
KAKPOPThisMessage;
KAKPOPThisMessageDHMAC;
EKPOPEncryptedCert;
KAKPOPEncryptedCert;
EKPOPChallengeResp; and
KAKPOPChallengeResp.
Given this array of options, it is natural to ask how an end entity
can know what is supported by the CA/RA (i.e., which options it may
use when requesting certificates). The following guidelines should
clarify this situation for EE implementers.
RAVerified. This is not an EE decision; the RA uses this if and only
if it has verified POP before forwarding the request on to the CA, so
it is not possible for the EE to choose this technique.
SKPOP. If the EE has a signing key pair, this is the only POP method
specified for use in the request for a corresponding certificate.
EKPOPThisMessage and KAKPOPThisMessage. Whether or not to give up
its private key to the CA/RA is an EE decision. If the EE decides to
reveal its key, then these are the only POP methods available in this
specification to achieve this (and the key pair type will determine
which of these two methods to use).
KAKPOPThisMessageDHMAC. The EE can only use this method if (1) the
CA has a DH certificate available for this purpose, and (2) the EE
already has a copy of this certificate. If both these conditions
hold, then this technique is clearly supported and may be used by the
EE, if desired.
EKPOPEncryptedCert, KAKPOPEncryptedCert, EKPOPChallengeResp,
KAKPOPChallengeResp. The EE picks one of these (in the
subsequentMessage field) in the request message, depending upon
preference and key pair type. The EE is not doing POP at this point;
it is simply indicating which method it wants to use. Therefore, if
the CA/RA replies with a "badPOP" error, the EE can re-request using
the other POP method chosen in subsequentMessage. Note, however,
that this specification encourages the use of the EncryptedCert
choice and, furthermore, says that the challenge-response would
typically be used when an RA is involved and doing POP verification.
Thus, the EE should be able to make an intelligent decision regarding
which of these POP methods to choose in the request message.
5.3. Operation-Specific Data Structures
5.3.1. Initialization Request
An Initialization request message contains as the PKIBody a
CertReqMessages data structure, which specifies the requested
certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity
are the template fields which may be supplied for each certificate
requested (see Appendix D profiles for further information). This
message is intended to be used for entities when first initializing
into the PKI.
See Appendix C and [CRMF] for CertReqMessages syntax.
5.3.2. Initialization Response
An Initialization response message contains as the PKIBody an
CertRepMessage data structure, which has for each certificate
requested a PKIStatusInfo field, a subject certificate, and possibly
a private key (normally encrypted with a session key, which is itself
encrypted with the protocolEncrKey).
See Section 5.3.4 for CertRepMessage syntax. Note that if the PKI
Message Protection is "shared secret information" (see Section
5.1.3), then any certificate transported in the caPubs field may be
directly trusted as a root CA certificate by the initiator.
5.3.3. Certification Request
A Certification request message contains as the PKIBody a
CertReqMessages data structure, which specifies the requested
certificates. This message is intended to be used for existing PKI
entities who wish to obtain additional certificates.
See Appendix C and [CRMF] for CertReqMessages syntax.
Alternatively, the PKIBody MAY be a CertificationRequest (this
structure is fully specified by the ASN.1 structure
CertificationRequest given in [PKCS10]). This structure may be
required for certificate requests for signing key pairs when
interoperation with legacy systems is desired, but its use is
strongly discouraged whenever not absolutely necessary.
5.3.4. Certification Response
A Certification response message contains as the PKIBody a
CertRepMessage data structure, which has a status value for each
certificate requested, and optionally has a CA public key, failure
information, a subject certificate, and an encrypted private key.
CertRepMessage ::= SEQUENCE {
caPubs [1] SEQUENCE SIZE (1..MAX) OF Certificate
OPTIONAL,
response SEQUENCE OF CertResponse
}
CertResponse ::= SEQUENCE {
certReqId INTEGER,
status PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
rspInfo OCTET STRING OPTIONAL