encryptedValue is longer used. This field has been deprecated
along with the EncryptedValue structure.
envelopedData contains the encrypted value of the private key.
CPRs that use this structure MUST define the entity or entities
for whom the data is to be encrypted (the EE, escrow agents, CAs)
and how that key or set of keys is to be determined. Details on
constructing an EnvelopedData structure are found in [CMS]. The
encrypted content MUST be an id-ct-encKeyWithID. The identifier
can be omitted unless this structure is also being used to do
proof-of-possession.
6.5. OldCert ID Control
If present, the OldCertID control specifies the certificate to be
updated by the current certification request. The OID and syntax is:
id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
6.6. Protocol Encryption Key Control
If present, the protocolEncrKey control specifies a key that the CA
is to use in encrypting a response to CertReqMessages. The OID for
this control is id-regCtrl-protocolEncrKey. The parameter structure
for this field is SubjectPublicKeyInfo. (This structure is defined
in [PROFILE].)
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
This control is used when a CA has information to send to the
subscriber that needs to be encrypted. Such information includes a
private key generated by the CA for use by the subscriber.
7. RegInfo Controls
This section documents the controls that are to be placed in the
regInfo field of the CertReqMsg structure.
7.1. utf8Pairs
This control is used to convey text-based information from the
Subject to an RA to a CA issuing a certificate. The OID for this
structure is id-regInfo-utf8Paris and has a type of UTF8String.
id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
The name is terminated by the question mark character (’?’). The
value is terminated by the percent character ’%’. Name value pairs
can be repeated. Thus the syntax is:
Name?Value%[Name?Value%]*
The %xx mechanism of [RFC1738] is used to encode ’?’ (%3f) and ’%’
(%25) if they are not being used for their reserved purpose. Names
MUST NOT start with a numeric character.
This control can appear multiple times in the regInfo structure.
Resolution of conflicts of information is a matter of local policy on
the RA/CA.
Appendix A contains a set of common names and data formats
corresponding to fields that commonly appear in certificates and
directories.
7.2. certReq
This control is designed to deal with the problem where an RA needs
to modify the certificate template proposed by a Subject, but the
Subject used the certificate template as part of its POP calculation.
In this case, the RA can place a new certificate template in the
regInfo sequence.
This control has the OID id-regInfo-certReq and the structure
CertRequest. There can only be one instance of this attribute in the
regInfo sequence. If this control exists in the regInfo structure,
then the certificate template in the request is ignored. The RA MUST
copy all data from the core template to this attribute.
id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
8. Object Identifiers
The OID id-pkix has the value
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
-- arc for Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
-- arc for Registration Info in CRMF
id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
9. Security Considerations
Enrollment protocols, by their very nature, involve large amounts of
private information. This can include private keys, identity
numbers, credit card numbers, and the like. The security of any CRP
is based on the security mechanisms of the protocol and/or process
used to communicate between CAs, RAs and EEs. All protocols must
provide for masking, either via encryption or off-line processing, of
all subscriber-sensitive information.
Many enrollment protocols provide for the initial establishment of
identity between the CA/RA and the EE by the use of a token.
Generally this token is delivered using an out-of-band delivery
method (such as the governmental mail system). The security of any
out-of-band exchange needs to be commensurate with the risk that the
CA/RA will tolerate with regard to interception of the token by a
third party.
Implementation must implement Proof-of-Possession (POP) values during
certificate enrollment processes. A good POP algorithm needs to
provide proof of two things: 1) that the key is tied to a specific
user and 2) that the user has use of the key in question. Failure to
implement POP allows people to create certificates where the public
key and the name values do not correctly bind. This allows for
impersonation on signature keys and interception of encrypted
messages.
Implementations must use high entropy random number generators in
producing private keys. Implementations must randomly generate
content-encryption keys, message-authentication keys, initialization
vectors (IVs), salt, and padding. The use of inadequate pseudo-
random number generators (PRNGs) to generate cryptographic keys can
result in little or no security. An attacker may find it much easier
to reproduce the PRNG environment that produced the keys, searching
the resulting small set of possibilities, rather than brute force
searching the whole key space. The generation of quality random
numbers is difficult. RFC 4086 [RANDOM] offers important guidance in
this area and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
PRNG technique.
Implementations must protect private keys. The compromise of a
signer’s private key permits third parties to masquerade as the
signer. The compromise of a decryption private key allows for
interception of messages by a third party.
One feature of the certificate message request syntax is for the key
generation to be performed remotely from the creation of the
certificate request. This feature should never be used for
generation of signing keys. If signing keys are generated for the
user, then an element of repudiation comes into play. The user can
claim that an item was signed by the entity that generated the key as
well as any entity that might have seen the key value during transfer
from the generator the to EE. Care must be taken to protect
encryption keys by the remote key generator to protect against
interception of the keys by a third party. This means that the
encryption algorithms used need to be secure, and a content
encryption key or a key encryption key must be used to mask the
private key during transport back to the user. CRP protocols must
never assume that a signature key generated by the user can be used
to decrypt the package in which an encryption private key is
transported.
This document describes a method by which key escrow may be done.
There are several issues that need to be taken into account when
doing key escrow. First, the client must be able to correctly
identify the entity to which a key is to be escrowed or the CRP must
provide a method by which the client can discover this information.
A CRP cannot assume that the key escrow agent and the CA are the same
entity and thus have the same names. Second, the algorithms used to
mask the private key or other key generation information during
transport to the escrow agent need to be commensurate with the value
of the data being protected by the key. Third, the escrow agent
needs to provide sufficient safeguards that an escrowed key is
returned only to entities that should be able to obtain the private
key. Generally, this should be restricted to the entity that
escrowed the data. Fourth, the escrow data base needs to be stored
in a secure manner. One common method for doing this is to re-
encrypt the data to keys that only the escrow agent has access to.
In this case, one may need to escrow the escrow agent key as well.
Access to either the escrow agent or the archived key would amount to
access to all private keys that have been escrowed with that agent.
10. References
10.1. Normative References
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[PKCS11] RSA Laboratories, The Public-Key Cryptography Standards -
"PKCS #11 v2.11: Cryptographic Token Interface Standard",
RSA Security Inc., June 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIXALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, April 2002.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[RFC2875] Prafullchandra, H. and J. Schaad, "Diffie-Hellman
Proof-of-Possession Algorithms", RFC 2875, July 2000.
10.2. Informative References
[DSS] National Institute of Standards and Technology, FIPS Pub
186: Digital Signature Standard, May 1994.
[PKCS8] RSA Laboratories, "PKCS #8: Private-Key Information Syntax
Standard", PKCS #8 v1.2, November 1993.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
HMAC-SHA-1", RFC 2202, September 1997.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
11. Acknowledgements
The working group would like to thank Michael Myers, Carlisle Adams,
Dave Solo, and David Kemp, who authored the original version of this
document.
The working group also gratefully acknowledges the contributions of
Barbara Fox, Warwick Ford, Russ Housley, and John Pawling, whose
review and comments significantly clarified and improved the utility
of this specification. The members of the ca-talk mailing list also
provided significant input with respect to interoperability testing.
The text of Appendix C (Why do POP) was taken from an e-mail message
by Al Arsenault and was originally part of the PKIX Roadmap document.
Appendix A. Use of RegInfo for Name-Value Pairs
The "value" field of the id-regInfo-utf8Pairs string (with "tag"
field equal to 12 and appropriate "length" field) will contain a
series of UTF-8 name/value pairs.
This Appendix lists some common examples of such pairs for the
purpose of promoting interoperability among independent
implementations of this specification. It is recognized that this
list is not exhaustive and will grow with time and implementation
experience.
A.1. Defined Names
The following table defines a recommended set of named elements. The
value in the column "Name Value" is the exact text string that will
appear in the regInfo.
Name Value
----------
version -- version of this variation of regInfo use
corp_company -- company affiliation of subscriber
org_unit -- organizational unit
mail_firstName -- personal name component
mail_middleName -- personal name component
mail_lastName -- personal name component
mail_email -- subscriber’s email address
jobTitle -- job title of subscriber
employeeID -- employee identification number or string
mailStop -- mail stop
issuerName -- name of CA
subjectName -- name of Subject
validity -- validity interval
For example:
version?1%corp_company?Example, Inc.%org_unit?Engineering%
mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
mail_email?john@example.com%
A.2. IssuerName, SubjectName, and Validity Value Encoding
When they appear in id-regInfo-utf8Pairs syntax as named elements,
the encoding of values for issuerName, subjectName, and validity
SHALL use the following syntax. The characters [] indicate an
optional field, ::= and | have their usual BNF meanings, and all
other symbols (except spaces, which are insignificant) outside non-
terminal names are terminals. Alphabetics are case-sensitive.
issuerName ::= <names>
subjectName ::= <names>
<names> ::= <name> | <names>:<name>
<validity> ::= validity ? [<notbefore>]-[<notafter>]
<notbefore> ::= <time>
<notafter> ::= <time>
Where <time> is UTC time in the form YYYYMMDD[HH[MM[SS]]]. HH, MM,
and SS default to 00 and are omitted if at the and of value 00.
Example validity encoding:
validity?-19991231%
is a validity interval with no value for notBefore, and a value of
December 31, 1999 for notAfter.
Each name comprises a single character name form identifier, followed
by a name value of one or more UTF-8 characters. Within a name
value, when it is necessary to disambiguate a character that has
formatting significance at an outer level, the escape sequence %xx
SHALL be used, where xx represents the hex value for the encoding
concerned. The percent symbol is represented by %%.
<name> ::= X<xname>|O<oname>|E<ename>|D<dname>|U<uname>|I<iname>
Name forms and value formats are as follows:
X.500 directory name form (identifier "X"):
<xname> ::= <rdns>
<rdns> ::= <rdn> | <rdns> , <rdn>
<rdn> ::= <avas>
<avas> ::= <ava> | <avas> + <ava>
<ava> ::= <attyp> = <avalue>
<attyp> ::= OID.<oid> | <stdat>
Standard attribute type <stdat> is an alphabetic attribute type
identifier from the following set:
C (country)
L (locality)
ST (state or province)
O (organization)
OU (organizational unit)
CN (common name)
STREET (street address)
E (E-mail address).
<avalue> is a name component in the form of a UTF-8 character string
of 1 to 64 characters, with the restriction that in the IA5 subset of
UTF-8 only the characters of ASN.1 PrintableString may be used.
Other name form (identifier "O"):
<oname> ::= <oid> , <utf8string>
E-mail address (rfc822name) name form (identifier "E"):
<ename> ::= <ia5string>
DNS name form (identifier "D"):
<dname> ::= <ia5string>
URI name form (identifier "U"):
<uname> ::= <ia5string>
IP address (identifier "I"):
<iname> ::= <oid>
For example:
issuerName?XOU=Our CA,O=Example,C=US% subjectName?XCN=John Smith,
O=Example, C=US, E=john@example.com%
Appendix B. ASN.1 Structures and OIDs
PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Directory Authentication Framework (X.509)
Version, AlgorithmIdentifier, Name, Time,
SubjectPublicKeyInfo, Extensions, UniqueIdentifier, Attribute
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18)} -- found in [PROFILE]
-- Certificate Extensions (X.509)
GeneralName
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit(19)} -- found in [PROFILE]
-- Cryptographic Message Syntax
EnvelopedData
FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) cms-2004(24) }; -- found in [CMS]
-- The following definition may be uncommented for use with
-- ASN.1 compilers that do not understand UTF8String.
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents of this type correspond to RFC 2279.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 7 }
-- arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- content types
-- Core definitions for this module
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
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
Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type OBJECT IDENTIFIER,
value ANY DEFINED BY type }
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
-- used if the RA has already verified that the requester is in
-- possession of the private key
signature [1] POPOSigningKey,
keyEncipherment [2] POPOPrivKey,
keyAgreement [3] POPOPrivKey }
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSigningKeyInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
-- The signature (using "algorithmIdentifier") is on the
-- DER-encoded value of poposkInput. NOTE: If the CertReqMsg
-- certReq CertTemplate contains the subject and publicKey values,
-- then poposkInput MUST be omitted and the signature MUST be
-- computed over the DER-encoded value of CertReqMsg certReq. If
-- the CertReqMsg certReq CertTemplate does not contain both the
-- public key and subject values (i.e., if it contains only one
-- of these, or neither), then poposkInput MUST be present and
-- MUST be signed.
POPOSigningKeyInput ::= SEQUENCE {
authInfo CHOICE {
sender [0] GeneralName,
-- used only if an authenticated identity has been
-- established for the sender (e.g., a DN from a
-- previously-issued and currently-valid certificate)
publicKeyMAC PKMACValue },
-- used if no authenticated GeneralName currently exists for
-- the sender; publicKeyMAC contains a password-based MAC
-- on the DER-encoded value of publicKey
publicKey SubjectPublicKeyInfo } -- from CertTemplate
PKMACValue ::= SEQUENCE {
algId AlgorithmIdentifier,
-- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
-- parameter value is PBMParameter
value BIT STRING }
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 [HMAC, RFC2202])
POPOPrivKey ::= CHOICE {
thisMessage [0] BIT STRING, -- Deprecated
-- possession is proven in this message (which contains the private
-- key itself (encrypted for the CA))
subsequentMessage [1] SubsequentMessage,
-- possession will be proven in a subsequent message
dhMAC [2] BIT STRING, -- Deprecated
agreeMAC [3] PKMACValue,
encryptedKey [4] EnvelopedData }
-- for keyAgreement (only), possession is proven in this message
-- (which contains a MAC (over the DER-encoded value of the
-- certReq parameter in CertReqMsg, which MUST include both subject
-- and publicKey) based on a key derived from the end entity’s
-- private DH key and the CA’s public DH key);
SubsequentMessage ::= INTEGER {
encrCert (0),
-- requests that resulting certificate be encrypted for the
-- end entity (following which, POP will be proven in a
-- confirmation message)
challengeResp (1) }
-- requests that CA engage in challenge-response exchange with
-- end entity in order to prove private key possession
-- Object identifier assignments --
-- Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
id-regCtrl-regToken OBJECT IDENTIFIER ::= { id-regCtrl 1 }
--with syntax:
RegToken ::= UTF8String
id-regCtrl-authenticator OBJECT IDENTIFIER ::= { id-regCtrl 2 }
--with syntax:
Authenticator ::= UTF8String
id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
--with syntax:
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
--with syntax:
PKIArchiveOptions ::= CHOICE {
encryptedPrivKey [0] EncryptedKey,
-- the actual value of the private key
keyGenParameters [1] KeyGenParameters,
-- parameters that 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