< draft-ietf-pkix-rfc2510bis-05.txt   draft-ietf-pkix-rfc2510bis-06.txt >
Internet Draft C. Adams Internet Draft C. Adams
PKIX Working Group Entrust, Inc. PKIX Working Group Entrust, Inc.
November, 2001 S. Farrell December, 2001 S. Farrell
Expires in 6 Months Baltimore Technologies Expires in 6 Months Baltimore Technologies
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
Certificate Management Protocols Certificate Management Protocols
<draft-ietf-pkix-rfc2510bis-05.txt> <draft-ietf-pkix-rfc2510bis-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire in May, 2002. Comments or This Internet-Draft will expire in June, 2002. Comments or
suggestions for improvement may be made on the "ietf-pkix" mailing suggestions for improvement may be made on the "ietf-pkix" mailing
list, or directly to the authors. list, or directly to the authors.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document describes the Internet X.509 Public Key Infrastructure This document describes the Internet X.509 Public Key Infrastructure
skipping to change at page 2, line 44 skipping to change at page 2, line 44
3.3.12 Cross-Certification Response ............................. 42 3.3.12 Cross-Certification Response ............................. 42
3.3.13 CA Key Update Announcement ............................... 42 3.3.13 CA Key Update Announcement ............................... 42
3.3.14 Certificate Announcement ................................. 42 3.3.14 Certificate Announcement ................................. 42
3.3.15 Revocation Announcement .................................. 42 3.3.15 Revocation Announcement .................................. 42
3.3.16 CRL Announcement ......................................... 43 3.3.16 CRL Announcement ......................................... 43
3.3.17 PKI Confirmation ......................................... 43 3.3.17 PKI Confirmation ......................................... 43
3.3.18 Certificate Confirmation ................................. 43 3.3.18 Certificate Confirmation ................................. 43
3.3.19 PKI General Message ...................................... 44 3.3.19 PKI General Message ...................................... 44
3.3.20 PKI General Response ..................................... 47 3.3.20 PKI General Response ..................................... 47
3.3.21 Error Message ............................................ 47 3.3.21 Error Message ............................................ 47
3.3.22 Polling Request and Response ............................. 47
4. Mandatory PKI Management Functions ................................. 47 4. Mandatory PKI Management Functions ................................. 49
4.1 Root CA Initialization ......................................... 47 4.1 Root CA Initialization ......................................... 49
4.2 Root CA Key Update ............................................. 48 4.2 Root CA Key Update ............................................. 50
4.3 Subordinate CA Initialization .................................. 48 4.3 Subordinate CA Initialization .................................. 50
4.4 CRL Production ................................................. 48 4.4 CRL Production ................................................. 50
4.5 PKI Information Request ........................................ 48 4.5 PKI Information Request ........................................ 50
4.6 Cross-Certification ............................................ 49 4.6 Cross-Certification ............................................ 51
4.7 End Entity Initialization ...................................... 51 4.7 End Entity Initialization ...................................... 53
4.8 Certificate Request ............................................ 52 4.8 Certificate Request ............................................ 54
4.9 Key Update ..................................................... 52 4.9 Key Update ..................................................... 54
5. Version Negotiation ................................................ 53 5. Version Negotiation ................................................ 55
5.1 Supporting RFC 2510 Implementations ............................ 53 5.1 Supporting RFC 2510 Implementations ............................ 55
Security Considerations ............................................... 54 Security Considerations ............................................... 56
References ............................................................ 55 References ............................................................ 57
Acknowledgements ...................................................... 56 Acknowledgements ...................................................... 58
Authors' Addresses .................................................... 56 Authors' Addresses .................................................... 58
Appendix A: Reasons for the presence of RAs ........................... 57 Appendix A: Reasons for the presence of RAs ........................... 59
Appendix B: PKI Management Message Profiles (REQUIRED) ................ 58 Appendix B: PKI Management Message Profiles (REQUIRED) ................ 60
Appendix C: PKI Management Message Profiles (OPTIONAL) ................ 68 Appendix C: PKI Management Message Profiles (OPTIONAL) ................ 70
Appendix D: Request Message Behavioral Clarifications ................. 75 Appendix D: Request Message Behavioral Clarifications ................. 77
Appendix E: The Use of "Revocation Passphrase" ........................ 76 Appendix E: The Use of "Revocation Passphrase" ........................ 78
Appendix F: "Compilable" ASN.1 Module Using 1988 Syntax ............... 78 Appendix F: "Compilable" ASN.1 Module Using 1988 Syntax ............... 80
Appendix G: Registration of MIME Type for E-Mail or HTTP Use .......... 89 Appendix G: Registration of MIME Type for E-Mail or HTTP Use .......... 91
Full Copyright Statement .............................................. 90 Full Copyright Statement .............................................. 92
1 PKI Management Overview 1 PKI Management Overview
The PKI must be structured to be consistent with the types of The PKI must be structured to be consistent with the types of
individuals who must administer it. Providing such administrators individuals who must administer it. Providing such administrators
with unbounded choices not only complicates the software required but with unbounded choices not only complicates the software required but
also increases the chances that a subtle mistake by an administrator also increases the chances that a subtle mistake by an administrator
or software developer will result in broader compromise. Similarly, or software developer will result in broader compromise. Similarly,
restricting administrators with cumbersome mechanisms will cause them restricting administrators with cumbersome mechanisms will cause them
not to use the PKI. not to use the PKI.
skipping to change at page 20, line 25 skipping to change at page 20, line 25
during this "gap" (the CA operator SHOULD avoid this as it leads to during this "gap" (the CA operator SHOULD avoid this as it leads to
the failure cases described below). the failure cases described below).
2.4.2.2 Verification in case 2. 2.4.2.2 Verification in case 2.
In case 2 the verifier must get access to the old public key of the In case 2 the verifier must get access to the old public key of the
CA. The verifier does the following: CA. The verifier does the following:
1. Look up the caCertificate attribute in the repository and pick 1. Look up the caCertificate attribute in the repository and pick
the OldWithNew certificate (determined based on validity the OldWithNew certificate (determined based on validity
periods); periods; note that the subject and issuer fields must match);
2. Verify that this is correct using the new CA key (which the 2. Verify that this is correct using the new CA key (which the
verifier has locally); verifier has locally);
3. If correct, check the signer's certificate using the old CA 3. If correct, check the signer's certificate using the old CA
key. key.
Case 2 will arise when the CA operator has issued the signer's Case 2 will arise when the CA operator has issued the signer's
certificate, then changed key and then issued the verifier's certificate, then changed key and then issued the verifier's
certificate, so it is quite a typical case. certificate, so it is quite a typical case.
2.4.2.3 Verification in case 3. 2.4.2.3 Verification in case 3.
In case 3 the verifier must get access to the new public key of the In case 3 the verifier must get access to the new public key of the
CA. The verifier does the following: CA. The verifier does the following:
1. Look up the CACertificate attribute in the repository and pick 1. Look up the CACertificate attribute in the repository and pick
the NewWithOld certificate (determined based on validity the NewWithOld certificate (determined based on validity
periods); periods; note that the subject and issuer fields must match);
2. Verify that this is correct using the old CA key (which the 2. Verify that this is correct using the old CA key (which the
verifier has stored locally); verifier has stored locally);
3. If correct, check the signer's certificate using the new CA 3. If correct, check the signer's certificate using the new CA
key. key.
Case 3 will arise when the CA operator has issued the verifier's Case 3 will arise when the CA operator has issued the verifier's
certificate, then changed key and then issued the signer's certificate, then changed key and then issued the signer's
certificate, so it is also quite a typical case. certificate, so it is also quite a typical case.
2.4.2.4 Failure of verification in case 6. 2.4.2.4 Failure of verification in case 6.
skipping to change at page 25, line 28 skipping to change at page 25, line 28
This is used by the CA to inform the EE how long it intends to wait for This is used by the CA to inform the EE how long it intends to wait for
the certificate confirmation before revoking the certificate and the certificate confirmation before revoking the certificate and
deleting the transaction. deleting the transaction.
confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14}
ConfirmWaitTimeValue ::= GeneralizedTime -- time CA will wait until ConfirmWaitTimeValue ::= GeneralizedTime -- time CA will wait until
3.1.2 PKI Message Body 3.1.2 PKI Message Body
PKIBody ::= CHOICE { -- message-specific body elements PKIBody ::= CHOICE { -- message-specific body elements & Section ref
ir [0] CertReqMessages, --Initialization Request ir [0] CertReqMessages, --Initialization Req (3.3.1)
ip [1] CertRepMessage, --Initialization Response ip [1] CertRepMessage, --Initialization Resp (3.3.2)
cr [2] CertReqMessages, --Certification Request cr [2] CertReqMessages, --Certification Req (3.3.3)
cp [3] CertRepMessage, --Certification Response cp [3] CertRepMessage, --Certification Resp (3.3.4)
p10cr [4] CertificationRequest, --PKCS #10 Cert. Req. p10cr [4] CertificationRequest, --PKCS #10 Cert. Req. [PKCS10]
-- the PKCS #10 certification request (see [PKCS10]) -- the PKCS #10 certification request (see [PKCS10])
popdecc [5] POPODecKeyChallContent, --pop Challenge popdecc [5] POPODecKeyChallContent --pop Challenge (3.2.8)
popdecr [6] POPODecKeyRespContent, --pop Response popdecr [6] POPODecKeyRespContent, --pop Response (3.2.8)
kur [7] CertReqMessages, --Key Update Request kur [7] CertReqMessages, --Key Update Request (3.3.5)
kup [8] CertRepMessage, --Key Update Response kup [8] CertRepMessage, --Key Update Response (3.3.6)
krr [9] CertReqMessages, --Key Recovery Request krr [9] CertReqMessages, --Key Recovery Req (3.3.7)
krp [10] KeyRecRepContent, --Key Recovery Response krp [10] KeyRecRepContent, --Key Recovery Resp (3.3.8)
rr [11] RevReqContent, --Revocation Request rr [11] RevReqContent, --Revocation Request (3.3.9)
rp [12] RevRepContent, --Revocation Response rp [12] RevRepContent, --Revocation Response (3.3.10)
ccr [13] CertReqMessages, --Cross-Cert. Request ccr [13] CertReqMessages, --Cross-Cert. Request (3.3.11)
ccp [14] CertRepMessage, --Cross-Cert. Response ccp [14] CertRepMessage, --Cross-Cert. Resp (3.3.12)
ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. (3.3.13)
cann [16] CertAnnContent, --Certificate Ann. cann [16] CertAnnContent, --Certificate Ann. (3.3.14)
rann [17] RevAnnContent, --Revocation Ann. rann [17] RevAnnContent, --Revocation Ann. (3.3.15)
crlann [18] CRLAnnContent, --CRL Announcement crlann [18] CRLAnnContent, --CRL Announcement (3.3.16)
pkiconf [19] PKIConfirmContent, --Confirmation pkiconf [19] PKIConfirmContent, --Confirmation (3.3.17)
nested [20] NestedMessageContent, --Nested Message nested [20] NestedMessageContent, --Nested Message (3.1.3)
genm [21] GenMsgContent, --General Message genm [21] GenMsgContent, --General Message (3.3.19)
genp [22] GenRepContent, --General Response genp [22] GenRepContent, --General Response (3.3.20)
error [23] ErrorMsgContent, --Error Message error [23] ErrorMsgContent, --Error Message (3.3.21)
certConf [24] CertConfirmContent, --Certificate confirm certConf [24] CertConfirmContent, --Certificate confirm (3.3.18)
pollReq [25] PollReqContent, --Polling request pollReq [25] PollReqContent, --Polling request (3.3.22)
pollRep [26] PollRepContent --Polling response pollRep [26] PollRepContent --Polling response (3.3.22)
} }
The specific types are described in Section 3.3 below. The specific types are described in Section 3.3 below.
3.1.3 PKI Message Protection 3.1.3 PKI Message Protection
Some PKI messages will be protected for integrity. (Note that if an Some PKI messages will be protected for integrity. (Note that if an
asymmetric algorithm is used to protect a message and the relevant asymmetric algorithm is used to protect a message and the relevant
public component has been certified already, then the origin of the public component has been certified already, then the origin of the
message can also be authenticated. On the other hand, if the public message can also be authenticated. On the other hand, if the public
component is uncertified then the message origin cannot be component is uncertified then the message origin cannot be
skipping to change at page 47, line 38 skipping to change at page 47, line 38
is not valid. Both sides MUST treat this message as the end of the is not valid. Both sides MUST treat this message as the end of the
transaction (if a transaction is in progress). transaction (if a transaction is in progress).
If protection is desired on the message, the client MUST protect it If protection is desired on the message, the client MUST protect it
using the same technique (i.e., signature or MAC) as the starting using the same technique (i.e., signature or MAC) as the starting
message of the transaction. The CA MUST always sign it with a message of the transaction. The CA MUST always sign it with a
signature key. signature key.
3.3.22 Polling Request and Response 3.3.22 Polling Request and Response
This pair of messages is intended to handle scenarios in which the
client needs to poll the server in order to determine the status of an
outstanding ir, cr, or kur transaction (i.e., when the "waiting"
PKIStatus has been received).
PollReqContent ::= SEQUENCE OF SEQUENCE { PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER certReqId INTEGER }
}
PollRepContent ::= SEQUENCE OF SEQUENCE { PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER, certReqId INTEGER,
checkAfter INTEGER, -- time in seconds checkAfter INTEGER, -- time in seconds
reason [0] PKIFreeText OPTIONAL reason PKIFreeText OPTIONAL }
}
1. It is assumed that multiple certConf messages can be sent during The following clauses describe when polling messages are used, and how
the transaction. There will be one sent in response to each ip, cp, or they are used. It is assumed that multiple certConf messages can be
kup containing a CertStatus for each approved certificate. If a single sent during transactions. There will be one sent in response to each
certConf must be sent for the transaction, then it is possible that the ip, cp, or kup containing a CertStatus for an approved certificate.
confirmWaitTime (see Section 3.1.1.2) of the first certificate will
have expired before the second cert pickup has taken place.
2. In response to an ip, cp, or kup message, an EE will send a certConf 1. In response to an ip, cp, or kup message, an EE will send a certConf
for all approved certificates and, following the ack, a pollReq for all for all approved certificates and, following the ack, a pollReq for all
pending certificates. pending certificates.
3. In respose to a pollReq, a CA/RA will return an ip, cp, or kup if 2. In respose to a pollReq, a CA/RA will return an ip, cp, or kup if
one or more of the pending certificates is ready; otherwise, it will one or more of the pending certificates is ready; otherwise, it will
return a pollRep. return a pollRep.
4. If the EE receives a pollRep, it will wait for at least as long as 3. If the EE receives a pollRep, it will wait for at least as long as
the checkAfter value before sending another pollReq. the checkAfter value before sending another pollReq.
5. If an ip, cp, or kup is received in response to a pollReq, then it 4. If an ip, cp, or kup is received in response to a pollReq, then it
will be treated in the same way as the initial response. will be treated in the same way as the initial response.
START START
| |
| |
\/ \/
Send ir Send ir
| |
| ip | ip
| |
skipping to change at page 54, line 31 skipping to change at page 54, line 31
See Section 4.1 for further details. See Section 4.1 for further details.
4.8 Certificate Request 4.8 Certificate Request
An initialized end entity MAY request an additional certificate at any An initialized end entity MAY request an additional certificate at any
time (for any purpose). This request will be made using the time (for any purpose). This request will be made using the
certification request (cr) message. If the end entity already certification request (cr) message. If the end entity already
possesses a signing key pair (with a corresponding verification possesses a signing key pair (with a corresponding verification
certificate), then this cr message will typically be protected by the certificate), then this cr message will typically be protected by the
entity's digital signature. The CA returns the new certificate (if the entity's digital signature. The CA returns the new certificate (if
request is successful) in a CertRepMessage. the request is successful) in a CertRepMessage.
4.9 Key Update 4.9 Key Update
When a key pair is due to expire the relevant end entity MAY request When a key pair is due to expire the relevant end entity MAY request
a key update - that is, it MAY request that the CA issue a new a key update - that is, it MAY request that the CA issue a new
certificate for a new key pair (or, in certain circumstances, a new certificate for a new key pair (or, in certain circumstances, a new
certificate for the same key pair). The request is made using a key certificate for the same key pair). The request is made using a key
update request (kur) message (referred to, in some environments, as a update request (kur) message (referred to, in some environments, as a
"Certificate Update" operation). If the end entity already possesses "Certificate Update" operation). If the end entity already possesses
a signing key pair (with a corresponding verification certificate), a signing key pair (with a corresponding verification certificate),
skipping to change at page 66, line 24 skipping to change at page 66, line 24
senderKID referenceNum senderKID referenceNum
-- the reference number which the CA has previously issued to the -- the reference number which the CA has previously issued to the
-- end entity (together with the MACing key) -- end entity (together with the MACing key)
transactionID present transactionID present
-- value from corresponding ir message -- value from corresponding ir message
senderNonce present senderNonce present
-- 128 (pseudo-)random bits -- 128 (pseudo-)random bits
recipNonce present recipNonce present
-- value from senderNonce in corresponding ir message -- value from senderNonce in corresponding ir message
freeText any valid value freeText any valid value
body ir (CertRepMessage) body ip (CertRepMessage)
contains exactly one response contains exactly one response
for each request for each request
-- The PKI (CA) responds to either one or two requests as appropriate. -- The PKI (CA) responds to either one or two requests as appropriate.
-- crc[0] denotes the first (always present); crc[1] denotes the -- crc[0] denotes the first (always present); crc[1] denotes the
-- second (only present if the ir message contained two requests and -- second (only present if the ir message contained two requests and
-- if the CA supports centralized key generation). -- if the CA supports centralized key generation).
crc[0]. fixed value of zero crc[0]. fixed value of zero
certReqId certReqId
-- MUST contain the response to the first request in the corresponding -- MUST contain the response to the first request in the corresponding
-- ir message -- ir message
skipping to change at page 67, line 43 skipping to change at page 67, line 43
recipient CA name recipient CA name
-- the name of the CA who was asked to produce a certificate -- the name of the CA who was asked to produce a certificate
transactionID present transactionID present
-- value from corresponding ir and ip messages -- value from corresponding ir and ip messages
senderNonce present senderNonce present
-- 128 (pseudo-) random bits -- 128 (pseudo-) random bits
recipNonce present recipNonce present
-- value from senderNonce in corresponding ip message -- value from senderNonce in corresponding ip message
protectionAlg MSG_MAC_ALG protectionAlg MSG_MAC_ALG
-- only MAC protection is allowed for this message. The MAC is -- only MAC protection is allowed for this message. The MAC is
-- based on the initial authentication key shared between the EE and the CA. -- based on the initial auth'n key shared between the EE and the CA.
senderKID referenceNum senderKID referenceNum
-- the reference number which the CA has previously issued to the -- the reference number which the CA has previously issued to the
-- end entity (together with the MACing key) -- end entity (together with the MACing key)
body certConf body certConf
-- see Section 3.3.18 for the contents of the certConf fields
-- Note: two CertStatus structures are required if both an
-- encryption and a signing certificate were sent.
protection present protection present
-- bits calculated using MSG_MAC_ALG -- bits calculated using MSG_MAC_ALG
PKIConf: PKIConf:
Field Value Field Value
sender present sender present
-- same as in ip -- same as in ip
recipient present recipient present
-- sender name from certConf -- sender name from certConf
skipping to change at page 90, line 32 skipping to change at page 90, line 32
-- implementation-specific error details -- implementation-specific error details
} }
PollReqContent ::= SEQUENCE OF SEQUENCE { PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER certReqId INTEGER
} }
PollRepContent ::= SEQUENCE OF SEQUENCE { PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER, certReqId INTEGER,
checkAfter INTEGER, -- time in seconds checkAfter INTEGER, -- time in seconds
reason [0] PKIFreeText OPTIONAL reason PKIFreeText OPTIONAL
} }
END -- of CMP module END -- of CMP module
Appendix G: Registration of MIME Type for E-Mail or HTTP use Appendix G: Registration of MIME Type for E-Mail or HTTP use
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkixcmp Subject: Registration of MIME media type application/pkixcmp
MIME media type name: application MIME media type name: application
skipping to change at page 92, line 7 skipping to change at page 92, line 7
Person and email address to contact for further information: Person and email address to contact for further information:
Carlisle Adams, cadams@entrust.com Carlisle Adams, cadams@entrust.com
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Carlisle Adams Author/Change controller: Carlisle Adams
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 29 change blocks. 
80 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/