CA/RA. This field MUST be present if the purpose is to prove
possession of the private key. The field SHOULD be present if
archiving a key and the archive agent is expected to decrypt the
key.
The fields of PrivatekeyInfo are define as:
version MUST be the value 0
privateKeyAlgorithm contains the identifier for the private key
object
privateKey is an octet string whose contents is the private key
and whose format is defined by the value of privateKeyAlgorithm.
attributes is a set of attributes. They are extended information
that is part of the private key information.
4.2.2. Private Key Structures
We are defining the structures here to be used for three algorithms.
4.2.2.1. D-H Private Keys
When creating a PrivateKeyInfo for a D-H key, the following rules
apply:
1. The privateKeyAlgorithm MUST be set to id-dh-private-number.
The parameter for id-dh-private-number is DomainParameters
(imported from [PKIXALG]).
2. The ASN structure for privateKey MUST be
DH-PrivateKey ::= INTEGER
3. The attributes field MUST be omitted.
4.2.2.2. DSA Private Keys
When creating a PrivateKeyInfo for a DSA key, the following rules
apply:
1. The privateKeyAlgorithm MUST be set to id-dsa. The parameters
for id-dsa is Dss-Parms (imported from [PKIXALG]).
2. The ASN structure for privateKey MUST be
DSA-PrivateKey ::= INTEGER
3. The attributes field MUST be omitted.
4.2.2.3. RSA Private Keys
When creating a PrivateKeyInfo for an RSA key, the following rules
apply:
1. The privateKeyAlgorithm MUST be set to rsaEncryption.
2. The ASN structure for privateKey MUST be RSAPrivateKey (defined
in [PKCS1])
3. The attributes field MUST be omitted.
4.2.3. Challenge-Response Guidelines
The following provides guidelines to enrollment protocol authors
about how an indirect proof-of-possession is expected to work and
about some of the areas where one needs to be careful in crafting the
messages to implement this POP method.
1. The original enrollment request includes a proof of identity of
some type and the public portion of the encryption key. Note
that the proof of identity needs to cover the public portion of
the encryption key to prevent substitution attacks (where the
attacker changes your public key for his public key).
2. The response message from the server includes an encrypted data
value of some type. That value needs to be authenticated in some
fashion as having come from the server. The specification needs
to include the specifics of how this value is returned for the
different key types. For RSA keys, the value can be specified as
being directly encrypted by the RSA public key; this will not
work for a D-H key where you need to specify an indirect
mechanism to encrypt the value.
3. The second request message includes a hash of the decrypted
value. This message MUST NOT be just the hash of the encrypted
value, as one should never "sign" a completely random value. It
is desirable to include information such as the identity string
in the hashing process so that this can be made explicitly. This
returned value MUST be included in a second proof of identity.
It is strongly suggested that transaction identifiers and nonce
values be required when performing indirect POP, as this allows for
1) tying the different messages in the process together and 2)
letting each entity inject some amount of random data into the
process of doing identity proofs.
4.3. Key Agreement Keys
POP for key agreement keys is accomplished by one of four different
methods. The first three are identical to those presented above for
key encryption keys. The fourth method takes advantage of the fact
that a shared secret is produced and that the value can be used to
MAC information.
When the direct or indirect encryption methods presented above are
used, the CA/RA will need to create an ephemeral key for those cases
where the encryption algorithm parameters do not match between the
CA/RA and the requestor.
The end entity may also MAC the certificate request (using a shared
secret key derived from computation) as a fourth alternative for
demonstrating POP. This option may be used only if the CA/RA already
has a certificate that is known to the end entity and if the Subject
is able to use the CA/RA’s parameters.
For the DH key agreement algorithm, all implementations MUST support
the static DH Proof-of-Possession. Details on this algorithm can be
found in section 3 of [RFC2875]. NOTE: If either the subject or
issuer name in the CA certificate is empty, then the alternative name
should be used in its place.
4.4. Use of Password-Based MAC
This MAC algorithm was designed to take a shared secret (a password)
and use it to compute a check value over a piece of information. The
assumption is that, without the password, the correct check value
cannot be computed. The algorithm computes the one-way function
multiple times in order to slow down any dictionary attacks against
the password value.
The algorithm identifier and parameter structure used for Password-
Based MAC is:
id-PasswordBasedMAC OBJECT IDENTIFIER ::=
{ 1 2 840 113533 7 66 13}
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
)
The fields of PEMParameter have the following meaning:
salt contains a randomly generated value used in computing the key
of the MAC process. The salt SHOULD be at least 8 octets (64
bits) long.
owf identifies the algorithm and associated parameters used to
compute the key used in the MAC process. All implementations MUST
support SHA-1.
iterationCount identifies the number of times the hash is applied
during the key computation process. The iterationCount MUST be a
minimum of 100. Many people suggest using values as high as 1000
iterations as the minimum value. The trade off here is between
protection of the password from attacks and the time spent by the
server processing all of the different iterations in deriving
passwords. Hashing is generally considered a cheap operation but
this may not be true with all hash functions in the future.
mac identifies the algorithm and associated parameters of the MAC
function to be used. All implementations MUST support HMAC-SHA1
[HMAC]. All implementations SHOULD support DES-MAC and Triple-
DES-MAC [PKCS11].
The following is pseudo-code for the algorithm:
Inputs:
pw - an octet string containing the user’s password
data - an octet string containing the value to be MAC-ed
Iter - iteration count
Output:
MAC - an octet string containing the resultant MAC value
1. Generate a random salt value S
2. Append the salt to the pw. K = pw || salt.
3. Hash the value of K. K = HASH(K)
4. If Iter is greater than zero. Iter = Iter - 1. Goto step 3.
5. Compute an HMAC as documented in [HMAC].
MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )
Where opad and ipad are defined in [HMAC].
5. CertRequest syntax
The CertRequest syntax consists of a request identifier, a template
of certificate content, and an optional sequence of control
information.
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, --Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL } --at least one must be present
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
The fields of CertRequest have the following meaning:
certReqId contains an integer value that is used by the
certificate requestor to associate a specific certificate request
with a certificate response.
certTemplate contains a template of an X.509 certificate. The
requestor fills in those fields for which specific values are
desired. Details on the fields are given below.
controls contains attributes that are not part of the certificate,
but control the context in which the certificate is to be issued.
Details on the controls defined in this document can be found in
section 6. Other documents may define other controls. CRPs are
responsible for specifying which controls are required.
The fields of CertTemplate have the following meaning:
version MUST be 2 if supplied. It SHOULD be omitted.
serialNumber MUST be omitted. This field is assigned by the CA
during certificate creation.
signingAlg MUST be omitted. This field is assigned by the CA
during certificate creation.
issuer is normally omitted. It would be filled in with the CA
that the requestor desires to issue the certificate in situations
where an RA is servicing more than one CA.
validity is normally omitted. It can be used to request that
certificates either start at some point in the future or expire at
some specific time. A case where this field would commonly be
used is when a cross certificate is issued for a CA. In this case
the validity of an existing certificate would be placed in this
field so that the new certificate would have the same validity
period as the existing certificate. If validity is not omitted,
then at least one of the sub-fields MUST be specified. The sub-
fields are as follows:
notBefore contains the requested start time of the certificate.
The time follows the same rules as the notBefore time in
[PROFILE].
notAfter contains the requested expiration time of the
certificate. The time follows the same rules as the notAfter
time in [PROFILE].
subject is filled in with the suggested name for the requestor.
This would normally be filled in by a name that has been
previously issued to the requestor by the CA.
publicKey contains the public key for which the certificate is
being created. This field MUST be filled in if the requestor
generates its own key. The field is omitted if the key is
generated by the RA/CA.
issuerUID MUST be omitted. This field has been deprecated in
[PROFILE].
subjectUID MUST be omitted. This field has been deprecated in
[PROFILE].
extensions contains extensions that the requestor wants to have
placed in the certificate. These extensions would generally deal
with things such as setting the key usage to keyEncipherment.
With the exception of the publicKey field, the CA/RA is permitted to
alter any requested field. The returned certificate needs to be
checked by the requestor to see if the fields have been set in an
acceptable manner. CA/RA SHOULD use the template fields if possible.
There are cases where all fields of the template can be omitted. If
the key generation is being done at the CA/RA and the identity proof
is placed in a different location (such as the id-regCtrl-regToken
below), then there are no fields that need to be specified by the
certificate requestor.
6. Controls Syntax
The generator of a CertRequest may include one or more control values
pertaining to the processing of the request.
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
The following controls are defined by this document: regToken
(section 6.1); authenticator (section 6.2); pkiPublicationInfo
(section 6.3); pkiArchiveOptions (section 6.4); oldCertID (section
6.5); protocolEncrKey (section 6.6). Each CRP MUST define the set of
controls supported by that protocol. Additional controls may be
defined by additional RFCs or by the CRP protocol itself.
6.1. Registration Token Control
A regToken control contains one-time information (either based on a
secret value or other shared information) intended to be used by the
CA to verify the identity of the subject prior to issuing a
certificate. Upon receipt of a certification request containing a
value for regToken, the receiving CA verifies the information in
order to confirm the identity claimed in the certification request.
The value for regToken may be generated by the CA and provided out of
band to the subscriber, or may otherwise be available to both the CA
and the subscriber. The security of any out-of-band exchange should
be commensurate with the risk that the CA will tolerate with regard
to accepting an intercepted value from someone other than the
intended subscriber. The regToken value is not encrypted on return,
if the data is considered to be sensitive, it needs to be shrouded by
the requestor.
The regToken control is used only for initialization of an end entity
into the PKI, whereas the authenticator control (see section 7.2) can
be used for the initial as well as subsequent certification requests.
In some instances of use the value for regToken could be a text
string or a numeric quantity such as a random number. In the latter
case, the value is encoded as a text string representation of the
binary quantity. The encoding of regToken SHALL be UTF8String.
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
Without prior agreement between the subscriber and CA agents, this
value would be a textual shared secret of some type. If a computed
value based on that shared secret is to be used instead, it is
suggested that the CRP define a new registration control for that
specific computation.
6.2. Authenticator Control
An authenticator control contains information used on an ongoing
basis to establish a non-cryptographic check of identity in
communication with the CA. Examples include: mother’s maiden name,
last four digits of social security number, or other knowledge-based
information shared with the subscriber’s CA; a hash of such
information; or other information produced for this purpose. The
value for an authenticator control may be generated by the subscriber
or by the CA.
In some instances of use, the value for authenticator could be a text
string or a numeric quantity such as a random number. The value in
the latter case is encoded as a text string representation of the
binary quantity. The encoding of authenticator SHALL be UTF8String.
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
When deciding whether to use an authenticator or a regToken, use the
following guidelines. If the value is a one-time usage value, then
regToken would be used. If the value has a long-term usage, then the
authenticator control would be used.
6.3. Publication Information Control
The pkiPublicationInfo control enables subscribers to influence the
CA/RA’s publication of the certificate. This control is considered
advisory and can be ignored by CAs/RAs. It is defined by the
following OID and syntax:
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
The fields of PKIPublicationInfo have the following meaning:
action indicates whether or not the requestor wishes the CA/RA to
publish the certificate. The values and their means are:
dontPublish indicates that the requester wishes the CA/RA not
to publish the certificate (this may indicate that the
requester intends to publish the certificate him/herself). If
dontPublish is used, the pubInfos field MUST be omitted.
pleasePublish indicates that the requestor wishes the CA/RA to
publish the certificate.
pubInfos holds the locations where the requestor desires the CA/RA
to publish the certificate. This field is omitted if the
dontPublish choice is selected. If the requestor wants to specify
some locations for the certificate to be published, and to allow
the CA/RA to publish in other locations, it would specify multiple
values of the SinglePubInfo structure, one of which would be
dontCare.
The fields of SinglePubInfo have the following meaning:
pubMethod indicates the address type for the location at which the
requestor desires the certificate to be placed by the CA/RA.
dontCare indicates that the CA/RA can publish the certificate
in whatever locations it chooses. If dontCare is used, the
pubInfos field MUST be omitted.
x500 indicates that the requestor wishes for the CA/RA to
publish the certificate in a specific location. The location
is indicated in the x500 field of pubLocation.
ldap indicates that the requestor wishes for the CA/RA to
publish the certificate in a specific location. The location
is indicated in the ldap field of pubLocation.
web indicates that the requestor wishes for the CA/RA to
publish the certificate in a specific location. The location
is indicated in the http field of pubLocation.
pubLocation contains the address at which the certificate is to be
placed. The choice in the general name field is dictated by the
pubMethod selection in this structure.
Publication locations can be supplied in any order. All locations
are to be processed by the CA for purposes of publication.
6.4. Archive Options Control
The pkiArchiveOptions control enables subscribers to supply
information needed to establish an archive of the private key
corresponding to the public key of the certification request. It is
defined by the following OID and syntax:
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters which allow the private key to be re-generated
archiveRemGenPrivKey [2] BOOLEAN }
-- set to TRUE if sender wishes receiver to archive the private
-- key of a key pair that the receiver generates in response to
-- this request; set to FALSE if no archival is desired.
EncryptedKey ::= CHOICE {
encryptedValue EncryptedValue, -- deprecated
envelopedData [0] EnvelopedData }
-- The encrypted private key MUST be placed in the envelopedData
-- encryptedContentInfo encryptedContent OCTET STRING.
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
-- the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
-- the symmetric algorithm used to encrypt the value
encSymmKey [2] BIT STRING OPTIONAL,
-- the (encrypted) symmetric key used to encrypt the value
keyAlg [3] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the symmetric key
valueHint [4] OCTET STRING OPTIONAL,
-- a brief description or identifier of the encValue content
-- (may be meaningful only to the sending entity, and used only
-- if EncryptedValue might be re-examined by the sending entity
-- in the future)
encValue BIT STRING }
-- The use of the EncryptedValue field has been deprecated in favor
-- of the EnvelopedData structure.
--
-- When EncryptedValue is used to carry a private key (as opposed to
-- a certificate), implementations MUST support the encValue field
-- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
-- section 12.11. If encValue contains some other format/encoding
-- for the private key, the first octet of valueHint MAY be used
-- to indicate the format/encoding (but note that the possible values
-- of this octet are not specified at this time). In all cases, the
-- intendedAlg field MUST be used to indicate at least the OID of
-- the intended algorithm of the private key, unless this information
-- is known a priori to both sender and receiver by some other means.
KeyGenParameters ::= OCTET STRING
The fields of PKIArchiveOptions have the following meaning:
encryptedPrivKey contains an encrypted version of the private key.
keyGenParameters contains the information needed by the requestor
to regenerate the private key. As an example, for many RSA
implementations one could send the first random number(s) tested
for primality. The structure to go here is not defined by this
document. CRPs that define content for this structure MUST define
not only the content that is to go here, but also how that data is
shrouded from unauthorized access.
archiveRemGenPrivKey indicates that the requestor desires that the
key generated by the CA/RA on the requestor’s behalf be archived.
The fields of EncryptedKey have the following meaning: