idnits 2.16.02
/tmp/draft-ietf-pkix-rfc2511bis-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3667, Section 5.1 on line 19.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1873.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
36), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 36.
** The document claims conformance with section 10 of RFC 2026, but uses
some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of
RFC 2026, you should not claim conformance with it if you have changed to
using RFC 3978/3979 boilerplate.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure
Acknowledgement.
** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure
Acknowledgement.
** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure
Invitation.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing expiration date. The document expiration date should appear on
the first and last page.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 1
longer page, the longest (page 1) being 2101 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
== Couldn't figure out when the document was first submitted -- there may
comments or warnings related to the use of a disclaimer for pre-RFC5378
work that could not be issued because of this. Please check the Legal
Provisions document at https://trustee.ietf.org/license-info to determine
if you need the pre-RFC5378 disclaimer.
-- The document date (March 2005) is 5184 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'RFC2119' is mentioned on line 116, but not defined
-- Looks like a reference, but probably isn't: '0' on line 1725
-- Looks like a reference, but probably isn't: '1' on line 1656
-- Looks like a reference, but probably isn't: '2' on line 1658
-- Looks like a reference, but probably isn't: '3' on line 1660
-- Looks like a reference, but probably isn't: '4' on line 1662
-- Looks like a reference, but probably isn't: '5' on line 1510
-- Looks like a reference, but probably isn't: '6' on line 1511
-- Looks like a reference, but probably isn't: '7' on line 1512
-- Looks like a reference, but probably isn't: '8' on line 1513
-- Looks like a reference, but probably isn't: '9' on line 1514
== Missing Reference: 'UNIVERSAL 12' is mentioned on line 1473, but not
defined
== Unused Reference: 'RFC 2119' is defined on line 1257, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 3447 (ref. 'PKCS1') (Obsoleted by RFC
8017)
** Downref: Normative reference to an Informational RFC: RFC 2104 (ref.
'HMAC')
-- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS11'
** Obsolete normative reference: RFC 3280 (ref. 'PROFILE') (Obsoleted by
RFC 5280)
** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC
3852)
** Obsolete normative reference: RFC 2875 (Obsoleted by RFC 6955)
-- Obsolete informational reference (is this intentional?): RFC 1750 (ref.
'RANDOM') (Obsoleted by RFC 4086)
-- Obsolete informational reference (is this intentional?): RFC 1738
(Obsoleted by RFC 4248, RFC 4266)
Summary: 17 errors (**), 0 flaws (~~), 8 warnings (==), 16 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Internet Draft J. Schaad
3 PKIX Working Group Soaring Hawk Consulting
4 March 2005
5 expires in six months
7 Internet X.509 Public Key Infrastructure
8 Certificate Request Message Format (CRMF)
9
11 Status of this Memo
13 This document is an Internet-Draft and is in full conformance with
14 all provisions of Section 10 of RFC 2026.
16 By submitting this Internet-Draft, I certify that any applicable
17 patent or other IPR claims of which I am aware have been disclosed,
18 or will be disclosed, and any of which I become aware will be
19 disclosed, in accordance with RFC 3668.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that other
23 groups may also distribute working documents as Internet-Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at
31 http://www.ietf.org/ietf/1id-abstracts.txt
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 Copyright (C) The Internet Society (2004). All Rights Reserved.
38 Abstract
40 This document describes the Certificate Request Message Format (CRMF)
41 syntax and semantics. This syntax is used to convey a request for a
42 certificate to a Certification Authority (CA), possibly via a
43 Registration Authority (RA), for the purposes of X.509 certificate
44 production. The request will typically include a public key and the
45 associated registration information. This document does not define a
46 certificate request protocol
48 Table Of Contents
50 1. Introduction and Terminology......................................3
51 2. Overview..........................................................3
52 2.1 Changes since RFC 2511...........................................4
53 3. CertReqMessage Syntax..............................................4
54 4. Proof of Possession (POP)..........................................5
55 4.1 Signature Key POP................................................7
56 4.2 Key Encipherment Keys............................................9
57 4.2.1 Private Key Info Content Type...............................10
58 4.2.2 Private Key Structures......................................12
59 4.2.3 Challenge-Response Guidelines...............................13
60 4.3 Key Agreement Keys..............................................13
61 4.4 Use of Password-Based MAC......................................14
62 5. CertRequest syntax...............................................15
63 6. Controls Syntax...................................................17
64 6.1 Registration Token Control......................................18
65 6.2 Authenticator Control...........................................18
66 6.3 Publication Information Control.................................19
67 6.4 Archive Options Control........................................20
68 6.5 OldCert ID Control.............................................22
69 6.6 Protocol Encryption Key Control................................22
70 7. RegInfo Controls.................................................23
71 7.1 utf8Pairs......................................................23
72 7.2 certReq........................................................23
73 8. Object Identifiers...............................................24
74 9. Security Considerations..........................................24
75 10. IANA Considerations..............................................26
76 11. References.......................................................26
77 11.1 Normative References..........................................26
78 11.2 Informative References.........................................27
79 12. Acknowledgments..................................................27
80 13. Authors' Addresses...............................................27
81 Appendix A. Use of RegInfo for Name-Value Pairs......................28
82 A.1. Defined Names..................................................28
83 A.2 IssuerName, SubjectName and Validity Value Encoding.............29
84 Appendix B. ASN.1 Structures and OIDs................................30
85 Appendix C. Why do Proof of Possession (POP).........................36
86 Appendix D - Change History..........................................37
87 D.1 Changes from -06 to -07.........................................37
88 D.2 Changes from -07 to -08.........................................38
89 D.3 Changes from -08 to -09.........................................38
90 Appendix E - Full Copyright Statement................................38
92 1. Introduction and Terminology
94 This document describes the Certificate Request Message Format
95 (CRMF). A Certificate Request Message object is used within a
96 protocol to convey a request for a certificate to a Certification
97 Authority (CA), possibly via a Registration Authority (RA), for the
98 purposes of X.509 certificate production. The request will typically
99 include a public key and the associated registration information.
101 The certificate request object defined in this document is not a
102 standalone protocol. The information defined in this document is
103 designed to be used by an externally define Certificate Request
104 Protocol (CRP). The referencing protocol is expected to define what
105 algorithms are used, what registration information and control
106 structures are defined. Many of the requirements in this document
107 refer to the referencing Certificate Request Protocol (CRP).
109 Certificate requests may be submitted by an RA requesting a
110 certificate on behalf of a Subject, by a CA requesting a cross-
111 certificate from another CA, or directly by an End Entity (EE).
113 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
114 in this document (in uppercase, as shown) are to be interpreted as
115 described in RFC 2119 [RFC2119].
117 2. Overview
119 Construction of a certification request involves the following steps:
121 a) A CertRequest object is constructed. This object may include the
122 public key, all or a portion of the Subject name, other requested
123 certificate fields, and additional control information related to the
124 registration process. Depending on the CRP this information can be
125 specified by the Subject and potentially modified by an RA, or be
126 specified by the RA based on knowledge of the Subject or
127 documentation presented by the Subject.
129 b) If required, a proof of possession (of the private key
130 corresponding to the public key for which a certificate is being
131 requested) value is calculated.
133 c) Additional registration information can be combined with the
134 proof of possession value and the CertRequest structure to form a
135 CertReqMessage. Additional registration information can be added by
136 both the Subject and an RA.
138 d) The CertReqMessage is securely communicated to a CA. Specific
139 means of secure transport are to be specified by each CRP that refers
140 to this document.
142 2.1 Changes since RFC 2511
144 1. Addition of an introduction section.
146 2. Addition of the concept of a CRP and language relating to CRPs.
148 3. In section 6.2 changed regToken to authenticator.
150 4. Add information describing the contents of the EncryptedValue
151 structure.
153 5. Changed name and contents of OID {id-regInfo 1}.
155 6. Added text detailing what goes into the fields of the different
156 structures defined in the document.
158 7. Replaced appendix A with a reference to [RFC 2875]. The only
159 difference is that the old text specified to use subject alt name
160 instead of subject name if subject name was empty. This is not
161 possible for a CA certificate issued using PKIX. It would however be
162 useful to update RFC 2875 to have this fall back position.
164 7. Insert Appendix C describing why POP is necessary and what some
165 of the different POP attacks are.
167 8. pop field in the CertReqMsg structure has been renamed to popo to
168 avoid confusion between POP and pop.
170 9. The use of the EncryptedValue structure is now discouraged in
171 favor of the EnvelopedData structure.
173 10. Add details on how private keys are to be structured when
174 encrypted.
176 11. Allow for POP on key agreement algorithms other than DH.
178 3. CertReqMessage Syntax
180 A certificate request message is composed of the certificate request,
181 an optional proof of possession field and an optional registration
182 information field.
184 CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
186 CertReqMsg ::= SEQUENCE {
187 certReq CertRequest,
188 popo ProofOfPossession OPTIONAL,
189 -- content depends upon key type
190 regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL
191 }
193 The fields of CertReqMsg have the following meaning:
195 certReq contains the template of the certificate being requested.
196 The template is filled in by (or on behalf of) the Subject. Not
197 all fields within the template need to be specified. Details on
198 this field are found in section 5.
200 popo contains the value used to demonstrate that the entity that
201 will be identified as the Subject of the certificate is actually
202 in possession of the corresponding private key. This field varies
203 in structure and content based on the public key algorithm and the
204 mode (encryption vs. signature) in which the algorithm is used, as
205 specified in the KeyUsage field of the certificate to be issued.
206 Details on this field are found in section 4.
208 regInfo field SHOULD contain only supplementary information
209 relating to the context of the certificate request, where such
210 information is required to fulfill the request. This information
211 might include subscriber contact information, billing information
212 or other ancillary information useful to fulfillment of the
213 request.
215 Information directly related to certificate content SHOULD be
216 included in the certReq content. However, inclusion of additional
217 certReq content by RAs can invalidate the popo field (depending on
218 the details of the POP method used). Data therefore intended for
219 certificate content MAY be provided in regInfo.
221 It is the responsibility of a referencing CRP to define the details
222 of what can be specified in the regInfo field. This document
223 describes one method of encoding the information found in this field.
224 Details on this encoding are found in Appendix A.
226 4. Proof of Possession (POP)
228 In order to prevent certain attacks (see Appendix C) and to allow a
229 CA/RA to properly check the validity of the binding between a subject
230 and a key pair, the PKI management structures specified here make it
231 possible for a subject to prove that it has possession of (i.e., is
232 able to use) the private key corresponding to the public key for
233 which a certificate is requested. A given CRP is free to choose how
234 to enforce POP (e.g., out-of-band procedural means versus the CRMF
236 in-band message) in its certification exchanges. Within a given CRP,
237 CAs and RAs are free to choose from among the POP methods provided
238 (i.e., this is a policy issue local to an RA/CA). A CRP SHOULD
239 define either which POP methods are required, or specify a mechanism
240 for clients to discover the POP methods supported.
242 Any CRP referencing this document MUST enforce POP by some means.
243 There are currently many non-PKIX operational protocols in use
244 (various electronic mail protocols are one example) that do not
245 explicitly check the binding between the end entity and the private
246 key. Until operational protocols that do verify the binding (for
247 signature, encryption, and key agreement key pairs) exist, and are
248 ubiquitous, this binding cannot be assumed to have been verified by
249 the CA/RA. Therefore, one cannot truly know if the binding of the
250 public key and the identity in the certificate is actually correct.
252 POP is accomplished in different ways depending on the type of key
253 for which a certificate is requested. If a key can be used for
254 multiple purposes (e.g., a signing and decryption RSA key) then any
255 of the methods MAY be used. Protocol designers need to be aware that
256 there can be hardware limitations on what POP methods may be usable,
257 e.g., if the private key is maintained in a hardware token.
259 This specification allows for cases where POP is validated by the CA,
260 the RA, or both. Some policies require the CA to verify POP during
261 certificate issuance, in which case the RA MUST forward the end
262 entity's CertRequest and ProofOfPossession fields unaltered to the
263 CA. (In this case the RA could verify the POP and reject failing
264 certificate requests rather than forwarding them to the CA.) If the
265 CA is not required by policy to verify POP, then the RA SHOULD
266 forward the end entity's request and proof unaltered to the CA as
267 above. If this is not possible (for example because the RA verifies
268 POP by an out-of-band method), then the RA uses the raVerified
269 element to attest to the CA that the required proof has been
270 validated. If the CA/RA uses an out-of-band method to verify POP
271 (such as physical delivery of CA/RA-generated private keys) then the
272 ProofOfPossession field is omitted.
274 ProofOfPossession ::= CHOICE {
275 raVerified [0] NULL,
276 signature [1] POPOSigningKey,
277 keyEncipherment [2] POPOPrivKey,
278 keyAgreement [3] POPOPrivKey }
280 The fields of ProofOfPossession have the following meaning:
282 raVerified indicates that the RA has performed the POP required on
283 the certificate request. This field is used by an RA when 1) the
284 CA is not required to do its own POP verification and 2) the RA
285 needs to change the contents of the certReq field. CRPs MUST
286 provide a method for the RA to sign the ProofOfPossession. A
287 requestor MUST NOT set this field and an RA/CA MUST NOT accept a
288 ProofOfPossession where the requestor sets this field.
290 signature is used for performing POP with signature keys. The
291 details of this field are covered in section 4.1.
293 keyEncipherment is used for performing POP with key encipherment
294 encryption based keys (i.e. RSA). The details of this field are
295 covered in section 4.2.
297 keyAgreement is used for performing POP with key agreement type
298 encryption keys (i.e. DH). The details of this field are covered
299 in section 4.3.
301 4.1 Signature Key POP
303 POP for a signature key is accomplished by performing a signature
304 operation on a piece of data containing the identity for which the
305 certificate is desired.
307 There are three cases that need to be looked at when doing a POP for
308 a signature key:
310 1. The certificate subject has not yet established an authenticated
311 identity with a CA/RA but has a one-time password and identity issued
312 by the CA/RA. In this case the POPOSigningKeyInput structure would
313 be filled out using the publicKeyMAC choice for authInfo and the
314 password and identity would be used to compute the publicKeyMAC
315 value. The public key for the certificate being requested would be
316 placed in both the POPOSigningKeyInput and the Certificate Template
317 structures. The signature field is computed over the DER encoded
318 POPOSigningKeyInput structure.
320 2. The CA/RA has established an authenticated identity for the
321 certificate subject, but the requestor is not placing it into the
322 certificate request. In this case the POPOSigningKeyInput
323 structure would be filled out using the sender choice for authInfo.
324 The public key for the certificate being requested would be placed in
325 both the POPOSigningKeyInput and the Certificate Template structures.
326 The signature field is computed over the DER encoded
327 POPOSigningKeyInput structure.
329 3. The certificate subject places its name in the Certificate
330 Template structure along with the public key. In this case the
331 poposkInput field is omitted from the POPOSigningKey structure. The
333 signature field is computed over the DER certReq field of the
334 CertReqMsg structure.
336 POPOSigningKey ::= SEQUENCE {
337 poposkInput [0] POPOSigningKeyInput OPTIONAL,
338 algorithmIdentifier AlgorithmIdentifier,
339 signature BIT STRING }
341 The fields of POPOSigningKey have the following meaning:
343 poposkInput contains the data to be signed, when present. This
344 field MUST be present when the certificate template does not
345 contain both the public key value and a subject name value.
347 algorithmIdentifier identifiers the signature algorithm and an
348 associated parameters used to produce the POP value.
350 signature contains the POP value produced. If poposkInput is
351 present, the signature is computed using the DER encoded value of
352 poposkInput. If poposkInput is absent, the signature is computed
353 using the DER encoded value of certReq.
355 POPOSigningKeyInput ::= SEQUENCE {
356 authInfo CHOICE {
357 sender [0] GeneralName,
358 -- used only if an authenticated identity has been
359 -- established for the sender (e.g., a DN from a
360 -- previously-issued and currently-valid certificate)
361 publicKeyMAC PKMACValue },
362 -- used if no authenticated GeneralName currently exists for
363 -- the sender; publicKeyMAC contains a password-based MAC
364 -- on the DER-encoded value of publicKey
365 publicKey SubjectPublicKeyInfo } -- from CertTemplate
367 The fields of POPOSigningKeyInput have the following meaning:
369 sender contains an authenticated identity that has previously been
370 established for the subject.
372 publicKeyMAC contains a computed value using a shared secret
373 between the CA/RA and the certificate requestor.
375 publicKey contains a copy of the public key from the certificate
376 template. This MUST be exactly the same value as is contained in
377 the certificate template.
379 PKMACValue ::= SEQUENCE {
380 algId AlgorithmIdentifier,
382 value BIT STRING }
384 The fields of PKMACValue have the following meaning:
386 algId identifiers the algorithm used to compute the MAC value.
387 All implementations MUST support id-PasswordBasedMAC. The details
388 on this algorithm are presented in section 4.4.
390 value contains the computed MAC value. The MAC value is computed
391 over the DER encoded public key of the certificate subject.
392 2
393 The CA/RA identifies the shared secret to be used by looking at 1)
394 the subject name field in the certificate request, 2) the subject
395 alternative name field in the certificate request or 3) either the
396 regToken (see section 6.1) or authToken (see section 6.2) controls.
398 4.2 Key Encipherment Keys
400 POP for key encipherment keys is accomplished by one of three
401 different methods. The private key can be provided to the CA/RA, an
402 encrypted challenge from the CA/RA can be decrypted (direct method)
403 or the created certificate can be returned encrypted and used as the
404 challenge response (indirect method).
406 POPOPrivKey ::= CHOICE {
407 thisMessage [0] BIT STRING, -- discouraged
408 subsequentMessage [1] SubsequentMessage,
409 dhMAC [2] BIT STRING, -- deprecated
410 agreeMAC [3] PKMACValue,
411 encryptedKey [4] EnvelopedData }
412 -- for keyAgreement (only), possession is proven in this message
413 -- (which contains a MAC (over the DER-encoded value of the
414 -- certReq parameter in CertReqMsg, which must include both subject
415 -- and publicKey) based on a key derived from the end entity's
416 -- private DH key and the CA's public DH key);
417 -- the dhMAC value MUST be calculated as per the directions given
418 -- in RFC 2875 for static DH proof of possesion.
420 SubsequentMessage ::= INTEGER {
421 encrCert (0),
422 challengeResp (1) }
424 The fields of POPOPrivKey have the following meaning:
426 thisMessage contains the encrypted private key for which a
427 certificate is to be issued. The possession of the private key is
428 proved by providing it to the CA/RA. This field was incorrectly
429 typed when the specification was first written. The correct way
431 to use this field is to encrypt the private using using the
432 EncryptedValue structure and then wrap that in the BIT STRING
433 type. This field has been discouraged in favor of the
434 encryptedKey field. This is because EnvelopedData offers key
435 management options not supported by the EncryptedValue data type.
437 subsequentMessage is used to indicate that the POP will be
438 completed by decrypting a message from the CA/RA and a response
439 returned. The type of message to be decrypted is indicated by the
440 value used.
442 encrCert indicates that the certificate issued is to be
443 returned in an encrypted form. The requestor is required to
444 decrypt the certificate and prove success to the CA/RA. The
445 details of this are provided by the CRP.
447 challengeResponse indicates that a challenge message is to be
448 sent from the CA/RA to the requestor. The details of the
449 challenge message and the response are details to be provided
450 by the CRP.
452 dhMAC is used for Diffie-Hellman key agreement keys. It contains
453 a computed MAC that is obtained by using the requestor's private
454 key and the CA/RA public key. The use of this field is deprecated
455 in favor of the agreeMAC field. Details are covered in section
456 4.3.
458 agreeMAC is used for key agreement keys. It contains a computed
459 MAC that is obtained by using the requestor's private key and a
460 matching CA/RA public key. Details are covered in section 4.3.
462 macAlg contains the algorithm identifying the method used to
463 compute the MAC value.
465 macValue contains the computed MAC value.
467 encryptedKey contains the encrypted private key matching the
468 public key for which the certificate is to be issued. It also
469 contains an identification value to indicate it was constructed by
470 the requestor of the certificate. The enveloped content type MUST
471 be id-ct-encKeyWithID.
473 It is expected that protocols that incorporate this specification
474 will include the confirmation and challenge-response messages
475 necessary for a complete protocol.
477 4.2.1 Private Key Info Content Type
479 This content type is used for 1) proving possession of private keys
480 and 2) escrow of private keys (using the archive options control in
481 section 6.4). This structure is based on the private key info
483 structure from [PKCS8] but has one deliberate difference. There is a
484 potential attack on escrow agents if they decrypt the private key but
485 don't know who the encrypted key is supposed to belong to. An
486 attacker could intercept the encrypted private key, build a
487 certificate request around it and then ask for a recovery operation
488 on the private key.
490 This content type and its structure are:
492 id-ct-encKeyWithID ::= OBJECT IDENTIFER ::= {id-ct 21}
494 EncKeyWithID ::= SEQUENCE {
495 privateKey PrivateKeyInfo,
496 identifier CHOICE {
497 string UTF8String,
498 generalName GeneralName
499 } OPTIONAL
500 }
502 PrivateKeyInfo ::= SEQUENCE {
503 version INTEGER,
504 privateKeyAlgorithm AlgorithmIdentifier,
505 privateKey OCTET STRING,
506 attributes [0] IMPLICIT Attributes OPTIONAL
507 }
509 Attributes ::= SET OF Attribute
511 The fields of EncKeyWithID are defined as:
513 privateKey contains the encoded private key. Definitions for
514 three private key formats are included in this document.
515 Specifications for asymmetric algorithms need to include both the
516 public and private key definitions for consistency.
518 identifier contains a name that the CA/RA can associate with the
519 requestor. This will generally be either the DN of a certificate
520 or a text token passed known to both the requestor and the CA/RA.
521 This field MUST be present if the purpose is to prove possession
522 of the private key. The field SHOULD be present if archiving a
523 key and the archive agent is expected to decrypt the key.
525 The fields of PrivatekeyInfo are define as:
527 version MUST be the value 0
529 privateKeyAlgorithm contains the identifier for the private key
530 object
532 privateKey is an octet string whose contents is the private key
533 and whose format is defined by the value of privateKeyAlgorithm.
535 attributes is a set of attributes. These are extended information
536 that is part of the private key information.
538 4.2.2 Private Key Structures
540 We are defining the structures here to be used for three algorithms.
542 4.2.2.1 D-H Private Keys
544 When creating a PrivateKeyInfo for a D-H key, the following rules
545 apply:
547 1. The privateKeyAlgorithm MUST be set to id-dh-private-number. The
548 parameter for id-dh-private-number is DomainParameters (imported
549 from [PKIXALG]).
551 2. The ASN structure for privateKey MUST be
553 DH-PrivateKey ::= INTEGER
555 3. The attributes field MUST be omitted.
557 4.2.2.2 DSA Private Keys
559 When creating a PrivateKeyInfo for a DSA key, the following rules
560 apply:
562 1. The privateKeyAlgorithm MUST be set to id-dsa. The parameters
563 for id-dsa is Dss-Parms (imported from [PKIXALG]).
565 2. The ASN structure for privateKey MUST be
567 DSA-PrivateKey ::= INTEGER
569 3. The attributes field MUST be omitted.
571 4.2.2.3 RSA Private Keys
573 When creating a PrivateKeyInfo for an RSA key, the following rules
574 apply:
576 1. The privateKeyAlgorithm MUST be set to rsaEncryption.
578 2. The ASN structure for privateKey MUST be RSAPrivateKey (defined
579 in [PKCS1])
581 3. The attributes field MUST be omitted.
583 4.2.3 Challenge-Response Guidelines
585 The following provides guidelines to enrollment protocol authors
586 about how an indirect proof of possession is expected to work and
587 some of the areas where one needs to be careful in crafting the
588 messages to implement this POP method.
590 1. The original enrollment request includes a proof of identity of
591 some type and the public portion of the encryption key. Note
592 that the proof of identity needs cover the public portion of the
593 encryption key to prevent substitution attacks (where the
594 attacker changes your public key for his public key).
596 2. The response message from the server includes an encrypted data
597 value of some type. That value needs to be authenticated as
598 coming from the server in some fashion. The specification needs
599 to include the specifics of how this value is returned for the
600 different key types. For RSA keys the value can be specified as
601 being directly encrypted by the RSA public key, this will not
602 work for a D-H key where you need to specify an indirect
603 mechanism to encrypt the value.
605 3. The second request message includes a hash of the decrypted
606 value. This message MUST NOT be just the hash of the encrypted
607 value as one should never "sign" a completely random value. One
608 method to avoid this is to include information such as an
609 identity string in the hashing process. This returned value MUST
610 be included in a second proof of identity.
612 It is strongly suggested that transaction identifiers and nonce
613 values be required when performing indirect POP as this allows for 1)
614 tying the different messages in the process together and 2) for
615 letting each entity inject some amount of random data into the
616 process for doing identity proofs on.
618 4.3 Key Agreement Keys
620 POP for key agreement keys is accomplished by one of four different
621 methods. The first three are identical to those presented above for
622 key encryption keys. The fourth method takes advantage of the fact
623 that a shared secret is produced and that value can be used to MAC
624 information.
626 When the direct or indirect encryption methods presented above are
627 used, the CA/RA will need to create an ephemeral key for those cases
628 where the encryption algorithm parameters do not match between the
629 CA/RA and the requestor.
631 The end entity may also MAC the certificate request (using a shared
632 secret key derived from computation) as a fourth alternative for
633 demonstrating POP. This option may be used only if the CA/RA already
634 has a certificate that is known to the end entity and if the Subject
635 is able to use the CA/RA's key parameters.
637 For the DH key agreement algorithm, all implementations MUST support
638 the static DH Proof-of-Possession. Details on this algorithm can be
639 found in section 3 of [RFC 2875]. NOTE: If either the subject or
640 issuer name in the CA certificate is empty, then the alternative name
641 should be used in its place.
643 4.4 Use of Password-Based MAC
645 This MAC algorithm was designed to take a shared secret (a password)
646 and use it to compute a check value over a piece of information. The
647 assumption being that without the password the correct check value
648 cannot be computed. The algorithm computes the one way function
649 multiple times in order to slow down any dictionary attacks against
650 the password value.
652 The algorithm identifier and parameter structure used for Password-
653 Based MAC is:
655 id-PasswordBasedMAC OBJECT IDENTIFIER ::=
656 { 1 2 840 113533 7 66 13}
658 PBMParameter ::= SEQUENCE {
659 salt OCTET STRING,
660 owf AlgorithmIdentifier,
661 iterationCount INTEGER,
662 mac AlgorithmIdentifier
663 )
665 The fields of PEMParameter have the following meaning:
667 salt contains a randomly generated value used in computing the key
668 of the MAC process. The salt SHOULD be at least 8 octets (64 bits)
669 long.
671 owf identifies the algorithm and associated parameters used to
672 compute the key used in the MAC process. All implementations MUST
673 support SHA-1.
675 iterationCount identifies the number of times the hash is applied
676 during the key computation process. The iterationCount MUST be a
677 minimum of 100. Many people suggest using values as high as 1000
678 iterations as the minimum value. The trade off here is between
680 protection of the password from attacks and the time spent by the
681 server processing all of the different iterations in deriving
682 passwords. Hashing is generally considered to be a cheap
683 operation but this may not be true with all hash functions in the
684 future.
686 mac identifies the algorithm and associated parameters of the MAC
687 function to be used. All implementations MUST support HMAC-SHA1
688 [HMAC]. All implementations SHOULD support DES-MAC and Triple-DES-
689 MAC [PKCS11].
691 The following is pseudo code for the algorithm:
693 Inputs:
694 pw an octet string containing the user's password
695 data an octet string containing the value to be MAC-ed
696 iteration count Iter
698 Output:
699 MAC an octet string containing the resultant MAC value.
701 1. Generate a random salt value S
703 2. Append the salt to the pw. K = pw || salt.
705 3. Hash the value of K. K = HASH(K)
707 4. Iter = Iter - 1. If Iter is greater than zero. Goto step 3.
709 5. Compute an HMAC as documented in [HMAC].
711 MAC = HASH( K XOR opad, HASH( K XOR ipad, data) )
713 Where opad and ipad are defined in [HMAC].
715 5. CertRequest syntax
717 The CertRequest syntax consists of a request identifier, a template
718 of certificate content, and an optional sequence of control
719 information.
721 CertRequest ::= SEQUENCE {
722 certReqId INTEGER, -- ID for matching request and reply
723 certTemplate CertTemplate, --Selected fields of cert to be issued
724 controls Controls OPTIONAL } -- Attributes affecting issuance
726 CertTemplate ::= SEQUENCE {
727 version [0] Version OPTIONAL,
729 serialNumber [1] INTEGER OPTIONAL,
730 signingAlg [2] AlgorithmIdentifier OPTIONAL,
731 issuer [3] Name OPTIONAL,
732 validity [4] OptionalValidity OPTIONAL,
733 subject [5] Name OPTIONAL,
734 publicKey [6] SubjectPublicKeyInfo OPTIONAL,
735 issuerUID [7] UniqueIdentifier OPTIONAL,
736 subjectUID [8] UniqueIdentifier OPTIONAL,
737 extensions [9] Extensions OPTIONAL }
739 OptionalValidity ::= SEQUENCE {
740 notBefore [0] Time OPTIONAL,
741 notAfter [1] Time OPTIONAL } --at least one must be present
743 Time ::= CHOICE {
744 utcTime UTCTime,
745 generalTime GeneralizedTime }
747 The fields of CertRequest have the following meaning:
749 certReqId contains an integer value that is used by the
750 certificate requestor to associate a specific certificate request
751 with a certificate response.
753 certTemplate contains a template of an X.509 certificate. The
754 requestor fills in those fields for which specific values are
755 desired. Details on the fields are given below.
757 controls contains attributes that are not part of the certificate,
758 but control the context in which the certificate is to be issued.
759 Details on the controls defined in this document can be found in
760 section 6. Other documents may define other controls. CRPs are
761 responsible for specifying which controls are required.
763 The fields of CertTemplate have the following meaning:
765 version MUST be 2 if supplied. It SHOULD be omitted.
767 serialNumber MUST be omitted. This field is assigned by the CA
768 during certificate creation.
770 signingAlg MUST be omitted. This field is assigned by the CA
771 during certificate creation.
773 issuer is normally omitted. It would be filled in with the CA
774 that the requestor desires to issue the certificate in situations
775 where an RA is servicing more than one CA.
777 validity is normally omitted. It can be used to request that
778 certificates either start at some point in the future or expire at
780 some specific time. A case where this field would commonly be
781 used is when a cross certificate is issued for a CA. In this case
782 the validity of an existing certificate would be placed in this
783 field so that the new certificate would have the same validity
784 period as the existing certificate. If validity is not omitted
785 then at least one of the sub-fields MUST be specified. The sub-
786 fields are as follows:
788 notBefore contains the requested start time of the certificate.
789 The time follows the same rules as the notBefore time in
790 [PROFILE].
792 notAfter contains the requested expiration time of the
793 certificate. The time follows the same rules as the notAfter
794 time in [PROFILE].
796 subject is filled in with the suggested name for the requestor.
797 This would normally be filled in by a name that has previously
798 been issued to the requestor by the CA.
800 publicKey contains the public key for which the certificate is
801 being created. This field MUST be filled in if the requestor
802 generates its own key. The field is omitted if the key is
803 generated by the RA/CA.
805 issuerUID MUST be omitted. This field has been deprecated in
806 [PROFILE].
808 subjectUID MUST be omitted. This field has been deprecated in
809 [PROFILE].
811 extensions contains extensions that the requestor wants to have
812 placed in the certificate. These extensions would generally deal
813 with things such as setting the key usage to keyEncipherment.
815 With the exception of the publicKey field, the CA/RA is permitted to
816 alter any requested field. The returned certificate needs to be
817 checked by the requestor to see if the fields have been set in an
818 acceptable manner. CA/RA SHOULD use the template fields if possible.
820 There are cases where all fields of the template can be omitted. If
821 the key generation is being done at the CA/RA and the identity proof
822 is placed in a different location (such as the id-regCtrl-regToken
823 below), then there are no fields that needs to be specified by the
824 certificate requestor.
826 6. Controls Syntax
828 The generator of a CertRequest may include one or more control values
829 pertaining to the processing of the request.
831 Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
833 The following controls are defined by this document: regToken;
834 authenticator; pkiPublicationInfo; pkiArchiveOptions; oldCertID;
835 protocolEncrKey. Each CRP MUST define the set of controls supported
836 by that protocol. Additional controls may be defined by additional
837 RFCs or by the CRP protocol itself.
839 6.1 Registration Token Control
841 A regToken control contains one-time information (either based on a
842 secret value or other shared information) intended to be used by the
843 CA to verify the identity of the subject prior to issuing a
844 certificate. Upon receipt of a certification request containing a
845 value for regToken, the receiving CA verifies the information in
846 order to confirm the identity claimed in the certification request.
848 The value for regToken may be generated by the CA and provided out of
849 band to the subscriber, or may otherwise be available to both the CA
850 and the subscriber. The security of any out-of-band exchange should
851 be commensurate with the risk that the CA will tolerate with regard
852 to accepting an intercepted value from someone other than the
853 intended subscriber. The regToken value is not encrypted on return,
854 if the data is considered to be sensitive it needs to be shrouded by
855 the requestor.
857 The regToken control is used only for initialization of an end entity
858 into the PKI, whereas the authenticator control (see Section 7.2) can
859 be used both for the initial as well as subsequent certification
860 requests.
862 In some instances of use the value for regToken could be a text
863 string or a numeric quantity such as a random number. The value in
864 the latter case is encoded as a text string representation of the
865 binary quantity. The encoding of regToken SHALL be UTF8String.
867 id-regCtrl-regTokenUTF8 OBJECT IDENTIFIER ::= { id-regCtrl 9 }
869 Without prior agreement between the subscriber and CA agents, this
870 value would be a textual shared secret of some type. If a computed
871 value based on that shared secret is to be used instead, it is
872 suggested that the CRP define a new registration control for that
873 specific computation.
875 6.2 Authenticator Control.
877 An authenticator control contains information used in an ongoing
878 basis to establish a non-cryptographic check of identity in
880 communication with the CA. Examples include: mother's maiden name,
881 last four digits of social security number, or other knowledge-based
882 information shared with the subscriber's CA; a hash of such
883 information; or other information produced for this purpose. The
884 value for an authenticator control may be generated by the subscriber
885 or by the CA.
887 In some instances of use the value for authenticator could be a text
888 string or a numeric quantity such as a random number. The value in
889 the latter case is encoded as a text string representation of the
890 binary quantity. The encoding of authenticator SHALL be UTF8String.
892 id-regCtrl-authenticatorUTF8 OBJECT IDENTIFIER ::= { id-regCtrl 10 }
894 When deciding whether to use an authenticator or a regToken, use the
895 following guidelines. If the value is a one time usage value, then
896 regToken would be used. If the value has a long term usage then the
897 authenticator control would be used.
899 6.3 Publication Information Control
901 The pkiPublicationInfo control enables subscribers to influence the
902 CA/RA's publication of the certificate. This control is considered
903 to be advisory and can be ignored by CAs/RAs. It is defined by the
904 following OID and syntax:
906 id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
908 PKIPublicationInfo ::= SEQUENCE {
909 action INTEGER {
910 dontPublish (0),
911 pleasePublish (1) },
912 pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
914 SinglePubInfo ::= SEQUENCE {
915 pubMethod INTEGER {
916 dontCare (0),
917 x500 (1),
918 web (2),
919 ldap (3) },
920 pubLocation GeneralName OPTIONAL }
922 The fields of PKIPublicationInfo have the following meaning:
924 action indicates whether or not the requestor wishes the CA/RA to
925 publish the certificate. The values and their means are:
927 dontPublish indicates that the requester wishes the CA/RA not
928 to publish the certificate (this may indicate that the
929 requester intends to publish the certificate him/herself). If
930 dontPublish is used, the pubInfos field MUST be omitted.
932 pleasePublish indicates that the requestor wishes the CA/RA to
933 publish the certificate.
935 pubInfos holds the locations where the requestor desires the CA/RA
936 to publish the certificate. This field is omitted if the
937 dontPublish choice is selected. If the requestor wants to specify
938 some locations for the certificate to be published, and to allow
939 the CA/RA to publish in other locations would specify multiple
940 values of the SinglePubInfo structure, one of which would be
941 dontCare.
943 The fields of SinglePubInfo have the following meaning:
945 pubMethod indicates the address type for the location at which the
946 requestor desires the certificate to be placed by the CA/RA.
948 dontCare indicates that the CA/RA can publish the certificate
949 in whatever locations it choses. If dontCare is used, the
950 pubInfos field MUST be omitted.
952 x500 indicates that the requestor wishes for the CA/RA to
953 publish the certificate in a specific location. The location
954 is indicated in the x500 field of pubLocation.
956 ldap indicates that the requestor wishes for the CA/RA to
957 publish the certificate in a specific location. The location
958 is indicated in the ldap field of pubLocation.
960 web indicates that the requestor wishes for the CA/RA to
961 publish the certificate in a specific location. The location
962 is indicated in the http field of pubLocation.
964 pubLocation contains the address at which the certificate is to be
965 placed. The choice in the general name field is dictated by the
966 pubMethod selection in this structure.
968 Publication locations can be supplied in any order. All locations
969 are to be processed by the CA for purposes of publication.
971 6.4 Archive Options Control
973 The pkiArchiveOptions control enables subscribers to supply
974 information needed to establish an archive of the private key
975 corresponding to the public key of the certification request. It is
976 defined by the following OID and syntax:
978 id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
980 PKIArchiveOptions ::= CHOICE {
981 encryptedPrivKey [0] EncryptedKey,
982 -- the actual value of the private key
983 keyGenParameters [1] KeyGenParameters,
984 -- parameters which allow the private key to be re-generated
985 archiveRemGenPrivKey [2] BOOLEAN }
986 -- set to TRUE if sender wishes receiver to archive the private
987 -- key of a key pair that the receiver generates in response to
988 -- this request; set to FALSE if no archival is desired.
990 EncryptedKey ::= CHOICE {
991 encryptedValue EncryptedValue, -- deprecated
992 envelopedData [0] EnvelopedData }
993 -- The encrypted private key MUST be placed in the envelopedData
994 -- encryptedContentInfo encryptedContent OCTET STRING.
996 EncryptedValue ::= SEQUENCE {
997 intendedAlg [0] AlgorithmIdentifier OPTIONAL,
998 -- the intended algorithm for which the value will be used
999 symmAlg [1] AlgorithmIdentifier OPTIONAL,
1000 -- the symmetric algorithm used to encrypt the value
1001 encSymmKey [2] BIT STRING OPTIONAL,
1002 -- the (encrypted) symmetric key used to encrypt the value
1003 keyAlg [3] AlgorithmIdentifier OPTIONAL,
1004 -- algorithm used to encrypt the symmetric key
1005 valueHint [4] OCTET STRING OPTIONAL,
1006 -- a brief description or identifier of the encValue content
1007 -- (may be meaningful only to the sending entity, and used only
1008 -- if EncryptedValue might be re-examined by the sending entity
1009 -- in the future)
1010 encValue BIT STRING }
1011 -- The use of the EncryptedValue field has been deprecated in favor
1012 -- of the EnvelopedData structure.
1013 --
1014 -- When EncryptedValue is used to carry a private key (as opposed to
1015 -- a certificate), implementations MUST support the encValue field
1016 -- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
1017 -- section 12.11. If encValue contains some other format/encoding
1018 -- for the private key, the first octet of valueHint MAY be used
1019 -- to indicate the format/encoding (but note that the possible values
1020 -- of this octet are not specified at this time). In all cases, the
1021 -- intendedAlg field MUST be used to indicate at least the OID of
1022 -- the intended algorithm of the private key, unless this information
1023 -- is known a priori to both sender and receiver by some other means.
1025 KeyGenParameters ::= OCTET STRING
1027 The fields of PKIArchiveOptions have the following meaning:
1029 encryptedPrivKey contains an encrypted version of the private key.
1031 keyGenParameters contains the information needed by the requestor
1032 to regenerate the private key. As an example, for many RSA
1033 implementations one could send the first random number(s) tested
1034 for primality. The structure to go here is not defined by this
1035 document. CRPs that define content for this structure MUST define
1036 not only the content that is to go here but how that data is
1037 shrouded from unauthorized access.
1039 archiveRemGenPrivKey indicates that the requestor desires that the
1040 key generated by the CA/RA on the requestor's behalf be archived.
1042 The fields of EncryptedKey have the following meaning:
1044 encryptedValue is longer used. This field has been deprecated
1045 along with the EncryptedValue structure.
1047 envelopedData contains the encrypted value of the private key.
1048 CPRs that use this structure MUST define the entity or entities
1049 for whom the data is to be encrypted (the EE, escrow agents, CAs)
1050 and how that key or set of keys is to be determined. Details on
1051 constructing an EnvelopedData structure are found in [CMS]. The
1052 encrypted content MUST be an id-ct-encKeyWithID. The identifier
1053 can be omitted unless this structure is also being used to do
1054 proof-of-possession.
1056 6.5 OldCert ID Control
1058 If present, the OldCertID control specifies the certificate to be
1059 updated by the current certification request. The OID and syntax is:
1061 id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
1063 CertId ::= SEQUENCE {
1064 issuer GeneralName,
1065 serialNumber INTEGER
1066 }
1068 6.6 Protocol Encryption Key Control
1070 If present, the protocolEncrKey control specifies a key the CA is to
1071 use in encrypting a response to CertReqMessages. The OID for this
1072 control is id-regCtrl-protocolEncrKey. The parameter structure for
1074 this field is SubjectPublicKeyInfo. (This structure is defined in
1075 [PROFILE].)
1077 id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
1079 This control is used when a CA has information to send to the
1080 subscriber that needs to be encrypted. Such information includes a
1081 private key generated by the CA for use by the subscriber.
1083 7. RegInfo Controls
1085 This section documents the controls that are to be placed in the
1086 regInfo field of the CertReqMsg structure.
1088 7.1 utf8Pairs
1090 This control is used to convey text based information from the
1091 Subject to an RA to a CA issuing a certificate. The OID for this
1092 structure is id-regInfo-utf8Paris and has a type of UTF8String.
1094 id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
1096 The name is terminated by the question mark character ('?'). The
1097 value is terminated by the percent character '%'. Name value pairs
1098 can be repeated. Thus the syntax is:
1100 Name?Value%[Name?Value%]*
1102 The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%'
1103 (%25) if they are not being used for their reserved purpose. Names
1104 MUST NOT start with a numeric character.
1106 This control can appear multiple times in the regInfo structure.
1107 Resolution of conflicts of information is a matter of local policy on
1108 the RA/CA.
1110 Appendix A contains a set of common names and data formats
1111 corresponding to fields that commonly appear in certificates and
1112 directories.
1114 7.2 certReq
1116 This control is designed to deal with the problem where an RA needs
1117 to modify the certificate template proposed by a Subject, but the
1118 Subject used the certificate template as part of its POP calculation.
1119 In this case the RA can place a new certificate template in the
1120 regInfo sequence.
1122 This control has the OID id-regInfo-certReq and the structure
1123 CertRequest. There can only be one instance of this attribute in the
1124 regInfo sequence. If this control exists in the regInfo structure
1125 then the certificate template in the request is ignored. The RA MUST
1126 copy all data from the core template to this attribute.
1128 id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
1130 8. Object Identifiers
1132 The OID id-pkix has the value
1134 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
1135 dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
1137 -- arc for Internet X.509 PKI protocols and their components
1138 id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
1140 -- arc for Registration Controls in CRMF
1141 id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
1143 -- arc for Registration Info in CRMF
1144 id-regInfo OBJECT IDENTIFIER ::= { id-pkip id-regInfo(2) }
1146 9. Security Considerations
1148 Enrollment protocols, by their very nature, involve large amounts of
1149 private information. This can include private keys, identity
1150 numbers, credit card numbers and the like. The security of any CRP
1151 is based on the security mechanisms of the protocol and/or process
1152 used to communicate between CAs, RAs and EEs. All protocols must
1153 provide for masking, either via encryption or off-line processing, of
1154 all subscriber-sensitive information.
1156 Many enrollment protocols provide for the initial establishment of
1157 identity between the CA/RA and the EE by the use of a token.
1158 Generally this token is delivered using an out-of-band delivery
1159 method (such as the governmental mail system). The security of any
1160 out-of-band exchange needs to be commensurate with the risk that the
1161 CA/RA will tolerate with regard to interception of the token by a
1162 third party.
1164 Implementation must implement Proof-of-Possession (POP) values during
1165 certificate enrollment processes. A good POP algorithm needs to
1166 provide proof of two things: 1) that the key is tied to a specific
1167 user and 2) that the user has use of the key in question. Failure to
1169 implement POP allows for people to create certificates where the
1170 public key and the name values do not correctly bind. This allows
1171 for impersonation on signature keys and interception of encrypted
1172 messages.
1174 Implementations must use high entropy random number generators in
1175 producing private keys. Implementations must randomly generate
1176 content-encryption keys, message-authentication keys, initialization
1177 vectors (IVs), salt, and padding. The use of inadequate pseudo-
1178 random number generators (PRNGs) to generate cryptographic keys can
1179 result in little or no security. An attacker may find it much easier
1180 to reproduce the PRNG environment that produced the keys, searching
1181 the resulting small set of possibilities, rather than brute force
1182 searching the whole key space. The generation of quality random
1183 numbers is difficult. RFC 1750 [RANDOM] offers important guidance in
1184 this area and Appendix 3 of FIPS Pub 186 [DSS] provides one quality
1185 PRNG technique.
1187 Implementations must protect private keys. The compromise of a
1188 signer's private key permits third parties to masquerade as the
1189 signer. The compromise of a decryption private key allows for
1190 interception of messages by a third party.
1192 One feature of the certificate message request syntax is for the key
1193 generation to be performed remotely from the creation of the
1194 certificate request. This feature should never be used for
1195 generation of signing keys. If signing keys are generated for the
1196 user, then an element of repudiation comes into play. The user can
1197 claim that an item was signed by the entity that generated the key as
1198 well as any entity that might have seen the key value during transfer
1199 from the generator the to EE. Care must be taken to protect
1200 encryption keys by the remote key generator to protect againist
1201 interception of the keys by a third party. This means that the
1202 encryption algorithms used need to be secure, and content encryption
1203 key or key encryption key must be used to mask the private key during
1204 transport back to the user. CRP protocols must never assume that a
1205 signature key generated by the user can be used to decrypt the
1206 package that an encryption private key is transported in.
1208 This document describes a method by which key escrow may be done.
1209 There are several issues that need to be taken into account when
1210 doing key escrow. First, the client must be able to correctly
1211 identify the entity to which a key is to be escrowed or the CRP must
1212 provide a method by which the client can discover this information.
1213 A CRP cannot assume that the key escrow agent and the CA are the same
1214 entity and thus have the same names. Second, the algorithms used
1215 mask the private key or other key generation information during
1217 transport to the escrow agent need to be commensurate with the value
1218 of the data being protected by the key. Third, the escrow agent needs
1219 to provide sufficient safeguards that an escrowed key is returned
1220 only to entities that should be able to obtain the private key. This
1221 generally should be restricted to the entity that escrowed the data.
1222 Fourth, the escrow data base needs to be stored in a secure manner.
1223 One common method for doing this is to re-encrypt the data to keys
1224 that only the escrow agent has access to. In this case one may need
1225 to escrow the escrow agent key as well. Access to either the escrow
1226 agent or the archived key would amount to access to all private keys
1227 that have been escrowed with that agent.
1229 10. IANA Considerations
1231 This document defines Registration Controls and Registration Info
1232 objects. These objects are all defined by object identifiers (OIDs).
1233 The OIDs for the objects were assigned from an arc delegated by the
1234 IANA to the PKIX Working Group. No further action by the IANA is
1235 necessary for this document or any anticipated updates.
1237 This document defines a CMS Content Type. This object is defined by
1238 an object identifier (OID) assigned from an arc delegated to the
1239 S/MIME Working Group. No further action by IANA is necessary for
1240 this document or any anticipated updates.
1242 11. References
1244 11.1 Normative References
1246 [PKCS1] Jonsson, J., B. Kaliski, "Public-Key Cryptography Standards
1247 (PKCS) #1: RSA Cryptography Specifications 2.1", RFC 3447,
1248 February 2003.
1250 [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
1251 Hashing for Message Authentication", RFC 2104, February 1997.
1253 [PKCS11] RSA Laboratories, The Public-Key Cryptography Standards -
1254 "PKCS #11 v2.11: Cryptographic Token Interface Standard", RSA
1255 Security Inc., June 2001.
1257 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate
1258 Requirement Levels", BCP 14, RFC 2119, March 1997.
1260 [PROFILE] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
1261 X.509 Public Key Infrastructure Certificate and
1262 Certificate Revocation List (CRL) Profile", RFC 3280,
1263 April 2002.
1265 [PKIXALG] Polk, W., Housley, R. and L. Bassham, "Algorithms and
1266 Identifiers for the Internet X.509 Public Key Infrastructure
1267 Certificate and Certificate Revocation List (CRL) Profile",
1268 RFC 3279, April 2002.
1270 [CMS] Housley, R, "Cryptographic Message Syntax (CMS)",
1271 RFC 3369, August 2002
1273 [RFC 2875] Prafullchandra, H., J. Schaad, "Diffie-Hellman Proof-of-
1274 Possession Algorithms" RFC 2875, June 2000.
1276 11.2 Informative References
1278 [DSS] National Institute of Standards and Technology, FIPS Pub 186:
1279 Digital Signature Standard, May 1994.
1281 [PKCS8] RSA Laboratories, "PKCS #8: Private-Key Information Syntax
1282 Standard", PKCS #8 v1.2, November 1993.
1284 [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
1285 Recommendations for Security, RFC 1750, December 1994.
1287 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
1288 SHA-1", RFC 2202, September 1997.
1290 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill,
1291 "Uniform Resource Locators (URL)", RFC 1738, December 1994.
1293 12. Acknowledgments
1295 The working group would like to thank Michael Myers, Carlisle Adams,
1296 Dave Solo and David Kemp who authored the original version of this
1297 document.
1299 The working group also gratefully acknowledges the contributions of
1300 Barbara Fox, Warwick Ford, Russ Housley and John Pawling, whose
1301 review and comments significantly clarified and improved the utility
1302 of this specification. The members of the ca-talk mailing list also
1303 provided significant input with respect to interoperability testing.
1305 The text of Appendix C (Why do POP) was taken from an e-mail message
1306 by Al Arsenault and was originally part of the PKIX Roadmap document.
1308 13. Authors' Addresses
1310 Jim Schaad
1311 Soaring Hawk Consulting
1312 PO Box 675
1314 Gold Bar, WA 98251
1316 EMail: jimsch@exmsft.com
1318 Appendix A. Use of RegInfo for Name-Value Pairs
1320 The "value" field of the id-regInfo-utf8Pairs string (with "tag"
1321 field equal to 12 and appropriate "length" field) will contain a
1322 series of UTF8 name/value pairs.
1324 This Appendix lists some common examples of such pairs for the
1325 purpose of promoting interoperability among independent
1326 implementations of this specification. It is recognized that this
1327 list is not exhaustive and will grow with time and implementation
1328 experience.
1330 A.1. Defined Names
1332 The following table defines a recommended set of named elements. The
1333 value in the column "Name Value" is the exact text string that will
1334 appear in the regInfo.
1336 Name Value
1337 ----------
1338 version -- version of this variation of regInfo use
1339 corp_company -- company affiliation of subscriber
1340 org_unit -- organizational unit
1341 mail_firstName -- personal name component
1342 mail_middleName -- personal name component
1343 mail_lastName -- personal name component
1344 mail_email -- subscriber's email address
1345 jobTitle -- job title of subscriber
1346 employeeID -- employee identification number or string
1347 mailStop -- mail stop
1348 issuerName -- name of CA
1349 subjectName -- name of Subject
1350 validity -- validity interval
1352 For example:
1354 version?1%corp_company?Example, Inc.%org_unit?Engineering%
1355 mail_firstName?John%mail_lastName?Smith%jobTitle?Team Leader%
1356 mail_email?john@example.com%
1358 A.2 IssuerName, SubjectName and Validity Value Encoding
1360 When they appear in id-regInfo-utf8Pairs syntax as named elements,
1361 the encoding of values for issuerName, subjectName and validity SHALL
1362 use the following syntax. The characters [] indicate an optional
1363 field, ::= and | have their usual BNF meanings, and all other symbols
1364 (except spaces which are insignificant) outside non-terminal names
1365 are terminals. Alphabetics are case-sensitive.
1367 issuerName ::=
1368 subjectName ::=
1369 ::= | :
1371 ::= validity ? []-[]
1372 ::=
1373 ::=
1375 Where is UTC time in the form YYYYMMDD[HH[MM[SS]]]. HH, MM,
1376 and SS default to 00 and are omitted if at the and of value 00.
1378 Example validity encoding:
1380 validity?-19991231%
1382 is a validity interval with no value for notBefore and a value of
1383 December 31, 1999 for notAfter.
1385 Each name comprises a single character name form identifier followed
1386 by a name value of one or UTF8 characters. Within a name value, when
1387 it is necessary to disambiguate a character which has formatting
1388 significance at an outer level, the escape sequence %xx SHALL be
1389 used, where xx represents the hex value for the encoding concerned.
1390 The percent symbol is represented by %%.
1392 ::= X|O|E|D|U|I
1394 Name forms and value formats are as follows:
1396 X.500 directory name form (identifier "X"):
1398 ::=
1399 ::= | ,
1400 ::=
1401 ::= | +
1402 ::= =
1403 ::= OID. |
1405 Standard attribute type is an alphabetic attribute type
1406 identifier from the following set:
1408 C (country)
1409 L (locality)
1410 ST (state or province)
1411 O (organization)
1412 OU (organizational unit)
1413 CN (common name)
1414 STREET (street address)
1415 E (E-mail address).
1417 is a name component in the form of a UTF8 character string
1418 of 1 to 64 characters, with the restriction that in the IA5 subset of
1419 UTF8 only the characters of ASN.1 PrintableString may be used.
1421 Other name form (identifier "O"):
1422 ::= ,
1424 E-mail address (rfc822name) name form (identifier "E"):
1425 ::=
1427 DNS name form (identifier "D"):
1428 ::=
1430 URI name form (identifier "U"):
1431 ::=
1433 IP address (identifier "I"):
1434 ::=
1436 For example:
1438 issuerName?XOU=Our CA,O=Example,C=US%
1439 subjectName?XCN=John Smith, O=Example, C=US, E=john@example.com%
1441 Appendix B. ASN.1 Structures and OIDs
1443 PKIXCRMF-2005 {iso(1) identified-organization(3) dod(6) internet(1)
1444 security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36)}
1446 DEFINITIONS IMPLICIT TAGS ::=
1447 BEGIN
1449 IMPORTS
1450 -- Directory Authentication Framework (X.509)
1451 Version, AlgorithmIdentifier, Name, Time,
1452 SubjectPublicKeyInfo, Extensions, UniqueIdentifier, Attribute
1454 FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
1455 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1456 id-pkix1-explicit(18)} -- found in [PROFILE]
1458 -- Certificate Extensions (X.509)
1459 GeneralName
1460 FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
1461 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1462 id-pkix1-implicit(19)} -- found in [PROFILE]
1464 -- Cryptographic Message Syntax
1465 EnvelopedData
1466 FROM CryptographicMessageSyntax2004 { iso(1) member-body(2)
1467 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
1468 modules(0) cms-2001(14) }; -- found in [CMS]
1470 -- The following definition may be uncommented for use with
1471 -- ASN.1 compilers which do not understand UTF8String.
1473 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
1474 -- The contents of this type correspond to RFC 2279.
1476 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
1477 dod(6) internet(1) security(5) mechanisms(5) 7 }
1479 -- arc for Internet X.509 PKI protocols and their components
1481 id-pkip OBJECT IDENTIFIER ::= { id-pkix 5 }
1483 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
1484 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
1486 id-ct OBJECT IDENTIFIER ::= { id-smime 1 } -- content types
1488 -- Core definitions for this module
1490 CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
1492 CertReqMsg ::= SEQUENCE {
1493 certReq CertRequest,
1494 popo ProofOfPossession OPTIONAL,
1495 -- content depends upon key type
1496 regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
1498 CertRequest ::= SEQUENCE {
1499 certReqId INTEGER, -- ID for matching request and reply
1500 certTemplate CertTemplate, -- Selected fields of cert to be issued
1501 controls Controls OPTIONAL } -- Attributes affecting issuance
1503 CertTemplate ::= SEQUENCE {
1504 version [0] Version OPTIONAL,
1505 serialNumber [1] INTEGER OPTIONAL,
1506 signingAlg [2] AlgorithmIdentifier OPTIONAL,
1508 issuer [3] Name OPTIONAL,
1509 validity [4] OptionalValidity OPTIONAL,
1510 subject [5] Name OPTIONAL,
1511 publicKey [6] SubjectPublicKeyInfo OPTIONAL,
1512 issuerUID [7] UniqueIdentifier OPTIONAL,
1513 subjectUID [8] UniqueIdentifier OPTIONAL,
1514 extensions [9] Extensions OPTIONAL }
1516 OptionalValidity ::= SEQUENCE {
1517 notBefore [0] Time OPTIONAL,
1518 notAfter [1] Time OPTIONAL } --at least one MUST be present
1520 Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue
1522 AttributeTypeAndValue ::= SEQUENCE {
1523 type OBJECT IDENTIFIER,
1524 value ANY DEFINED BY type }
1526 ProofOfPossession ::= CHOICE {
1527 raVerified [0] NULL,
1528 -- used if the RA has already verified that the requester is in
1529 -- possession of the private key
1530 signature [1] POPOSigningKey,
1531 keyEncipherment [2] POPOPrivKey,
1532 keyAgreement [3] POPOPrivKey }
1534 POPOSigningKey ::= SEQUENCE {
1535 poposkInput [0] POPOSigningKeyInput OPTIONAL,
1536 algorithmIdentifier AlgorithmIdentifier,
1537 signature BIT STRING }
1538 -- The signature (using "algorithmIdentifier") is on the
1539 -- DER-encoded value of poposkInput. NOTE: If the CertReqMsg
1540 -- certReq CertTemplate contains the subject and publicKey values,
1541 -- then poposkInput MUST be omitted and the signature MUST be
1542 -- computed on the DER-encoded value of CertReqMsg certReq. If
1543 -- the CertReqMsg certReq CertTemplate does not contain both the
1544 -- public key and subject values (i.e., if it contains only one
1545 -- of these, or neither), then poposkInput MUST be present and
1546 -- MUST be signed.
1548 POPOSigningKeyInput ::= SEQUENCE {
1549 authInfo CHOICE {
1550 sender [0] GeneralName,
1551 -- used only if an authenticated identity has been
1552 -- established for the sender (e.g., a DN from a
1553 -- previously-issued and currently-valid certificate
1554 publicKeyMAC PKMACValue },
1555 -- used if no authenticated GeneralName currently exists for
1556 -- the sender; publicKeyMAC contains a password-based MAC
1557 -- on the DER-encoded value of publicKey
1558 publicKey SubjectPublicKeyInfo } -- from CertTemplate
1560 PKMACValue ::= SEQUENCE {
1562 algId AlgorithmIdentifier,
1563 -- algorithm value shall be PasswordBasedMac {1 2 840 113533 7 66 13}
1564 -- parameter value is PBMParameter
1565 value BIT STRING }
1567 PBMParameter ::= SEQUENCE {
1568 salt OCTET STRING,
1569 owf AlgorithmIdentifier,
1570 -- AlgId for a One-Way Function (SHA-1 recommended)
1571 iterationCount INTEGER,
1572 -- number of times the OWF is applied
1573 mac AlgorithmIdentifier
1574 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
1575 } -- or HMAC [HMAC, RFC2202])
1577 POPOPrivKey ::= CHOICE {
1578 thisMessage [0] BIT STRING, -- Deprecated
1579 -- posession is proven in this message (which contains the private
1580 -- key itself (encrypted for the CA))
1581 subsequentMessage [1] SubsequentMessage,
1582 -- possession will be proven in a subsequent message
1583 dhMAC [2] BIT STRING, -- Deprecated
1584 agreeMAC [3] PKMACValue,
1585 encryptedKey [4] EnvelopedData }
1586 -- for keyAgreement (only), possession is proven in this message
1587 -- (which contains a MAC (over the DER-encoded value of the
1588 -- certReq parameter in CertReqMsg, which MUST include both subject
1589 -- and publicKey) based on a key derived from the end entity's
1590 -- private DH key and the CA's public DH key);
1592 SubsequentMessage ::= INTEGER {
1593 encrCert (0),
1594 -- requests that resulting certificate be encrypted for the
1595 -- end entity (following which, POP will be proven in a
1596 -- confirmation message)
1597 challengeResp (1) }
1598 -- requests that CA engage in challenge-response exchange with
1599 -- end entity in order to prove private key possession
1601 -- Object identifier assignments --
1603 -- Registration Controls in CRMF
1604 id-regCtrl OBJECT IDENTIFIER ::= { id-pkip 1 }
1606 id-regCtrl-regTokenUTF8 OBJECT IDENTIFIER ::= { id-regCtrl 9 }
1607 --with syntax:
1608 RegToken ::= UTF8String
1610 id-regCtrl-authenticatorUTF8 OBJECT IDENTIFIER ::= { id-regCtrl 10 }
1611 --with syntax:
1612 Authenticator ::= UTF8String
1614 id-regCtrl-pkiPublicationInfo OBJECT IDENTIFIER ::= { id-regCtrl 3 }
1616 --with syntax:
1618 PKIPublicationInfo ::= SEQUENCE {
1619 action INTEGER {
1620 dontPublish (0),
1621 pleasePublish (1) },
1622 pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
1623 -- pubInfos MUST NOT be present if action is "dontPublish"
1624 -- (if action is "pleasePublish" and pubInfos is omitted,
1625 -- "dontCare" is assumed)
1627 SinglePubInfo ::= SEQUENCE {
1628 pubMethod INTEGER {
1629 dontCare (0),
1630 x500 (1),
1631 web (2),
1632 ldap (3) },
1633 pubLocation GeneralName OPTIONAL }
1635 id-regCtrl-pkiArchiveOptions OBJECT IDENTIFIER ::= { id-regCtrl 4 }
1636 --with syntax:
1637 PKIArchiveOptions ::= CHOICE {
1638 encryptedPrivKey [0] EncryptedKey,
1639 -- the actual value of the private key
1640 keyGenParameters [1] KeyGenParameters,
1641 -- parameters which allow the private key to be re-generated
1642 archiveRemGenPrivKey [2] BOOLEAN }
1643 -- set to TRUE if sender wishes receiver to archive the private
1644 -- key of a key pair which the receiver generates in response to
1645 -- this request; set to FALSE if no archival is desired.
1647 EncryptedKey ::= CHOICE {
1648 encryptedValue EncryptedValue, -- Deprecated
1649 envelopedData [0] EnvelopedData }
1650 -- The encrypted private key MUST be placed in the envelopedData
1651 -- encryptedContentInfo encryptedContent OCTET STRING.
1653 EncryptedValue ::= SEQUENCE {
1654 intendedAlg [0] AlgorithmIdentifier OPTIONAL,
1655 -- the intended algorithm for which the value will be used
1656 symmAlg [1] AlgorithmIdentifier OPTIONAL,
1657 -- the symmetric algorithm used to encrypt the value
1658 encSymmKey [2] BIT STRING OPTIONAL,
1659 -- the (encrypted) symmetric key used to encrypt the value
1660 keyAlg [3] AlgorithmIdentifier OPTIONAL,
1661 -- algorithm used to encrypt the symmetric key
1662 valueHint [4] OCTET STRING OPTIONAL,
1663 -- a brief description or identifier of the encValue content
1664 -- (may be meaningful only to the sending entity, and used only
1665 -- if EncryptedValue might be re-examined by the sending entity
1666 -- in the future)
1667 encValue BIT STRING }
1668 -- the encrypted value itself
1669 -- When EncryptedValue is used to carry a private key (as opposed to
1671 -- a certificate), implementations MUST support the encValue field
1672 -- containing an encrypted PrivateKeyInfo as defined in [PKCS11],
1673 -- section 12.11. If encValue contains some other format/encoding
1674 -- for the private key, the first octet of valueHint MAY be used
1675 -- to indicate the format/encoding (but note that the possible values
1676 -- of this octet are not specified at this time). In all cases, the
1677 -- intendedAlg field MUST be used to indicate at least the OID of
1678 -- the intended algorithm of the private key, unless this information
1679 -- is known a priori to both sender and receiver by some other means.
1681 KeyGenParameters ::= OCTET STRING
1683 id-regCtrl-oldCertID OBJECT IDENTIFIER ::= { id-regCtrl 5 }
1684 --with syntax:
1685 OldCertId ::= CertId
1687 CertId ::= SEQUENCE {
1688 issuer GeneralName,
1689 serialNumber INTEGER }
1691 id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
1692 --with syntax:
1693 ProtocolEncrKey ::= SubjectPublicKeyInfo
1695 -- Registration Info in CRMF
1696 id-regInfo OBJECT IDENTIFIER ::= { id-pkip 2 }
1698 id-regInfo-utf8Pairs OBJECT IDENTIFIER ::= { id-regInfo 1 }
1699 --with syntax
1700 UTF8Pairs ::= UTF8String
1702 id-regInfo-certReq OBJECT IDENTIFIER ::= { id-regInfo 2 }
1703 --with syntax
1704 CertReq ::= CertRequest
1706 -- id-ct-encKeyWithID is a new content type used for CMS objects.
1707 -- it contains both a private key and an identifier for key escrow
1708 -- agents to check against recovery requestors.
1710 id-ct-encKeyWithID OBJECT IDENTIFIER ::= {id-ct 21}
1712 EncKeyWithID ::= SEQUENCE {
1713 privateKey PrivateKeyInfo,
1714 identifier CHOICE {
1715 string UTF8String,
1716 generalName GeneralName
1717 } OPTIONAL
1718 }
1720 PrivateKeyInfo ::= SEQUENCE {
1721 version INTEGER,
1722 privateKeyAlgorithm AlgorithmIdentifier,
1724 privateKey OCTET STRING,
1725 attributes [0] IMPLICIT Attributes OPTIONAL
1726 }
1728 Attributes ::= SET OF Attribute
1730 END
1732 Appendix C. Why do Proof of Possession (POP).
1734 Proof of Possession, or POP, means that the CA is adequately
1735 convinced that the entity requesting a certificate containing a
1736 public key Y has access to the private key X corresponding to that
1737 public key.
1739 POP is important because it provides an appropriate level of
1740 assurance in the correct operation of the PKI as a whole. At its
1741 lowest level, POP counters the "self-inflicted denial of service";
1742 that is, an entity voluntarily getting a certificate that cannot be
1743 used to sign or encrypt/decrypt information. However, as the
1744 following two examples demonstrate, POP also counters less direct,
1745 but more severe, threats:
1747 POP for signing keys: it is important to provide POP for keys used
1748 to sign material, in order to provide non-repudiation of
1749 transactions. For example, suppose Alice legitimately has private
1750 key X and its corresponding public key Y. Alice has a certificate
1751 from Charlie, a CA, containing Y. Alice uses X to sign a
1752 transaction T. Without POP, Mal could also get a certificate from
1753 Charlie containing the same public key, Y. Now, there are two
1754 possible threats: Mal could claim to have been the real signer of
1755 T; or Alice can falsely deny signing T, claiming that it was
1756 instead Mal. Since no one can reliably prove that Mal did or did
1757 not ever possess X, neither of these claims can be refuted, and
1758 thus the service provided by and the confidence in the PKI has
1759 been defeated. (Of course, if Mal really did possess X, Alice's
1760 private key, then no POP mechanism in the world will help, but
1761 that is a different problem.)
1763 Note that one level of protection can be gained by having Alice,
1764 as the true signer of the transaction; include in the signed
1765 information her certificate or an identifier of her certificate
1766 (e.g., a hash of her certificate). This might make it more
1767 difficult for Mal to claim authorship; he would have to assert
1768 that he incorrectly included Alice's certificate, rather than his
1769 own. However, it would not stop Alice from falsely repudiating
1770 her actions. Since the certificate itself is a public item, Mal
1771 indeed could have inserted Alice's certificate or identifier into
1772 the signed transaction, and thus its presence does not indicate
1773 that Alice was the one who participated in the now-repudiated
1774 transaction. The only reliable way to stop this attack is to
1776 require that Mal prove he possesses X before his certificate is
1777 issued.
1779 For signing keys used only for authentication, and not for non-
1780 repudiation, the threat is lower because users may not care about
1781 Alice's after-the-fact repudiation, and thus POP becomes less
1782 important. However, POP SHOULD still be done wherever feasible in
1783 this environment, by either off-line or on-line means.
1785 POP for key management keys: Similarly, POP for key management
1786 keys (that is, keys used for either key agreement or key exchange)
1787 can help to prevent undermining confidence in the PKI. Suppose
1788 that Al is a new instructor in the Computer Science Department of
1789 a local University. Al has created a draft final exam for the
1790 Introduction to Networking course he is teaching. He wants to
1791 send a copy of the draft final to Dorothy, the Department Head,
1792 for her review prior to giving the exam. This exam will of course
1793 be encrypted, as several students have access to the computer
1794 system. However, a quick search of the certificate repository
1795 (e.g., search the repository for all records with
1796 subjectPublicKey=Dorothy's-value) turns up the fact that several
1797 students have certificates containing the same public key
1798 management key as Dorothy. At this point, if no POP has been done
1799 by the CA, Al has no way of knowing whether all of the students
1800 have simply created these certificates without knowing the
1801 corresponding private key (and thus it is safe to send the
1802 encrypted exam to Dorothy), or whether the students have somehow
1803 acquired Dorothy's private key (and thus it is certainly not safe
1804 to send the exam). Thus, the service to be provided by the
1805 PKI allowing users to communicate with one another, with
1806 confidence in who they are communicating with - has been totally
1807 defeated. If the CA is providing POP, then either no students will
1808 have such certificates, or Al can know with certainty that the
1809 students do indeed know Dorothy's private key, and act
1810 accordingly.
1812 Appendix D - Change History
1814 D.1 Changes from -06 to -07
1816 1. The editor of the document changed. When this occurred a huge
1817 number of textual re-writes were applied based on how the new
1818 editor felt that a document should be laid out based on his prior
1819 experience. This means that massive parts of the document cannot
1820 be diff-ed against the previous document to see what happened.
1821 2. Comments from the IESG review were responded to by the editor.
1822 3. Section 2.1 - Changes since RFC 2511 was added as required for
1823 all updated RFC documents
1824 4. Added Appendix C - Why POP?
1825 5. Defined and added a Certificate Request Protocol to refer to this
1826 document and to impose restrictions and requirements on such a
1827 protocol.
1829 6. Rename the CertReqMsg field pop to popo so that pop and POP would
1830 no longer potentially be confused.
1831 7. Added support for DES-MAC and Triple-DES-MAC to Password Based
1832 MACs.
1833 8. Greatly expanded the Security Considerations Section
1835 D.2 Changes from -07 to -08
1837 1. Add the agreeMAC field in section 4.3 to allow for key agreement
1838 algorithms other than Diffie-Hellman. Deprecate usage of dhMAC.
1840 2. Added encryptedKey to POPOPrivKey along with details of the body
1841 definition and content type to be used. Deprecate usage of the
1842 thisMessage field.
1843 3. Add the section on Challenge-Response Guidelines.
1844 4. Change Section 6.1 and 6.2 to simplify and clarify.
1845 5. Added guidance on parameters for salt and iterationCount in
1846 section 4.4.
1847 6. Added clarification for the usage of % for quoting values in
1848 section 7.1.
1850 D.3 Changes from -08 to -09
1852 1. Change EncryptedValue from deprecated to discouraged with text
1853 on why it is discouraged.
1854 2. Clarify what is used for computing a signature in section 4.1
1855 bullet item 3.
1856 3. Correct pseudo-code for MAC computation in section 4.4.
1857 4. Change OIDs and names for reg controls in sections 6.1 and 6.2.
1858 5. Add IANA considerations.
1860 Appendix E - Full Copyright Statement
1862 Copyright (C) The Internet Society (year). This document is
1863 Subject to the rights, licenses and restrictions contained in BCP 78,
1864 and except as set forth therein, the authors retain all their
1865 rights."
1867 This document and the information contained herein are provided on
1868 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
1869 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
1870 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
1871 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1872 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1873 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.