< draft-ietf-pkix-ipki3cmp-08.txt   draft-ietf-pkix-ipki3cmp-09.txt >
Internet Draft C. Adams (Entrust Technologies) Internet Draft C. Adams (Entrust Technologies)
PKIX Working Group S. Farrell (SSE) PKIX Working Group S. Farrell (SSE)
draft-ietf-pkix-ipki3cmp-08.txt draft-ietf-pkix-ipki3cmp-09.txt
Expires in 6 months May 1998 Expires in 6 months Nov. 1998
Internet X.509 Public Key Infrastructure Internet X.509 Public Key Infrastructure
Certificate Management Protocols Certificate Management Protocols
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of 6 months Internet-Drafts are draft documents valid for a maximum of 6 months
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 material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check To learn the current status of any Internet-Draft, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.is.co.za(Africa), ftp.nordu.net (Europe),
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu ftp.isi.edu (US West Coast).
(US West Coast).
Abstract Abstract
This document describes the Internet X.509 Public Key Infrastructure This document describes the Internet X.509 Public Key Infrastructure
(PKI) Certificate Management Protocols. Protocol messages are defined (PKI) Certificate Management Protocols. Protocol messages are defined
for all relevant aspects of certificate creation and management. Note for all relevant aspects of certificate creation and management. Note
that "certificate" in this document refers to an X.509v3 Certificate as that "certificate" in this document refers to an X.509v3 Certificate as
defined in [COR95, X509-AM]. defined in [COR95, X509-AM].
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
skipping to change at page 4, line 32 skipping to change at page 4, line 32
In some circumstances end entities will communicate directly with a CA In some circumstances end entities will communicate directly with a CA
even where an RA is present. For example, for initial registration even where an RA is present. For example, for initial registration
and/or certification the subject may use its RA, but communicate and/or certification the subject may use its RA, but communicate
directly with the CA in order to refresh its certificate. directly with the CA in order to refresh its certificate.
1.3 PKI Management Requirements 1.3 PKI Management Requirements
The protocols given here meet the following requirements on PKI The protocols given here meet the following requirements on PKI
management. management.
1. PKI management MUST conform to the ISO 9594-8 standard and the 1. PKI management must conform to the ISO 9594-8 standard and the
associated amendments (certificate extensions) associated amendments (certificate extensions)
2. PKI management MUST conform to the other parts of this series. 2. PKI management must conform to the other parts of this series.
3. It MUST be possible to regularly update any key pair without 3. It must be possible to regularly update any key pair without
affecting any other key pair. affecting any other key pair.
4. The use of confidentiality in PKI management protocols MUST be kept 4. The use of confidentiality in PKI management protocols must be kept
to a minimum in order to ease regulatory problems. to a minimum in order to ease regulatory problems.
5. PKI management protocols MUST allow the use of different industry- 5. PKI management protocols must allow the use of different industry-
standard cryptographic algorithms, (specifically including RSA, DSA, standard cryptographic algorithms, (specifically including RSA, DSA,
MD5, SHA-1) -- this means that any given CA, RA, or end entity may, in MD5, SHA-1) -- this means that any given CA, RA, or end entity may, in
principle, use whichever algorithms suit it for its own key pair(s). principle, use whichever algorithms suit it for its own key pair(s).
6. PKI management protocols MUST not preclude the generation of key 6. PKI management protocols must not preclude the generation of key
pairs by the end-entity concerned, by an RA, or by a CA -- key pairs by the end-entity concerned, by an RA, or by a CA -- key
generation MAY also occur elsewhere, but for the purposes of PKI generation may also occur elsewhere, but for the purposes of PKI
management we can regard key generation as occurring wherever the key is management we can regard key generation as occurring wherever the key is
first present at an end entity, RA, or CA. first present at an end entity, RA, or CA.
7. PKI management protocols MUST support the publication of 7. PKI management protocols must support the publication of
certificates by the end-entity concerned, by an RA, or by a CA. certificates by the end-entity concerned, by an RA, or by a CA.
Different implementations and different environments may choose any Different implementations and different environments may choose any
of the above approaches. of the above approaches.
8. PKI management protocols MUST support the production of Certificate 8. PKI management protocols must support the production of Certificate
Revocation Lists (CRLs) by allowing certified end entities to make Revocation Lists (CRLs) by allowing certified end entities to make
requests for the revocation of certificates - this MUST be done in such requests for the revocation of certificates - this must be done in such
a way that the denial-of-service attacks which are possible are not made a way that the denial-of-service attacks which are possible are not made
simpler. simpler.
9. PKI management protocols MUST be usable over a variety of 9. PKI management protocols must be usable over a variety of
"transport" mechanisms, specifically including mail, http, TCP/IP and "transport" mechanisms, specifically including mail, http, TCP/IP and
ftp. ftp.
10. Final authority for certification creation rests with the CA; no 10. Final authority for certification creation rests with the CA; no
RA or end-entity equipment can assume that any certificate issued by a RA or end-entity equipment can assume that any certificate issued by a
CA will contain what was requested -- a CA MAY alter certificate field CA will contain what was requested -- a CA may alter certificate field
values or MAY add, delete or alter extensions according to its operating values or may add, delete or alter extensions according to its operating
policy. In other words, all PKI entities (end-entities, RAs, and CAs) policy. In other words, all PKI entities (end-entities, RAs, and CAs)
MUST be capable of handling responses to requests for certificates in must be capable of handling responses to requests for certificates in
which the actual certificate issued is different from that requested which the actual certificate issued is different from that requested
(for example, a CA may shorten the validity period requested). Note that (for example, a CA may shorten the validity period requested). Note that
policy MAY dictate that the CA MAY NOT publish or otherwise distribute policy may dictate that the CA must not publish or otherwise distribute
the certificate until the requesting entity has reviewed and accepted the certificate until the requesting entity has reviewed and accepted
the newly-created certificate (typically through use of the PKIConfirm the newly-created certificate (typically through use of the PKIConfirm
message). message).
11. A graceful, scheduled change-over from one non-compromised CA key 11. A graceful, scheduled change-over from one non-compromised CA key
pair to the next (CA key update) MUST be supported (note that if the pair to the next (CA key update) must be supported (note that if the
CA key is compromised, re-initialization MUST be performed for all CA key is compromised, re-initialization must be performed for all
entities in the domain of that CA). An end entity whose PSE contains entities in the domain of that CA). An end entity whose PSE contains
the new CA public key (following a CA key update) MUST also be able the new CA public key (following a CA key update) must also be able
to verify certificates verifiable using the old public key. End to verify certificates verifiable using the old public key. End
entities who directly trust the old CA key pair MUST also be able to entities who directly trust the old CA key pair must also be able to
verify certificates signed using the new CA private key. (Required for verify certificates signed using the new CA private key. (Required for
situations where the old CA public key is "hardwired" into the end situations where the old CA public key is "hardwired" into the end
entity's cryptographic equipment). entity's cryptographic equipment).
12. The Functions of an RA MAY, in some implementations or 12. The Functions of an RA may, in some implementations or
environments, be carried out by the CA itself. The protocols MUST be environments, be carried out by the CA itself. The protocols must be
designed so that end entities will use the same protocol (but, of designed so that end entities will use the same protocol (but, of
course, not the same key!) regardless of whether the communication is course, not the same key!) regardless of whether the communication is
with an RA or CA. with an RA or CA.
13. Where an end entity requests a certificate containing a given 13. Where an end entity requests a certificate containing a given
public key value, the end entity MUST be ready to demonstrate public key value, the end entity must be ready to demonstrate
possession of the corresponding private key value. This may be possession of the corresponding private key value. This may be
accomplished in various ways, depending on the type of certification accomplished in various ways, depending on the type of certification
request. See Section 2.3, "Proof of Possession of Private Key", for request. See Section 2.3, "Proof of Possession of Private Key", for
details of the in-band methods defined for the PKIX-CMP (i.e., details of the in-band methods defined for the PKIX-CMP (i.e.,
Certificate Management Protocol) messages. Certificate Management Protocol) messages.
PKI Management Operations PKI Management Operations
The following diagram shows the relationship between the entities The following diagram shows the relationship between the entities
defined above in terms of the PKI management operations. The letters in defined above in terms of the PKI management operations. The letters in
skipping to change at page 7, line 48 skipping to change at page 7, line 48
certificate in which the subject CA and the issuer CA are distinct and certificate in which the subject CA and the issuer CA are distinct and
SubjectPublicKeyInfo contains a verification key (i.e., the certificate SubjectPublicKeyInfo contains a verification key (i.e., the certificate
has been issued for the subject CA's signing key pair). When it is has been issued for the subject CA's signing key pair). When it is
necessary to distinguish more finely, the following terms may be used: necessary to distinguish more finely, the following terms may be used:
a cross-certificate is called an "inter-domain cross-certificate" if a cross-certificate is called an "inter-domain cross-certificate" if
the subject and issuer CAs belong to different administrative domains; the subject and issuer CAs belong to different administrative domains;
it is called an "intra-domain cross-certificate" otherwise. it is called an "intra-domain cross-certificate" otherwise.
Notes: Notes:
1. The above definition of "cross-certificate" aligns with the defined Note 1. The above definition of "cross-certificate" aligns with the
term "CA-certificate" in X.509. Note that this term is not to be defined term "CA-certificate" in X.509. Note that this term is not to
confused with the X.500 "cACertificate" attribute type, which is be confused with the X.500 "cACertificate" attribute type, which is
unrelated. unrelated.
2. In many environments the term "cross-certificate", unless further Note 2. In many environments the term "cross-certificate", unless
qualified, will be understood to be synonymous with "inter-domain further qualified, will be understood to be synonymous with
cross-certificate" as defined above. "inter-domain cross-certificate" as defined above.
3. Issuance of cross-certificates may be, but is not necessarily, Note 3. Issuance of cross-certificates may be, but is not necessarily,
mutual; that is, two CAs may issue cross-certificates for each other. mutual; that is, two CAs may issue cross-certificates for each other.
3.6 cross-certificate update: Similar to a normal certificate update 3.6 cross-certificate update: Similar to a normal certificate update
but involving a cross-certificate. but involving a cross-certificate.
4 Certificate/CRL discovery operations: some PKI management 4 Certificate/CRL discovery operations: some PKI management
operations result in the publication of certificates or CRLs: operations result in the publication of certificates or CRLs:
4.1 certificate publication: Having gone to the trouble of producing 4.1 certificate publication: Having gone to the trouble of producing
a certificate, some means for publishing it is needed. The "means" a certificate, some means for publishing it is needed. The "means"
skipping to change at page 10, line 25 skipping to change at page 10, line 25
transaction) via some out-of-band means. The initial authentication key transaction) via some out-of-band means. The initial authentication key
can then be used to protect relevant PKI messages. can then be used to protect relevant PKI messages.
We can thus classify the initial registration/certification scheme We can thus classify the initial registration/certification scheme
according to whether or not the on-line end entity -> PKI messages are according to whether or not the on-line end entity -> PKI messages are
authenticated or not. authenticated or not.
Note 1: We do not discuss the authentication of the PKI -> end entity Note 1: We do not discuss the authentication of the PKI -> end entity
messages here as this is always REQUIRED. In any case, it can be messages here as this is always REQUIRED. In any case, it can be
achieved simply once the root-CA public key has been installed at the achieved simply once the root-CA public key has been installed at the
end entity’s equipment or it can be based on the initial authentication end entity?s equipment or it can be based on the initial authentication
key. key.
Note 2: An initial registration / certification procedure can be secure Note 2: An initial registration / certification procedure can be secure
where the messages from the end entity are authenticated via some out- where the messages from the end entity are authenticated via some out-
of-band means (e.g., a subsequent visit). of-band means (e.g., a subsequent visit).
2.2.1.3 Location of key generation 2.2.1.3 Location of key generation
In this specification, "key generation" is regarded as occurring In this specification, "key generation" is regarded as occurring
wherever either the public or private component of a key pair first wherever either the public or private component of a key pair first
skipping to change at page 11, line 58 skipping to change at page 11, line 58
verify request verify request
process request process request
create response create response
--<<--certification response--<<-- --<<--certification response--<<--
handle response handle response
create confirmation create confirmation
-->>--confirmation message-->>-- -->>--confirmation message-->>--
verify confirmation verify confirmation
(Where verification of the confirmation message fails, the RA/CA MUST (Where verification of the confirmation message fails, the RA/CA MUST
revoke the newly issued certificate if necessary.) revoke the newly issued certificate if it has been published or
otherwise made available.)
2.3 Proof of Possession (POP) of Private Key 2.3 Proof of Possession (POP) of Private Key
In order to prevent certain attacks and to allow a CA/RA to properly In order to prevent certain attacks and to allow a CA/RA to properly
check the validity of the binding between an end entity and a key pair, check the validity of the binding between an end entity and a key pair,
the PKI management operations specified here make it possible for an end the PKI management operations specified here make it possible for an end
entity to prove that it has possession of (i.e., is able to use) the entity to prove that it has possession of (i.e., is able to use) the
private key corresponding to the public key for which a certificate is private key corresponding to the public key for which a certificate is
requested. A given CA/RA is free to choose how to enforce POP (e.g., requested. A given CA/RA is free to choose how to enforce POP (e.g.,
out-of-band procedural means versus PKIX-CMP in-band messages) in its out-of-band procedural means versus PKIX-CMP in-band messages) in its
certification exchanges (i.e., this may be a policy issue). However, certification exchanges (i.e., this may be a policy issue). However,
it is MANDATED that CAs/RAs MUST enforce POP by some means because there it is REQUIRED that CAs/RAs MUST enforce POP by some means because there
are currently many non-PKIX operational protocols in use (various are currently many non-PKIX operational protocols in use (various
electronic mail protocols are one example) that do not explicitly check electronic mail protocols are one example) that do not explicitly check
the binding between the end entity and the private key. Until the binding between the end entity and the private key. Until
operational protocols that do verify the binding (for signature, operational protocols that do verify the binding (for signature,
encryption, and key agreement key pairs) exist, and are ubiquitous, this encryption, and key agreement key pairs) exist, and are ubiquitous, this
binding can only be assumed to have been verified by the CA/RA. binding can only be assumed to have been verified by the CA/RA.
Therefore, if the binding is not verified by the CA/RA, certificates in Therefore, if the binding is not verified by the CA/RA, certificates in
the Internet Public-Key Infrastructure end up being somewhat less the Internet Public-Key Infrastructure end up being somewhat less
meaningful. meaningful.
POP is accomplished in different ways depending on the type of key for POP is accomplished in different ways depending upon the type of key for
which a certificate is requested. If a key can be used for multiple which a certificate is requested. If a key can be used for multiple
purposes (e.g., an RSA key) then any of the methods MAY be used. purposes (e.g., an RSA key) then any appropriate method MAY be used
(e.g., a key which may be used for signing, as well as other purposes,
SHOULD NOT be sent to the CA/RA in order to prove possession).
This specification explicitly allows for cases where an end entity This specification explicitly allows for cases where an end entity
supplies the relevant proof to an RA and the RA subsequently attests to supplies the relevant proof to an RA and the RA subsequently attests to
the CA that the required proof has been received (and validated!). For the CA that the required proof has been received (and validated!). For
example, an end entity wishing to have a signing key certified could example, an end entity wishing to have a signing key certified could
send the appropriate signature to the RA which then simply notifies the send the appropriate signature to the RA which then simply notifies the
relevant CA that the end entity has supplied the required proof. Of relevant CA that the end entity has supplied the required proof. Of
course, such a situation may be disallowed by some policies (e.g., CAs course, such a situation may be disallowed by some policies (e.g., CAs
may be the only entities permitted to verify POP during certification). may be the only entities permitted to verify POP during certification).
skipping to change at page 17, line 44 skipping to change at page 17, line 44
The PKIHeader contains information which is common to many PKI messages. The PKIHeader contains information which is common to many PKI messages.
The PKIBody contains message-specific information. The PKIBody contains message-specific information.
The PKIProtection, when used, contains bits that protect the PKI The PKIProtection, when used, contains bits that protect the PKI
message. message.
The extraCerts field can contain certificates that may be useful to the The extraCerts field can contain certificates that may be useful to the
recipient. For example, this can be used by a CA or RA to present an end recipient. For example, this can be used by a CA or RA to present an end
entity with certificates that it needs to verify its own new certificate entity with certificates that it needs to verify its own new certificate
(if, for example, the CA that issued the end entity’s certificate is not (if, for example, the CA that issued the end entity?s certificate is not
a root CA for the end entity). Note that this field does not a root CA for the end entity). Note that this field does not
necessarily contain a certification path - the recipient may have to necessarily contain a certification path - the recipient may have to
sort, select from, or otherwise process the extra certificates in order sort, select from, or otherwise process the extra certificates in order
to use them. to use them.
3.1.1 PKI Message Header 3.1.1 PKI Message Header
All PKI messages require some header information for addressing and All PKI messages require some header information for addressing and
transaction identification. Some of this information will also be transaction identification. Some of this information will also be
present in a transport-specific envelope; however, if the PKI message is present in a transport-specific envelope; however, if the PKI message is
skipping to change at page 19, line 32 skipping to change at page 19, line 32
The protectionAlg field specifies the algorithm used to protect the The protectionAlg field specifies the algorithm used to protect the
message. If no protection bits are supplied (note that PKIProtection message. If no protection bits are supplied (note that PKIProtection
is OPTIONAL) then this field MUST be omitted; if protection bits are is OPTIONAL) then this field MUST be omitted; if protection bits are
supplied then this field MUST be supplied. supplied then this field MUST be supplied.
senderKID and recipKID are usable to indicate which keys have been used senderKID and recipKID are usable to indicate which keys have been used
to protect the message (recipKID will normally only be required where to protect the message (recipKID will normally only be required where
protection of the message uses Diffie-Hellman (DH) keys). protection of the message uses Diffie-Hellman (DH) keys).
The transactionID field within the message header is REQUIRED so that The transactionID field within the message header MAY be used to allow
the recipient of a response message can correlate this with a previously the recipient of a response message to correlate this with a previously
issued request. For example, in the case of an RA there may be many issued request. For example, in the case of an RA there may be many
requests "outstanding" at a given moment. requests "outstanding" at a given moment.
The senderNonce and recipNonce fields protect the PKIMessage against The senderNonce and recipNonce fields protect the PKIMessage against
replay attacks. replay attacks.
The messageTime field contains the time at which the sender created the The messageTime field contains the time at which the sender created the
message. This may be useful to allow end entities to correct their local message. This may be useful to allow end entities to correct their local
time to be consistent with the time on a central system. time to be consistent with the time on a central system.
skipping to change at page 24, line 55 skipping to change at page 24, line 55
-- as defined by local policy -- as defined by local policy
badCertId (4), badCertId (4),
-- no certificate could be found matching the provided criteria -- no certificate could be found matching the provided criteria
badDataFormat (5), badDataFormat (5),
-- the data submitted has the wrong format -- the data submitted has the wrong format
wrongAuthority (6), wrongAuthority (6),
-- the authority indicated in the request is different from the -- the authority indicated in the request is different from the
-- one creating the response token -- one creating the response token
incorrectData (7), incorrectData (7),
-- the requester's data is incorrect (used for notary services) -- the requester's data is incorrect (used for notary services)
missingTimeStamp (8) missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy) -- when the timestamp is missing but should be there (by policy)
badPOP (9)
-- the proof-of-possession failed
} }
PKIStatusInfo ::= SEQUENCE { PKIStatusInfo ::= SEQUENCE {
status PKIStatus, status PKIStatus,
statusString PKIFreeText OPTIONAL, statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL failInfo PKIFailureInfo OPTIONAL
} }
3.2.4 Certificate Identification 3.2.4 Certificate Identification
In order to identify particular certificates the CertId data structure In order to identify particular certificates the CertId data structure
skipping to change at page 36, line 46 skipping to change at page 36, line 46
4.6.1 One-way request-response scheme: 4.6.1 One-way request-response scheme:
The cross-certification scheme is essentially a one way operation; that The cross-certification scheme is essentially a one way operation; that
is, when successful, this operation results in the creation of one new is, when successful, this operation results in the creation of one new
cross-certificate. If the requirement is that cross-certificates be cross-certificate. If the requirement is that cross-certificates be
created in "both directions" then each CA in turn must initiate a cross- created in "both directions" then each CA in turn must initiate a cross-
certification operation (or use another scheme). certification operation (or use another scheme).
This scheme is suitable where the two CAs in question can already verify This scheme is suitable where the two CAs in question can already verify
each other’s signatures (they have some common points of trust) or where each other?s signatures (they have some common points of trust) or where
there is an out-of-band verification of the origin of the certification there is an out-of-band verification of the origin of the certification
request. request.
Detailed Description: Detailed Description:
Cross certification is initiated at one CA known as the responder. The Cross certification is initiated at one CA known as the responder. The
CA administrator for the responder identifies the CA it wants to cross CA administrator for the responder identifies the CA it wants to cross
certify and the responder CA equipment generates an authorization code. certify and the responder CA equipment generates an authorization code.
The responder CA administrator passes this authorization code by out-of- The responder CA administrator passes this authorization code by out-of-
band means to the requester CA administrator. The requester CA band means to the requester CA administrator. The requester CA
skipping to change at page 38, line 32 skipping to change at page 38, line 32
the root CA to the certifying CA together with appropriate revocation the root CA to the certifying CA together with appropriate revocation
lists lists
- the algorithms and algorithm parameters which the certifying CA - the algorithms and algorithm parameters which the certifying CA
supports for each relevant usage supports for each relevant usage
Additional information could be required (e.g., supported extensions Additional information could be required (e.g., supported extensions
or CA policy information) in order to produce a certification request or CA policy information) in order to produce a certification request
which will be successful. However, for simplicity we do not mandate that which will be successful. However, for simplicity we do not mandate that
the end entity acquires this information via the PKI messages. The end the end entity acquires this information via the PKI messages. The end
result is simply that some certification requests may fail (e.g., if the result is simply that some certification requests may fail (e.g., if the
end entity wants to generate its own encryption key but the CA doesn’t end entity wants to generate its own encryption key but the CA doesn?t
allow that). allow that).
The required information MAY be acquired as described in Section 4.5. The required information MAY be acquired as described in Section 4.5.
4.7.2 Out-of-Band Verification of Root-CA Key 4.7.2 Out-of-Band Verification of Root-CA Key
An end entity must securely possess the public key of its root CA. One An end entity must securely possess the public key of its root CA. One
method to achieve this is to provide the end entity with the CA’s self- method to achieve this is to provide the end entity with the CA?s self-
certificate fingerprint via some secure "out-of-band" means. The end certificate fingerprint via some secure "out-of-band" means. The end
entity can then securely use the CA’s self-certificate. entity can then securely use the CA?s self-certificate.
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 a certificate at any time (as part An initialized end entity MAY request a certificate at any time (as part
of an update procedure, or for any other purpose). This request will be of an update procedure, or for any other purpose). This request will be
made using the certification request (cr) message. If the end entity made using the certification request (cr) message. If the end entity
already possesses a signing key pair (with a corresponding verification already 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
skipping to change at page 41, line 15 skipping to change at page 41, line 15
A "direct TCP-based PKI message" consists of: A "direct TCP-based PKI message" consists of:
length (32-bits), flag (8-bits), value (defined below) length (32-bits), flag (8-bits), value (defined below)
The length field contains the number of octets of the remainder of the The length field contains the number of octets of the remainder of the
message (i.e., number of octets of "value" plus one). All 32-bit values message (i.e., number of octets of "value" plus one). All 32-bit values
in this protocol are specified to be in network byte order. in this protocol are specified to be in network byte order.
Message name flag value Message name flag value
msgReq ‘00’H DER-encoded PKI message msgReq ?00?H DER-encoded PKI message
-- PKI message from initiator -- PKI message
pollRep ‘01’H polling reference (32 bits), pollRep ?01?H polling reference (32 bits),
time-to-check-back (32 bits) time-to-check-back (32 bits)
-- poll response where no PKI message response ready; use polling -- poll response where no PKI message response ready; use polling
-- reference value (and estimated time value) for later polling -- reference value (and estimated time value) for later polling
pollReq ‘02’H polling reference (32 bits) pollReq ?02?H polling reference (32 bits)
-- request for a PKI message response to initial message -- request for a PKI message response to initial message
negPollRep ‘03’H ‘00’H negPollRep ?03?H ?00?H
-- no further polling responses (i.e., transaction complete) -- no further polling responses (i.e., transaction complete)
partialMsgRep ‘04’H next polling reference (32 bits), partialMsgRep ?04?H next polling reference (32 bits),
time-to-check-back (32 bits), time-to-check-back (32 bits),
DER-encoded PKI message DER-encoded PKI message
-- partial response to initial message plus new polling reference -- partial response to initial message plus new polling reference
-- (and estimated time value) to use to get next part of response -- (and estimated time value) to use to get next part of response
finalMsgRep ‘05’H DER-encoded PKI message finalMsgRep ?05?H DER-encoded PKI message
-- final (and possibly sole) response to initial message -- final (and possibly sole) response to initial message
errorMsgRep ‘06’H human readable error message errorMsgRep ?06?H human readable error message
-- produced when an error is detected (e.g., a polling reference is -- produced when an error is detected (e.g., a polling reference is
-- received which doesn’t exist or is finished with) -- received which doesn?t exist or is finished with)
Where a PKIConfirm message is to be transported (always from the Where a PKIConfirm message is to be transported (always from the
initiator to the responder) then a msgReq message is sent and a initiator to the responder) then a msgReq message is sent and a
negPollRep is returned. negPollRep is returned.
The sequence of messages which can occur is then: The sequence of messages which can occur is then:
a) end entity sends msgReq and receives one of pollRep, negPollRep, a) end entity sends msgReq and receives one of pollRep, negPollRep,
partialMsgRep or finalMsgRep in response. partialMsgRep or finalMsgRep in response.
b) end entity sends pollReq message and receives one of negPollRep, b) end entity sends pollReq message and receives one of negPollRep,
skipping to change at page 43, line 25 skipping to change at page 43, line 25
arbitrary challenge and returning the cleartext to an attacker. arbitrary challenge and returning the cleartext to an attacker.
Although in this specification a number of other failures in Although in this specification a number of other failures in
security are required in order for this attack to succeed, it is security are required in order for this attack to succeed, it is
conceivable that some future services (e.g., notary, trusted time) conceivable that some future services (e.g., notary, trusted time)
could potentially be vulnerable to such attacks. For this reason we could potentially be vulnerable to such attacks. For this reason we
re-iterate the general rule that implementations should be very re-iterate the general rule that implementations should be very
careful about decrypting arbitrary "ciphertext" and revealing careful about decrypting arbitrary "ciphertext" and revealing
recovered "plaintext" since such a practice can lead to serious recovered "plaintext" since such a practice can lead to serious
security vulnerabilities. security vulnerabilities.
Note also that exposing a private key to the CA/RA as a proof-of-
possession technique can carry some security risks (depending upon
whether or not the CA/RA can be trusted to handle such material
appropriately). Implementers are advised to exercise caution in
selecting and using this particular POP mechanism.
References References
[COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC [COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC
9594-8: 1990 & 1993 (1995:E), July 1995. 9594-8: 1990 & 1993 (1995:E), July 1995.
[CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, "Certificate Request [CRMF] M. Myers, C. Adams, D. Solo, D. Kemp, "Certificate Request
Message Format", Internet Draft Message Format", Internet Draft
draft-ietf-pkix-crmf-0x.txt (work in progress). draft-ietf-pkix-crmf-0x.txt (work in progress).
[MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of [MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of
skipping to change at page 47, line 18 skipping to change at page 47, line 18
receiver can validly reject a message containing such fields as receiver can validly reject a message containing such fields as
being syntactically incorrect). being syntactically incorrect).
Mandatory fields are not mentioned if they have an obvious value Mandatory fields are not mentioned if they have an obvious value
(e.g., pvno). (e.g., pvno).
2.Where structures occur in more than one message, they are 2.Where structures occur in more than one message, they are
separately profiled as appropriate. separately profiled as appropriate.
3.The algorithmIdentifiers from PKIMessage structures are profiled 3.The algorithmIdentifiers from PKIMessage structures are profiled
separately. separately.
4.A "special" X.500 DN is called the "NULL-DN"; this means a DN 4.A "special" X.500 DN is called the "NULL-DN"; this means a DN
containing a zero-length SEQUENCE OF RelativeDistinguishedNames containing a zero-length SEQUENCE OF RelativeDistinguishedNames
(its DER encoding is then ‘3000’H). (its DER encoding is then ?3000?H).
5.Where a GeneralName is required for a field but no suitable 5.Where a GeneralName is required for a field but no suitable
value is available (e.g., an end entity produces a request before value is available (e.g., an end entity produces a request before
knowing its name) then the GeneralName is to be an X.500 NULL-DN knowing its name) then the GeneralName is to be an X.500 NULL-DN
(i.e., the Name field of the CHOICE is to contain a NULL-DN). (i.e., the Name field of the CHOICE is to contain a NULL-DN).
This special value can be called a "NULL-GeneralName". This special value can be called a "NULL-GeneralName".
6.Where a profile omits to specify the value for a GeneralName 6.Where a profile omits to specify the value for a GeneralName
then the NULL-GeneralName value is to be present in the relevant then the NULL-GeneralName value is to be present in the relevant
PKIMessage field. This occurs with the sender field of the PKIMessage field. This occurs with the sender field of the
PKIHeader for some messages. PKIHeader for some messages.
7.Where any ambiguity arises due to naming of fields, the profile 7.Where any ambiguity arises due to naming of fields, the profile
skipping to change at page 48, line 11 skipping to change at page 48, line 11
Mandatory: an AlgorithmIdentifier which MUST be supported by Mandatory: an AlgorithmIdentifier which MUST be supported by
conforming implementations conforming implementations
Others: alternatives to the mandatory AlgorithmIdentifier Others: alternatives to the mandatory AlgorithmIdentifier
Name Use Mandatory Others Name Use Mandatory Others
MSG_SIG_ALG Protection of PKI DSA/SHA-1 RSA/MD5... MSG_SIG_ALG Protection of PKI DSA/SHA-1 RSA/MD5...
messages using signature messages using signature
MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC, MSG_MAC_ALG protection of PKI PasswordBasedMac HMAC,
messages using MACing X9.9... messages using MACing X9.9...
SYM_PENC_ALG symmetric encryption of 3-DES (3-key- RC5, SYM_PENC_ALG symmetric encryption of 3-DES (3-key- RC5,
an end entity’s private EDE, CBC mode) CAST-128... an end entity?s private EDE, CBC mode) CAST-128...
key where symmetric key where symmetric
key is distributed key is distributed
out-of-band out-of-band
PROT_ENC_ALG asymmetric algorithm D-H RSA PROT_ENC_ALG asymmetric algorithm D-H RSA
used for encryption of used for encryption of
(symmetric keys for (symmetric keys for
encryption of) private encryption of) private
keys transported in keys transported in
PKIMessages PKIMessages
PROT_SYM_ALG symmetric encryption 3-DES (3-key- RC5, PROT_SYM_ALG symmetric encryption 3-DES (3-key- RC5,
skipping to change at page 55, line 24 skipping to change at page 55, line 24
another key pair (typically an encryption key pair). another key pair (typically an encryption key pair).
Certification may only be requested for one locally generated public key Certification may only be requested for one locally generated public key
(for more, use separate PKIMessages). (for more, use separate PKIMessages).
The end entity MUST support proof-of-possession of the private key The end entity MUST support proof-of-possession of the private key
associated with the locally-generated public key. associated with the locally-generated public key.
Preconditions: Preconditions:
1.The end entity can authenticate the CA’s signature based on out-of- 1.The end entity can authenticate the CA?s signature based on out-of-
band means band means
2.The end entity and the CA share a symmetric MACing key 2.The end entity and the CA share a symmetric MACing key
Message flow: Message flow:
Step# End entity PKI Step# End entity PKI
1 format ir 1 format ir
2 -> ir -> 2 -> ir ->
3 handle ir 3 handle ir
4 format ip 4 format ip
skipping to change at page 57, line 51 skipping to change at page 57, line 51
-- ir message -- ir message
crc[0].status. present, positive values allowed: crc[0].status. present, positive values allowed:
status "granted", "grantedWithMods" status "granted", "grantedWithMods"
negative values allowed: negative values allowed:
"rejection" "rejection"
crc[0].status. present if and only if crc[0].status. present if and only if
failInfo crc[0].status.status is "rejection" failInfo crc[0].status.status is "rejection"
crc[0]. present if and only if crc[0]. present if and only if
certifiedKeyPair crc[0].status.status is certifiedKeyPair crc[0].status.status is
"granted" or "grantedWithMods" "granted" or "grantedWithMods"
certificate present unless end entity’s public certificate present unless end entity?s public
key is an encryption key and POP key is an encryption key and POP
is done in this in-band exchange is done in this in-band exchange
encryptedCert present if and only if end entity’s encryptedCert present if and only if end entity?s
public key is an encryption key and public key is an encryption key and
POP done in this in-band exchange POP done in this in-band exchange
publicationInfo optionally present publicationInfo optionally present
-- indicates where certificate has been published (present at -- indicates where certificate has been published (present at
-- discretion of CA) -- discretion of CA)
crc[1]. fixed value of one crc[1]. fixed value of one
certReqId certReqId
-- MUST contain the response to the second request in the -- MUST contain the response to the second request in the
-- corresponding ir message -- corresponding ir message
skipping to change at page 62, line 48 skipping to change at page 62, line 48
-- as defined by local policy -- as defined by local policy
badCertId (4), badCertId (4),
-- no certificate could be found matching the provided criteria -- no certificate could be found matching the provided criteria
badDataFormat (5), badDataFormat (5),
-- the data submitted has the wrong format -- the data submitted has the wrong format
wrongAuthority (6), wrongAuthority (6),
-- the authority indicated in the request is different from the -- the authority indicated in the request is different from the
-- one creating the response token -- one creating the response token
incorrectData (7), incorrectData (7),
-- the requester's data is incorrect (for notary services) -- the requester's data is incorrect (for notary services)
missingTimeStamp (8) missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy) -- when the timestamp is missing but should be there (by policy)
badPOP (9)
-- the proof-of-possession failed
} }
PKIStatusInfo ::= SEQUENCE { PKIStatusInfo ::= SEQUENCE {
status PKIStatus, status PKIStatus,
statusString PKIFreeText OPTIONAL, statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL failInfo PKIFailureInfo OPTIONAL
} }
OOBCert ::= Certificate OOBCert ::= Certificate
OOBCertHash ::= SEQUENCE { OOBCertHash ::= SEQUENCE {
skipping to change at page 67, line 13 skipping to change at page 67, line 13
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
Appendix D: Registration of MIME Type for Section 5 Appendix D: Registration of MIME Type for Section 5
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
MIME subtype name: pkixcmp MIME subtype name: pkixcmp
Required parameters: Content-Transfer-Encoding: base64 Required parameters: -
Optional parameters: - Optional parameters: -
Encoding considerations: Encoding considerations:
Content is the base64-encoded, ASN.1 DER encoding of a PKI message, as Content may contain arbitrary octet values (the ASN.1 DER encoding of
defined in the IETF PKIX Working Group specifications. a PKI message, as defined in the IETF PKIX Working Group
specifications). base64 encoding is required for MIME e-mail; no
encoding is necessary for HTTP.
Security considerations: Security considerations:
This MIME type may be used to transport Public-Key Infrastructure (PKI) This MIME type may be used to transport Public-Key Infrastructure (PKI)
messages between PKI entities. These messages are defined by the IETF messages between PKI entities. These messages are defined by the IETF
PKIX Working Group and are used to establish and maintain an Internet PKIX Working Group and are used to establish and maintain an Internet
X.509 PKI. There is no requirement for specific security mechanisms to X.509 PKI. There is no requirement for specific security mechanisms to
be applied at this level if the PKI messages themselves are protected be applied at this level if the PKI messages themselves are protected
as defined in the PKIX specifications. as defined in the PKIX specifications.
Interoperability considerations: - Interoperability considerations: -
skipping to change at page 67, line 41 skipping to change at page 67, line 43
Published specification: this document Published specification: this document
Applications which use this media type: Applications which use this media type:
Applications using certificate management, operational, or ancillary Applications using certificate management, operational, or ancillary
protocols (as defined by the IETF PKIX Working Group) to send PKI protocols (as defined by the IETF PKIX Working Group) to send PKI
messages via E-Mail or HTTP. messages via E-Mail or HTTP.
Additional information: Additional information:
Magic number (s): - Magic number (s): -
File extension (s): - File extension (s): ".PKI"
Macintosh File Type Code (s): - Macintosh File Type Code (s): -
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
 End of changes. 55 change blocks. 
69 lines changed or deleted 83 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/