One document matched: draft-ietf-pkix-ipki3cmp-00.txt
Expires in 6 months June 1996
Internet Public Key Infrastructure
Part III: Certificate Management Protocols
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of 6 months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This is the third draft of the Internet Public Key Infrastructure
X.509 Certificate Management Protocols. This document is based on
sections 7, 9 and 10 of draft-ietf-pkix-ipki-00.txt. Many changes
have been made as a result of discussion at the Dallas IETF in
December 1995, the Los Angeles IETF in March 1996, and discussion on
the ietf-pkix@tandem.com mail list. The intent of this document is to
generate further productive discussion and to build consensus.
1. Executive Summary
<< To be supplied. >>
2. PKI Management Overview
The PKI must be structured to be consistent with the types of
individuals who must administer it. Providing such administrators
Farrell, Adams, Ford [Page 1]
INTERNET-DRAFT June 1996
with unbounded choices complicates not only the software required but
also increases the chances that a subtle mistake by an administrator
or software developer will result in broader compromise. Similarly,
restricting administrators with cumbersome mechanisms will cause them
not to use the PKI.
Management protocols are required to support on-line interactions
between Public Key Infrastructure (PKI) components. For example, a
management protocol might be used between a CA and a client system
with which a key pair is associated, or between two CAs which cross-
certify each other.
2.1 PKI Management Model
Before specifying particular message formats and procedures we first
define the entities involved in PKI management and their interactions
(in terms of the PKI management functions required). We then group
these functions in order to accomodate different identifiable types
of end entities.
2.1.1. Definitions of PKI Entities
The entities involved in PKI management include the end entity (i.e.
the entity to be named in the subject field of a certificate) and the
certification authority (i.e. the entity named in the issuer field of
a certificate). A registration authority may also be involved in PKI
management.
2.1.1.1. Subjects and End Entities
The term "subject" is used here to refer to the entity named by the
subject field of a certificate; when we wish to distinguish the tools
and/or software used by the subject (e.g. a local certificate
management module) we will use the term "subject equipment".
It is important to note that the end entities here will include not
only human users of applications, but also applications themselves
(e.g. for IP security). This factor influences the protocols which
the PKI management operations use; e.g., applications software is far
more likely to know exactly which certificate extensions are required
than are human users. PKI management entities are also end entities
in the sense that they are sometimes named in the subject field of a
certificate or cross-certificate. Where appropriate, the term "end-
entity" will be used to refer to end entities who are not PKI
management entities.
All end entities require secure local access to some information -- at
a minimum, their own name and private key, the name of a CA which is
directly trusted by this subject and that CA's public key (or a
digest of the public key where a self-certified version is available
elsewhere). Implementations may use secure local storage for more
than this minimum (e.g. the end entity's own certificate or
Farrell, Adams, Ford [Page 2]
INTERNET-DRAFT June 1996
application-specific information). The form of storage will also vary
-- from files to tamper resistant cryptographic tokens. Such local
trusted storage is referred to here as the end entity's Personal
Security Environment (PSE).
<< The PSE content is not defined further here as it is very
dependent on equipment, et cetera. However, an interchange format for
a generic PSE might be useful - we could consider using a CertRep
message for this.>>
2.1.1.2. Certification Authority
The certification authority (CA) may or may not actually be a real
"third party" from the end entity's point of view. Quite often, the
CA will actually belong to the same organisation as the end entities
it supports.
Again, we use the term CA to refer to the entity named in the issuer
field of a certificate; when it is necessary to distinguish the
software or hardware tools used by the CA we use the term "CA
equipment".
The CA equipment will often include both an "off-line" component and
an "on-line" component, with the CA private key only available to the
"off-line" component. This is, however, a matter for implementors
(though it is also relevant as a policy issue).
2.1.1.3. Registration Authority
In addition to end entities and CAs, many environments call for the
existence of a registration authority (RA) separate from the
certification authority. The functions which the registration
authority may carry out will vary from case to case but may include
personal authentication, token distribution, revocation reporting,
name assignment, key generation, archival of key pairs, et cetera.
This document views the RA as an optional component - when it is not
present the CA is assumed to be able to carry out the RA's functions
so that the PKI management protocols are the same from the end
entity's point of view.
Again, we distinguish, where necessary, between the RA and the tools
used (the "RA equipment").
Note that an RA is itself an end entity. We further assume that all
RAs are in fact certified end entities and that the RA private key is
usable for signing. How a particular CA equipment identifies some end
entities as RAs is an implementation issue (so there is no special RA
certification operation). We do not mandate that the RA is certified
by the CA with which it is interacting at the moment (so one RA may
work with more than one CA whilst only being certified once).
Farrell, Adams, Ford [Page 3]
INTERNET-DRAFT June 1996
In some circumstances end entities will communicate directly with a
CA even where an RA is present. For example, for initial registration
and/or certification the subject may use its RA, but communicate
directly with the CA in order to refresh its certificate.
The reasons which justify the presence of an RA can be split into
those which are due to technical factors and those which are
organizational in nature. Technical reasons include the following.
-If hardware tokens are in use, then not all end entities will
have the equipment needed to initialize these; the RA equipment can
include the necessary functionality (this may also be a matter of
policy).
-Some end entities may not have the capability to publish
certificates; again, the RA may be suitably placed for this.
-The RA will be able to issue signed revocation requests on
behalf of end entities associated with it, whereas the end entity may
not be able to do this (if the key pair is completely lost).
Some of the organisational reasons which argue for the presence of an
RA are the following.
-It may be more cost effective to concentrate functionality in
the RA equipment, than to supply functionality to all end entities
(especially if special token initialization equipment is to be used).
-Establishing RAs within an organization can reduce the number
of CAs required, which is sometimes desirable.
-RAs may be better placed to identify people with their
"electronic" names, especially if the CA is physically remote from
the end entity.
-For many applications there will already be in place some
administrative structure so that candidates for the role of RA are
easy to find (which may not be true of the CA).
2.1.2. PKI Management Requirements
The protocols given here meet the following requirements on PKI
management.
2.1.2.1. PKI management must conform to ISO 9594-8 and the
associated draft amendment (DAM)
2.1.2.2. PKI management must conform to the other parts of this
series.
Farrell, Adams, Ford [Page 4]
INTERNET-DRAFT June 1996
2.1.2.3. It must be possible to regularly update any key pair
without affecting any other key pair
2.1.2.4. The use of confidentiality in PKI management protocols must
be kept to a minimum in order to ease regulatory problems
2.1.2.5. PKI management protocols must allow the use of different
industry-standard cryptographic algorithms, (specifically
including, RSA, DSA, MD5, SHA-1) -- this means that any given CA,
RA, or end entity may, in principal, use whichever algorithms suit
it for its own key pair(s).
2.1.2.6. PKI management protocols must not preclude the generation
of key pairs by the end entity concerned, an RA, or a CA -- key
generation may also occur elsewhere, but for the purposes of PKI
management we can regard key generation as occurring wherever the
key is first present at an end entity, RA or CA.
2.1.2.7. PKI management protocols must support the publication of
certificates by the end entity concerned, an RA or a CA.
Different implementations and different environments may choose
any of the above approaches.
2.1.2.8. PKI management protocols must support the production of
CRLs by allowing certified end entities to make 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
simpler.
2.1.2.9. PKI management protocols must be usable over a variety of
"transport" mechanisms, specifically including, mail, http,
TCP/IP and ftp.
2.1.2.10. Final authority for certification creation rests with
the CA; no RA or end entity equipment should assume that any
certificate issued by a CA will contain what was requested -- a CA
may alter certificate field values or may add, delete or alter
extensions according to its operating policy; the only exception
to this is the public key, which the CA may not modify (assuming
that the CA was presented with the public key value). In other
words, all PKI entities (end entities, RAs and CAs) must be
capable of handling responses to requests for certificates in
which the actual certificate issued is different from that
requested -- for example, a CA may shorten the validity period
requested.
2.1.2.11. A graceful, scheduled change-over from one non-compromised
CA key pair to the next must be supported (CA key update).
2.1.2.12. A subject whose PSE contains the new CA public key
(following a CA key update) must also be able to verify certificates
verifiable using the old public key.
Farrell, Adams, Ford [Page 5]
INTERNET-DRAFT June 1996
2.1.2.13. End entities who directly trust the old CA key pair
must be able to verify certificates signed using the new CA
private key (following a CA key update). This is required for
situations where the old CA public key is "hardwired" into the
end entity's cryptographic equipment (e.g., smartcard memory).
2.1.2.14. The Functions of an RA may, in some implementations or
environments, be carried out by the CA itself. The protocols
should be designed so that end entities will use the same protocol
regardless of whether the communication is with an RA or CA.
2.1.3. PKI Management Operations
The following diagram shows the relationship between the entities
defined above in terms of the PKI management operations. The numbers
in the diagram indicate "protocols" in the sense that a defined set
of PKI management messages can be sent along each of the numbered
lines.
cert. publish +------------+
+---+ +------------ | End Entity | Operations
| C | | 7 +------------+
| e | <--------+ | ^ initial
| r | 1 | | 2 registration/
| t | PKI "users" | | certification
| | | | key pair recovery
| / | | | key pair update
| | | | certificate update
| C | V | revocation request
| R | -------+-+-----+-+------+-+-----
| L | PKI management | ^ | ^
| | entities 1 | | 2 1 | | 2
| | V | | |
| R | 7 +------+ 4 | |
| e | <------------ | RA | <-----+ | |
| p | cert. | | ----+ | | |
| o | publish +------+ 3 | | | |
| s | | | | |
| i | V | V |
| t | 8 +------------+ 9
| o | <------------------------| CA |------->
| r | +------------+ "out-of-band"
| y | cert. publish | ^ publication
| | CRL publish | |
+---+ | | cross-certification
| | 6 cross-certificate
| | update
| |
V |
+------+
| CA-2 |
+------+
Figure 1 - PKI Entities
Farrell, Adams, Ford [Page 6]
INTERNET-DRAFT June 1996
At a high level the set of functions for which management messages
are defined is as follows.
-CA establishment: When establishing a new CA, certain steps are
required (e.g., production of initial CRLs).
-export of CA public key for "out-of-band" mechanisms: CAs must
provide their public keys to end-entities. In order to facilitate
interoperability between different CA and end-entity implementations
a data structure for this purpose is required.
-initial registration/certification: This is the process whereby a
subject first makes itself known to a CA or RA, prior to the CA
issuing a certificate or certificates for that user. The end result
of this process (when it is successful) is that a CA issues a
certificate for an end entity's public key, and returns that
certificate to the subject and/or posts that certificate in a public
repository. This process may, and typically will, involve multiple
"steps", possibly including an initialization of the end entity's
equipment. For example, the subject equipment must be securely
initialized with the public key of a CA, to be used in validating
certificate paths. Furthermore, a subject typically needs to be
initialized with its own key pair(s).
-key pair update: Every key pair needs to be updated regularly
(i.e., replaced with a new key pair), and a new certificate needs to
be issued.
-certificate update: As certificates expire they may be "refreshed"
if nothing relevant in the environment has changed.
-certificate publication: Having gone to the trouble of producing
a certificate some means for publishing it is needed.
Note that the above three functions will often be combined.
-key pair recovery: As an option, user client key materials (e.g.,
a user's private key used for decryption purposes) may be backed up
by a CA, an RA or a key backup system associated with a CA or RA. If
a subject needs to recover these backed up key materials (e.g., as a
result of a forgotten password or a lost key chain file), a
protocol exchange may be needed to support such recovery.
-revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
Farrell, Adams, Ford [Page 7]
INTERNET-DRAFT June 1996
-CA key pair update: As with end entities, CA key pairs need to
be updated regularly; however, different mechanisms are required.
-cross-certification: Two CAs exchange the information necessary to
establish cross-certificates between those CAs.
-cross-certificate update: Similar to a normal certificate update
but involving a cross-certificate.
-CRL publication: As for certificates.
Note that on-line protocols are not the only way of implementing the
above functions. For all functions there are off-line methods of
achieving the same result, and this specification does not mandate
use of on-line protocols. For example, when hardware tokens are
used, many of the functions may be achieved as part of the physical
token delivery.
Later sections define a set of standard protocols supporting the
above operations. The protocols for conveying these exchanges in
different environments (on-line, E-mail, and WWW) are also specified.
<>
3. Data Structures
This section contains descriptions of the data structures required
for PKI management messages. Section 4 describes constraints on their
values and the sequence of events for each of the various PKI
management operations. Section 5 describes how these may be
encapsulated in various transport mechanisms.
3.1 Overall PKI Message
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection PKIProtection
}
3.1.1. PKI Message Header
All PKI messages require some header information for addressing and
transaction identification. Some of this information will also be
present in a transport-specific envelope; however, if the PKI message
is signed then this information is also protected (i.e. we
make no assumption about secure transport).
Farrell, Adams, Ford [Page 8]
INTERNET-DRAFT June 1996
The following data structure is used to contain this information:
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version1 (0) },
messageType MessageType,
transactionID [1] OCTET STRING OPTIONAL,
-- identifies the transaction, i.e. this will be the same in
-- corresponding request, response and confirmation messages
messageID [2] OCTET STRING OPTIONAL,
-- identifies this message uniquely (if needed)
senderNonce [3] OCTET STRING OPTIONAL,
recipNonce [4] OCTET STRING OPTIONAL,
-- nonces used to provide replay protection, senderNonce
-- is inserted by the creator of this message; recipNonce
-- is a nonce previously inserted in a related message by
-- the intended recipient of this message
messageTime UTCTime OPTIONAL,
-- time of production of this message
sender GeneralName,
-- identifies the sender for addressing purposes
recipient GeneralName,
-- identifies the intended recipient for addressing purposes
protectionAlg AlgorithmIdentifier OPTIONAL,
-- to include the alg. in e.g. signature calculation
freeText CHOICE {
IA5String,
BNPString } OPTIONAL,
-- this may be used to indicate context-specific
-- instructions (this field is intended for human
-- consumption)
}
MessageType ::= INTEGER {
InitReq (0), -- message asking for initialization
InitRep (1), -- response to above
CertReq (2), -- message asking for a cert.
CertRep (3), -- response to above
KeyUpdReq (4), -- msg asking for new cert for pub key
KeyUpdRep (5), -- response to above
KeyRecReq (6), -- msg. asking for key recovery
KeyRecRep (7), -- response to above
RevReq (8), -- message asking for revocation
RevRep (9), -- response to above
CrossCertReq (10), -- message asking for cross-certification
CrossCertRep (11), -- response to above
CAKeyUpdAnn (12), -- announcement of CA key pair update
CertAnn (13), -- announcement of a certificate
Farrell, Adams, Ford [Page 9]
INTERNET-DRAFT June 1996
RevAnn (14), -- announcement of revocation of a cert
CRLAnn (15), -- announcement of CRL
PKIConfirm (16) -- used for confirmation in 3-way protocols
}
The transactionID field within the message header is required so that
the recipient of a response message can correlate this with the
request issued. In the case of an RA there may be many requests
"outstanding" at a given moment. The value of this field should be
unique from the sender's perspective in order to be useful.
<>
3.1.2. PKI Message Body
PKIBody ::= CHOICE { -- message-specific body elements
[0] InitReqContent,
[1] InitRepContent,
[2] CertReqContent,
[3] CertRepContent,
[4] KeyUpdReqContent,
[5] KeyUpdRepContent,
[6] KeyRecReqContent,
[7] KeyRecRepContent,
[8] RevReqContent,
[9] RevRepContent,
[10] CrossCertReqContent,
[11] CrossCertRepContent,
[12] CAKeyUpdAnnContent,
[13] CertAnnContent,
[14] RevAnnContent,
[15] CRLAnnContent,
[16] PKIConfirmContent,
}
3.1.3. PKI Message Protection
Some PKI messages will be protected for integrity. In that case the
following structure is used:
PKIProtection ::= SEQUENCE {
alg AlgorithmIdentifier OPTIONAL,
-- when both this field and the protectionAlg field of the
-- PKIHeader are present, they must be the same
protectionBits BIT STRING
}
Farrell, Adams, Ford [Page 10]
INTERNET-DRAFT June 1996
The input to the calculation of the protectionBits is the DER
encoding of the following data structure:
ProtectedPart ::= SEQUENCE {
PKIHeader,
PKIBody}
Note that this is equivalent to the ASN.1 notation:
PKIProtection ::= SIGNATURE SEQUENCE {
PKIHeader,
PKIBody}
The protocols required for PKI management use this structure
differently, there are four possibilities:
- no protection: e.g. to pass an "out-of-band" CA public key
- symmetric protection: used in some registration schemes
- single signature protection: e.g., when an RA signs a request
- double signature protection: e.g., when both end entity and RA
sign a request
3.1.3.1. Unprotected PKI messages
<>
3.1.3.2. Symmetric protection of PKI messages
<>
3.1.3.3. Single signatures on PKI messages
<>
3.1.3.4. Double signatures on PKI messages
<>
Some PKI messages may be signed twice. In this case the PKIProtection
structure is also used as follows:
pkix-double-sig-alg-id ::= AlgorithmIdentifier -- value TBS
-- just an OID; no parameters
Farrell, Adams, Ford [Page 11]
INTERNET-DRAFT June 1996
The protectionBits field will contain the DER encoding of the
following data structure:
TwoSigProtection ::= SEQUENCE {
firstAlgId [0] AlgorithmIdentifier OPTIONAL,
firstSig BIT STRING,
secondSigner GeneralName,
secondAlgId [1] AlgorithmIdentifier OPTIONAL,
secondSig BIT STRING}
Where secondSig contains the signature of the DER encoding of the
following:
secondSigInput ::= SEQUENCE {
PKIHeader,
PKIBody,
PKIProtection, -- version from 1st signer
GeneralName,
AlgorithmIdentifier OPTIONAL }
3.2 Common Data Structures
Before specifying the specific types which may be placed in a PKIBody
we define some useful data structures which are used in more than one
case.
3.2.1. Requested Certificate Contents
Various PKI management messages require that the originator of the
message indicate some of the fields which are required to be present
in a certificate. The CertTemplate structure allows an end entity
or RA to specify as much as they can about the certificate they
require. ReqCertContent is basically the same as a Certificate but
with all fields optional.
Note that even if the originator completely specifies the contents of
a certificate they require, a CA is free to modify fields within the
certificate actually issued.
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
-- used to ask for a particular syntax version
serial [1] INTEGER OPTIONAL,
-- used to ask for a particular serial number
signingAlg [2] AlgorithmIdentifier OPTIONAL,
-- used to ask the CA to use this alg. for
-- signing the cert
subject [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
Farrell, Adams, Ford [Page 12]
INTERNET-DRAFT June 1996
issuer [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL,
} -- the extensions which the requester would like in the cert.
OptionalValidity ::= SEQUENCE {
notBefore [0] UTCTime OPTIONAL,
notAfter [1] UTCTime OPTIONAL
}
CertTemplates ::= SEQUENCE OF CertTemplate
3.2.2. Encrypted Private Key
Where private keys are sent in PKI messages the following data
structure is used.
EncryptedPrivKey ::= SEQUENCE {
privKey BitsAndAlgs,
-- the private key encrypted
encSymmKey BitsAndAlgs OPTIONAL
-- a symmetric key used to encrypt the private key
}
BitsAndAlgs ::= SEQUENCE {
encKey BIT STRING,
encAlg [0] AlgorithmIdentifier OPTIONAL,
-- algorithm used to encrypt the key
keyAlg [1] AlgorithmIdentifier OPTIONAL
-- algorithm for which the key is intended to be used
}
EncryptedPrivKeys ::= SEQUENCE of EncryptedPrivKey
Use of this data structure requires that the creator and intended
recipient are respectively able to encrypt and decrypt. Typically,
this will mean that the end entity has been issued with a secret key
shared with the generator of the key pair.
If the recipient of the PKIMessage already possesses a private key
usable for decryption, then the encSymmKey field may contain a
session key encrypted using the recipient's public key.
3.2.3. Status codes and Failure Information for PKI messages
All response messages will include some status information. The
following values are defined.
PKIStatus ::= INTEGER {
granted (0),
-- you got exactly what you asked for
grantedWithMods (1),
-- you got something like what you asked for; the
-- requester is responsible for ascertaining the differences
Farrell, Adams, Ford [Page 13]
INTERNET-DRAFT June 1996
rejection (2),
-- you don't get it, more information elsewhere in the
-- message
waiting (3),
-- the request body part has not yet been processed,
-- expect to hear more later
revocationWarning (4)
-- this message contains a warning that a revocation is
-- imminent
revocationNotification (5)
-- notification that a revocation has occurred
}
Responders may use the following syntax to provide more information
about failure cases.
PKIFailureInfo ::= BIT STRING { -- since we can fail in more than
-- one way!
badAlg (0),
badMessageCheck (1)
-- <>
}
StatusInfo ::= SEQUENCE {
status PKIStatus,
failInfo PKIFailureInfo OPTIONAL
}
3.2.4. Certificate Identification
In order to identify particular certificates the following data
structure is used.
CertId ::= SEQUENCE {
issuer GeneralName,
serialNumber INTEGER
}
Furthermore, a list of certificates is identified as follows.
Certs ::= SEQUENCE OF Certificate
3.2.5. Publication Information
<>
In order to allow requesters to indicate where and/or how
certificates should be published, or to allow responders to indicate
where and/or how certificates have been published, the following
syntax is used.
PublicationInfo ::= SEQUENCE OF SEQUENCE {
pubMethod OBJECT IDENTIFIER,
pubDetails OCTET STRING OPTIONAL}
Farrell, Adams, Ford [Page 14]
INTERNET-DRAFT June 1996
3.2.6. "Out-of-band" CA public key
Each CA must be able to publish its current public key via some "out-
of-band" means. While such mechanisms are beyond the scope of this
document, we define data structures which can support such mechanisms.
There are generally two methods available; either the CA directly
publishes its public key and associated attributes, or this
information is available via the Directory (or equivalent) and the CA
publishes a hash of this value to allow verification of its integrity
before use.
OOBCert ::= Certificate
OOBCertHash ::= SEQUENCE {
hashAlg AlgorithmIdentifier OPTIONAL,
certId CertId OPTIONAL,
hashVal BIT STRING}
-- hashVal is calculated over DER encoding of an entire OOBCert
3.3 Operation-Specific Data Structures
3.3.1. Initialization Request
An Initialization request message (InitReq) contains an
InitReqContent data structure which specifies the requested
certificate(s). Typically, SubjectPublicKeyInfo, KeyId, and Validity
are the template fields which may be supplied for each certificate
requested.
InitReqContent ::= SEQUENCE {
referenceNum INTEGER,
protocolEncKey [0] SubjectPublicKeyInfo OPTIONAL,
certTemplates CertTemplates
}
3.3.2. Initialization Response
An Initialization response message (InitRep) contains an
InitRepContent data structure which has for each certificate requested
a StatusInfo field, a subject certificate, and possibly a private key
(encrypted with a session key, which is itself encrypted with the
protocolEncKey). InitRepContent also contains a CA signature
certificate.
InitRepContent ::= SEQUENCE {
caSigCert Certificate,
response SEQUENCE OF CertResponse
}
Farrell, Adams, Ford [Page 15]
INTERNET-DRAFT June 1996
3.3.3. Registration/Certification Request
A Registration/Certification request message (CertReq) contains a
CertReqContent data structure which specifies the requested
certificate.
CertReqContent ::= CertTemplates
3.3.4. Registration/Certification Response
A registration response message (CertRep) contains a CertRepContent
data structure which has a CA public key, a status value and
optionally failure information, a subject certificate, and an
encrypted private key.
CertRepContent ::= SEQUENCE {
caPub [1] OOBCert OPTIONAL,
response SEQUENCE OF CertResponse
}
CertResponse ::= SEQUENCE {
status StatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL,
}
CertifiedKeyPair ::= SEQUENCE {
certificate [1] Certificate OPTIONAL,
privateKey [2] EncryptedPrivKey OPTIONAL
}
Only one of the failInfo (in StatusInfo) and certificate fields should
be present in CertRepResponse (depending on the status). For some
status values (e.g., waiting) neither of the optional fields will be
present.
3.3.5. Key update request content
For key update requests the following syntax is used. Typically,
SubjectPublicKeyInfo, KeyId, and Validity are the template fields
which may be supplied for each key to be updated. As well, an
encryption certificate, or a signature certificate, or both, would
typically be specified in latestCerts.
KeyUpdReqContent ::= SEQUENCE {
endEntityName GeneralName,
latestCerts SEQUENCE OF CertId,
protocolEncKey [1] SubjectPublicKeyInfo OPTIONAL,
certTemplates [2] CertTemplates OPTIONAL
}
Farrell, Adams, Ford [Page 16]
INTERNET-DRAFT June 1996
3.3.6. Key Update response content
For key update responses the syntax used is identical to the
initialization response.
KeyUpdRepContent ::= InitRepContent
3.3.7. Key Recovery Request content
For key recovery requests the syntax used is identical to the
initialization request InitReqContent. Typically,
SubjectPublicKeyInfo and KeyId are the template fields which may be
used to supply a signature public key for which a certificate is
required.
KeyRecReqContent ::= InitReqContent
3.3.8. Key recovery response content
For key recovery responses the following syntax is used. For some
status values (e.g., waiting) none of the optional fields will be
present.
KeyRecRepContent ::= SEQUENCE {
status StatusInfo,
caCerts Certs OPTIONAL,
newSigCert Certificate OPTIONAL,
keyPairHist SEQUENCE OF CertifiedKeyPair OPTIONAL,
}
3.3.9. Revocation Request Content
When requesting revocation of a certificate (or several certificates)
the following data structure is used. The name of the requestor is
present in the PKIHeader structure.
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requestor to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g. for cases in which serialNumber is not available)
revocationReason ReasonFlags,
-- from the DAM, so that CA knows which Dist. point to use
badSinceDate UTCTime OPTIONAL,
-- indicates best knowledge of sender
crlEntryDetails Extensions}
-- requested crlEntryExtensions
3.3.10. Revocation Response Content
The response to the above message. If produced, this is sent to the
requestor of the revocation. (A separate revocation announcement
message may be sent to the subject of the certificate for which
revocation was requested.)
Farrell, Adams, Ford [Page 17]
INTERNET-DRAFT June 1996
RevRepContent ::= SEQUENCE {
status StatusInfo,
revCerts [0] SEQUENCE OF CertId OPTIONAL,
-- identifies the certs for which revocation was requested
crls [1] SEQUENCE OF CertificateList OPTIONAL
-- the resulting CRLs (there may be more than one)
}
3.3.11. Cross certification request content
Cross certification requests use the same syntax as for normal
certification requests.
CrossCertReqContent ::= CertReqContent
3.3.12. Cross certification response content
Cross certification responses use the same syntax as for normal
certification responses.
CrossCertRepContent ::= CertRepContent
3.3.13. CA Key Update Announcement content
When a CA updates its own key pair the following data structure may
be used to announce this event.
CAKeyUpdAnnContent ::= SEQUENCE {
oldWithNew Certificate, -- old pub signed with new priv
newWithOld Certificate, -- new pub signed with old priv
newWithNew Certificate -- new pub signed with new priv
}
3.3.14. Certificate Announcement
This data structure may be used to announce the existence of
certificates.
Note that this structure (and the CertAnn message itself) is intended
to be used for those cases (if any) where there is no pre-existing
method for publication of certificates; it is not intended to be used
where, for example, X.500 is the method for publication of
certificates.
CertAnnContent ::= Certificate
Farrell, Adams, Ford [Page 18]
INTERNET-DRAFT June 1996
3.3.15. Revocation Announcement
When a CA has revoked, or is about to revoke, a particular certificate
it may issue an announcement of this (possibly upcoming) event.
RevAnnContent ::= SEQUENCE {
status PKIStatus,
certId CertId,
revocationTime UTCTime,
badSinceDate UTCTime,
crlEntryDetails [0] Extensions OPTIONAL,
-- crlEntryExtensions (e.g. reason)
crlDetails [1] Extensions OPTIONAL,
-- crlExtensions (e.g. crl number)
}
A CA may use such an announcement to warn (or notify) a subject that
its certificate is about to be (or has been) revoked. This would
typically be used where the request for revocation did not come from
the subject concerned.
3.3.16. CRL Announcement
When a CA issues a new CRL (or set of CRLs) the following data
structure may be used to announce this event.
CRLAnnContent ::= SEQUENCE OF CertificateList
3.3.17. PKI Confirmation content
This data structure is used in three-way protocols as the final
PKIMessage. Its content is the same in all cases - actually there is
no content since the PKIHeader carries all the required information.
PKIConfirmContent ::= NULL
Farrell, Adams, Ford [Page 19]
INTERNET-DRAFT June 1996
4. PKI Management Operations
The certificate management protocol exchanges defined in this section
support management communications between client systems, each of
which supports one or more users, and CAs. In addition, one
management protocol exchange is defined for use between two CAs, for
the purpose of establishing cross-certificates. Each exchange is
defined in terms of a sequence of messages between the two systems
concerned. This section defines the contents of the messages
exchanged.
The protocols for conveying these exchanges in different environments
(on-line, E-mail, and WWW) are specified in Section 5.
The protocol exchanges defined in this document are as follows.
1. Registration/Certification
One-Step Registration/Certification
User Initialization/Certification
2. End-Entity Key Pair Update
Update for Client-Generated Key Pair
Update for Centrally-Generated Key Pair
Centrally-Initiated Key Pair Update
3. Encryption Key Pair Recovery
4. Revocation Request
5. Cross-Certification
6. CA Key Pair Update
7. Certificate Publication
8. Revocation Publication
9. CRL Publication
10. Certificate Update
11. Cross-Certificate Update
The following notes apply to the protocol exchange descriptions:
-In exchanges between a client system and a CA, the protocol
exchange is initiated by the client system. The one exception to
this is the Centrally-Initiated Key Pair Update exchange.
-To provide an upgrade path, a protocol version indicator is always
included in the first message of an exchange.
-A message type indicator is included in the protected part of all
messages.
-All messages include an optional transaction identifier which is
used to assist correlation of request and response messages for
one transaction. This identifier is generated by the initiator of
the exchange and will typically include the initiator's name plus
a transaction sequence number.
-The initial message from the client to the CA may optionally
contain the client system time. This is used to facilitate the
correction of client time problems by central administrators.
-Responses from CA to client include the CA system time. The
client can use this time to check that its own system time is
within a reasonable range.
-Random numbers are used in some of the protocols to prevent replay
of the exchanges.
Farrell, Adams, Ford [Page 20]
INTERNET-DRAFT June 1996
-Responses can be aborted at any time. An enumerated error code is
sent from the aborting end and can be decoded into a user readable
error string at the other end. Error codes are not specified in
this version of this document.
-Items in square brackets [] are optional.
-In every instance in which a public key is transferred, it is
transferred in the form of X.509 subjectPublicKeyInfo, including
algorithm identifier and (optional) parameters.
-When a new key pair is generated by a client, a key identifier may
optionally be sent to the CA along with the public key for
inclusion in the certificate. However, the CA may override this
value with a key identifier of its own. If the client is
concerned about the key identifier value used, it should check the
new certificate.
-Where this description refers to an encryption key pair, this
could be a key pair for RSA key transport or could be key pair for
key establishment using, for example, a Diffie-Hellman based
algorithm.
4.1 Registration/Certification
There are various approaches to this operation.
4.1.1. One-Step Registration/Certification
For simple end entities this operation involves an out-of-band (or
indeed implicit) request to an RA or CA. If no RA is involved then
the CA in question simply prepares a PSE for the end entity. When an
RA is involved the RA creates a certification request (CertReq)
message for the end entity in question and sends this to the
appropriate CA.
When an RA is involved the steps required are as follows.
1.The RA gathers the information required for the certification
request.
2.The RA creates the certification request message (CertReq);
at this point the RA may provide the end entity with its PSE if
the PSE doesn't need to contain the end entity's own
certificate(s).
3.The CertReq message is transported to the CA.
4.The CA processes the CertReq; this results in the creation of a
certification response (CertRep) message.
5.The CertRep message is transported to the RA.
6.The RA processes the CertRep. Depending on its content some
looping may be required; that is, the RA may have to await further
responses or generate a new CertReq for this end entity <>. Once
the required certificates have been acquired the RA can prepare the
end entity's PSE (assuming that the PSE contains the end entity's
certificates).
7.The end entity receives the PSE and if necessary verifies that the
CA public key contained therein is correct.
Farrell, Adams, Ford [Page 21]
INTERNET-DRAFT June 1996
We impose the following constraints on the certification request
message.
1.The RA must provide the protectionAlg field of the PKIHeader and
must protect the CertReq message. The name in the sender field of
the PKIHeader must be usable when verifying the protection.
2.The messageType field of the PKIMessage must contain the CertReq
value.
3.The CertReqContent supplied must contain values for the following
fields (i.e. these are mandated for this operation):
- version
- subject
- validity.
4.If the RA does not provide the subjectPublicKeyInfo field this
indicates that the RA is requesting a centrally-generated key pair
and that the CA return the end entity's private key encrypted
(using an EncPrivKey structure) for the end-entity or for the RA
according to policy (and the type of PSE in use).
If the RA does provide the subjectPublicKeyInfo field this does
not mean that the RA need have generated the end entity's key
pair, (which is an option) but simply that the RA has a "good"
copy of the end entity's public key.
All conforming CA implementations must be able to process any
certification request received. Some CA implementations may however,
only ever be able to reject requests which contain specific options
(e.g., some CA implementations may not allow RAs to request a
particular serial number for a certificate).
4.1.2. Initialization
4.1.2.1. End-Entity-Generated Encryption Key Pair
4.1.2.1.1. Overview of Exchange
This protocol exchange is used to support client initialization,
including certificate issuance, for one user, with provision for
simultaneously establishing and certifying separate key pairs for
digital signature and encryption (or encryption key exchange)
purposes. Both key pairs are generated by the client and no private
key is exposed to the CA. Generation and certification of the
encryption key pair is optional.
Prior to conducting this exchange, the user must have registered with
the CA, using either a face-to-face registration exchange or some
other means.
Following registration, the CA creates a secret data item, called an
authorization code, and transfers this data item by out-of-band
means to the user. The authorization code is used to establish
authentication and integrity protection of the user
initialization/certification on-line exchange. This is done by
generating a symmetric key based on the authorization code and using
this symmetric key for generating Message Authentication Codes (MACs)
on all exchanges between client and CA.
Farrell, Adams, Ford [Page 22]
INTERNET-DRAFT June 1996
In the first two messages exchanged, the client sends its user
signature public key (and, optionally, a client-generated encryption
public key) to the CA and the CA returns the currently valid CA
certificate(s). This exchange of public keys allows the client and CA
to authenticate each other.
4.1.2.1.2. Detailed Description
The user receives a reference number and a secret machine-generated
authorization code from the CA administrator. Both pieces of
information are transferred to the user in a secure manner which
preserves their integrity and confidentiality. The reference number
is used to uniquely identify the client at the CA and the
authorization code is used to secure the exchange in terms of
integrity. The reference number is used instead of a DN to uniquely
identify the client because a DN may be lengthy and difficult for a
user to manually type without error.
After the reference number and authorization code have been entered
by the user, the client generates:
- a client random number,
- (if a new user signature key pair is required) a new user
signature key pair,
- (if a new client-generated encryption key pair is required) a
new encryption key pair.
The client securely stores locally any new signature private key
and/or client-generated encryption private key. The client then
sends the message InitReq to the CA. The entire structure is
protected from modification with a MAC based on the authorization
code.
Upon receipt of the InitReq message, if the CA recognizes the
reference number and if the protocol version is valid, it saves the
client random number, generates its own random number (CA random
number), and validates the MAC. Then for the user encryption public
key, it creates:
- a new certificate for the user's digital signature public key,
- (if a new client-generated encryption key pair is required) a
new certificate for the user's encryption public key.
The CA responds to the client with the message InitRep. The entire
structure is protected from modification with a MAC based on the
authorization code.
Upon receipt of the InitRep message, the client checks that its own
system time is sufficiently close to the CA system time, checks the
client random number, and validates the MAC. The client then
securely stores the new certificates and acknowledges the transaction
by sending back the message PKIConfirm. The fields in this message
are protected from modification with a MAC based on the authorization
code.
Farrell, Adams, Ford [Page 23]
INTERNET-DRAFT June 1996
Upon receipt of the PKIConfirm message, the CA checks the random
numbers and validates the MAC. If no errors occur, the CA archives
the new user public-key certificate(s).
4.1.2.2. Centrally-Generated Encryption Key Pair
4.1.2.2.1. Overview of Exchange
This protocol exchange is used to support client initialization,
including certificate issuance, for one user, with provision for
simultaneously establishing and certifying separate key pairs for
digital signature and encryption (or encryption key exchange)
purposes. The digital signature key pair is generated by the client.
Optionally, a new encryption key pair is generated by (and,
optionally, backed up by) a central facility associated with the CA.
Prior to conducting this exchange, the user must have registered with
the CA, using either a face-to-face registration exchange or some
other means.
Following registration, the CA creates a secret data item, called an
authorization code, and transfers this data item by out-of-band
means to the user. The authorization code is used to establish
authentication and integrity protection of the user
initialization/certification on-line exchange. This is done by
generating a symmetric key based on the authorization code and using
this symmetric key for generating Message Authentication Codes (MACs)
on all exchanges between client and CA.
In the first two messages exchanged, the client sends its user
signature public key to the CA and the CA returns the currently valid
CA certificate(s). This exchange of public keys allows the client and
CA to authenticate each other.
If a centrally-generated encryption key pair is to be established,
the private key of the newly generated key pair is sent from the CA
to the client. The client first generates a protocol encryption key
pair and sends the public protocol encryption key to the CA. The CA
creates a random symmetric key called the session key and encrypts
the user encryption private key with it and then encrypts the session
key with the public protocol encryption key it received from the
client. The CA sends the encrypted user encryption private key and
encrypted session key back to the client. The client uses its private
protocol decryption key to decrypt the session key and then uses the
session key to decrypt the encryption private key. The protocol
encryption key pair and session key are discarded after the exchange.
Farrell, Adams, Ford [Page 24]
INTERNET-DRAFT June 1996
4.1.2.2.2. Detailed Description
The user receives a reference number and a secret machine-generated
authorization code from the CA administrator. Both pieces of
information are transferred to the user in a secure manner which
preserves their integrity and confidentiality. The reference number
is used to uniquely identify the client at the CA and the
authorization code is used to secure the exchange integrity-wise. The
reference number is used instead of a DN to uniquely identify the
client because a DN may be lengthy and difficult for a user to
manually type without error.
After the reference number and authorization code have been entered
by the user, the client generates:
- a client random number,
- (if a new user signature key pair is required) a new user
signature key pair,
- (if a new centrally-generated encryption key pair is required)
a protocol encryption key pair.
The client securely stores locally any new signature private key
and/or client-generated encryption private key. The client then
sends the message InitReq to the CA. The entire structure is
protected from modification with a MAC based on the authorization
code.
Upon receipt of the InitReq message, if the CA recognizes the
reference number and if the protocol version is valid, it saves the
client random number, generates its own random number (CA random
number), and validates the MAC. It then creates:
- a new certificate for the user's digital signature public key,
- (if a new centrally-generated encryption key pair is required)
a session key, a new user encryption key pair, and a new
certificate for the user encryption public key.
The CA responds to the client with the message InitRep. If a new
centrally-generated encryption key pair is being generated, the user
encryption private key is encrypted using the session key and the
session key is encrypted with the protocol encryption public key. The
entire structure is protected from modification with a MAC based on
the authorization code.
Upon receipt of the InitRep structure, the client checks that its own
system time is sufficiently close to the CA system time, checks the
client random number, and validates the MAC. If a new centrally-
generated encryption key pair is included, the client decrypts the
encryption private key. The client then securely stores the new
certificates and encryption private key (if present) and acknowledges
the transaction by sending back the message PKIConfirm. The fields in
this message are protected from modification with a MAC based on the
authorization code.
Farrell, Adams, Ford [Page 25]
INTERNET-DRAFT June 1996
Upon receipt of the PKIConfirm message, the CA checks the random
numbers and validates the MAC. If no errors occur, the CA archives
the new user public-key certificate(s) and (if there is a new
centrally-generated encryption key pair and key recovery is to be
supported) the encryption private key.
4.2 End Entity Key Pair Update
4.2.1. End-Entity-Generated Key Pair(s)
4.2.1.1. Overview of Exchange
This exchange is used to update the signature key pair and/or client-
generated encryption key pair of a user, (e.g., as a result of
routine cryptoperiod expiry).
A user must have a valid signature key pair in order to do this
exchange. It is up to the client to determine when a new signature
key pair should be generated; this has to be done prior to the
expiration of its signature public-key certificate.
A key pair update request from a client is digitally signed using the
original user signature private key, this signature being verifiable
using an existing signature certificate. If the key pair update is
for a new user digital signature key, then the client signs the
request message once more (including the first signature), this time
using the new signature private key. The reason for this second
signature is to prove to the CA that the client possesses both the
new and old private keys.
The request is verified at the CA by using the matching user
signature public key. A protocol signature key pair is used to
authenticate messages from the CA to the client. CA responses are
signed with the protocol signature private key.
A CA response is validated at the client by using a protocol
signature public-key certificate which is included in the CA
response. The protocol signature public-key certificate can be
validated by using the CA certificate stored at the client. A new
user initialization (as in Section 4.1) or key pair recovery (as in
Section 4.5) must be done if the user signature key pair becomes
invalid.
Farrell, Adams, Ford [Page 26]
INTERNET-DRAFT June 1996
In some client system implementations, local key materials are stored
in an encrypted key data disk file. A user may have several copies of
this key data file on different computers. It is possible that a key
update could occur and the user could forget to copy the updated key
data file to all the computers they use. To help keep the client
using the latest keys, the client sends the CA the serial number of
the latest user signature public-key certificate it has in the key
update request. Serial numbers are sent so that the CA can check if
the client has the latest key pair. If the client does not have the
latest signature private key and the signature public-key certificate
serial number is equal to that of a previous certificate, the CA
sends back an error code which indicates that the client has an old
version of the key data file. After this, the client can either find
the latest key data file or, if that fails, initiate a key recovery
exchange.
4.2.1.2. Detailed Description
The client initiates the key update exchange by creating a new
signature and/or encryption key pair and generating a random number
(client random number). The client then sends the message
KeyUpdReq to the CA . The fields in this message are protected from
modification and authenticated by a digital signature using the pre-
existing user signature private key. If the update includes a new
signature key pair, the result is additionally signed using the new
user signature private key.
Upon receipt of the KeyUpdReq message, the CA checks the protocol
version, checks the serial number, saves the client random number,
generates its own random number (CA random number) and verifies the
signature using the previous user verification key which is archived
at the CA. If a user digital signature key pair is being updated, the
CA also checks the second signature. It then generates new user
signature and/or encryption public-key certificate(s). The CA
responds with the message KeyUpdRep. The fields in this message are
protected from modification and authenticated by a digital signature
using the CA protocol signature private key.
Upon receipt of the KeyUpdReq message, the client verifies the
digital signature using the protocol verification key contained in
the protocol signature public-key certificate, checks that its own
system time is close to the CA system time, and checks the received
client random number. The client then securely stores locally the new
user public-key certificate(s). It responds with the message
PKIConfirm. The fields in this message are protected from
modification and authenticated by a digital signature using the pre-
existing user signature private key.
Upon receipt of the PKIConfirm message, the CA checks that the client
and CA random numbers are the same as the ones initially generated,
and verifies the received signature using the previous user signature
public key which is archived at the CA. The CA then archives the new
user public-key certificate(s) and updates its data stores to reflect
the new status of the user.
Farrell, Adams, Ford [Page 27]
INTERNET-DRAFT June 1996
4.2.2. Centrally-Generated Encryption Key Pair
4.2.2.1. Overview of Exchange
This exchange is used to update the encryption key pair of a user,
under the assumption that encryption key pairs are generated (and,
optionally, backed up) centrally. A user must have a valid signature
key pair in order to do this exchange. It is up to the client to
determine when a new encryption key pair should be generated; this
must be done some time before the expiration date in its encryption
public-key certificate.
4.2.2.2. Detailed Description
The client initiates the exchange by generating a random number
(client random number) and a protocol encryption key pair. The client
then sends the CA the message KeyUpdReq. The fields in this message
are protected from modification and authenticated by a digital
signature using the latest user signature private key.
Upon receipt of the KeyUpdReq message, the CA checks the protocol
version, checks the serial numbers, saves the client random number,
generates its own random number (CA random number), generates a
session key, and verifies the received signature using the latest
user signature public key which is archived at the CA. It then
generates a new end-user encryption key pair and encryption public-
key certificate for the user. In the case where the encryption public-
key certificate serial number is the second latest, the CA does not
generate any keys and uses the latest encryption public-key
certificate and encryption private key that it has. The CA responds
with the message KeyUpdRep. In this message, the new or latest
encryption private key is encrypted with the session key and the
session key is encrypted with the protocol encryption key. The fields
in this message are protected from modification and authenticated by
a digital signature using the protocol signature private key.
Upon receipt of the KeyUpdRep message, the client verifies the
digital signature using the protocol signature public-key
certificate, makes sure its own system time is close to the CA system
time, and checks the received client random number. The client then
decrypts the new or latest encryption private key and securely stores
locally the new or latest user encryption public-key certificate and
encryption private key. It responds with the message PKIConfirm. The
fields in this message are protected from modification and
authenticated by a digital signature using the latest user signature
private key.
Upon receipt of the PKIConfirm message, the CA checks that the client
and CA random numbers are correct and verifies the signature using
the latest user signature public key which is archived at the CA. If
no errors occur, the CA archives the new user encryption public-key
certificate and encryption private key, and updates its data stores
to reflect the new status of the user.
Farrell, Adams, Ford [Page 28]
INTERNET-DRAFT June 1996
4.2.3. Centrally-Initiated Key Pair Update
4.2.3.1. Overview of Exchange
This exchange is used to update the encryption key pair of an user,
under the assumption that encryption key pairs are generated (and,
optionally, backed up) centrally. This exchange differs from the
preceding exchange (Key Pair Update for Centrally-Generated
Encryption Key Pair) in that the exchange is initiated by the CA
rather than the client.
4.2.3.2. Detailed Description
<< To be supplied >>
4.3 Encryption Key Pair Recovery
4.3.1 Overview of Exchange
This protocol exchange is used to support recovery in the event that
a client no longer has a valid signature key pair (due to expiration
or revocation), or client system key materials have been lost (e.g.,
as a result of a forgotten user password). This exchange assumes a
system in which an encryption key pair has been centrally generated
and backed up (by a central system associated with a CA).
This exchange is very similar to the exchange for User
Initialization/Certification with Centrally-Generated Encryption Key
Pair. The client and CA start without a way to trust one another;
that is, they have no reliable shared key pairs.
4.3.2 Detailed Description
The user must first receive, by out-of-band means, a reference number
and a secret machine-generated authorization code from the CA
administrator. The on-line exchange then consists of a sequence of
KeyRecReq, KeyRecRep and PKIConfirm, which are the same as the
exchange in 4.1.2 except for two differences. First, the CA does not
generate (or archive) a new encryption key pair and encryption public-
key certificate for the user. Second, the user's entire encryption
key history (list of encryption public-key certificates and matching
encryption private keys) are sent back to the client with KeyRecRep.
Farrell, Adams, Ford [Page 29]
INTERNET-DRAFT June 1996
4.4 Revocation Request
4.4.1 Overview of Exchange
This protocol exchange is used to support a revocation request from a
user or other authorized party.
4.4.2 Detailed Description
<< To be supplied >>
4.5 Cross-Certification
The initiating CA is the CA which will become the subject of the
cross-certificate, the responding CA will become the issuer of the
cross-certificate.
The initiating CA must be "up and running" before initiating the
cross-certification operation.
As with registration/certification there are a few possibilities
here.
4.5.1. One-way request-response scheme:
The cross-certification scheme is essentially a one way operation,
that is, when successful, this operation results in the creation of
one new cross-certificate. If the requirement is that cross-
certificates be created in "both directions" then each CA in turn
must initiate a cross-certification operation (or use another
scheme).
The followings steps occur:
1.The initiating CA gathers the information required for the cross
certification request
2.The initiating CA creates the cross-certification request message
(CrossCertReq);
3.The CrossCertReq message is transported to the responding CA
4.The responding CA processes the CrossCertReq; this results in the
creation of a cross-certification response (CrossCertRep) message.
5.The CrossCertRep message is transported to the initiating CA
6.The initiating CA processes the CrossCertRep; depending on its
content some looping may be required, that is, the initiating CA
may have to await further responses or generate a new CrossCertReq
for this end entity <>
Notes:
1.The CrossCertReq should contain a "complete" certification
request, that is, all fields (including e.g. a BasicConstraints
extension) should be specified by the initiating CA.
2.The CrossCertRep message should contain the OOBcert of the
responding CA - the initiating CA should then verify this via the
"out-of-band" mechanism.
Farrell, Adams, Ford [Page 30]
INTERNET-DRAFT June 1996
4.5.2. Two-way request-response scheme:
4.5.2.1. Overview of Exchange
This cross certification exchange allows two CAs to simultaneously
certify each other. This means that each CA will create a certificate
that contains the CA verification key of the other CA.
Cross certification is initiated at one CA known as the responder.
The CA administrator for the responder identifies the CA it wants to
cross certify and the responder CA equipment generates an
authorization code. The responder CA administrator passes this
authorization code by out-of-band means to the requester CA
administrator. The requester CA administrator enters the
authorization code at the requester CA in order to initiate the on-
line exchange.
The authorization code is used for authentication and integrity
purposes. This is done by generating a symmetric key based on the
authorization code and using the symmetric key for generating Message
Authentication Codes (MACs) on all messages exchanged.
Serial numbers and protocol version are used in the same manner as in
the above CA-client exchanges.
4.5.2.2. Detailed Description
The requester CA initiates the exchange by generating a random number
(requester random number). The requester CA then sends the responder
CA the message CrossReq. The fields in this message are protected
from modification with a MAC based on the authorization code.
Upon receipt of the CrossReq message, the responder CA checks the
protocol version, saves the requester random number, generates its
own random number (responder random number) and validates the MAC. It
then generates and archives a new requester certificate which
contains the requester CA public key and is signed with the responder
CA signature private key. The responder CA responds with the message
CrossRep. The fields in this message are protected from modification
with a MAC based on the authorization code.
Upon receipt of the CrossRep message, the requester CA checks that
its own system time is close to the responder CA system time, checks
the received random numbers and validates the MAC. It then generates
and archives a new responder certificate which contains the responder
CA public key and is signed by the requester CA signature private
key. The requester CA responds with the message PKIConfirm. The
fields in this message are protected from modification with a MAC
based on the authorization code.
Upon receipt of the PKIConfirm message, the responder CA checks the
random numbers, archives the responder certificate, and validates the
MAC. It writes both the request and responder certificates to the
Farrell, Adams, Ford [Page 31]
INTERNET-DRAFT June 1996
Directory. It then responds with its own PKIConfirm message. The
fields in this message are protected from modification with a MAC
based on the authorization code.
Upon receipt of the PKIConfirm message, the requester CA checks the
random numbers and validates the MAC. The requester CA writes both
the requester and responder certificates to the Directory.
4.6 CA Key Pair Update
The basis of the procedure described here is that the CA protects its
new public key using its previous private key and vice versa. Thus
when a CA updates its key pair it must generate two new cACertificate
attribute values if certificates are made available using an X.500
directory.
When a CA changes its key pair those entities who have acquired the
old CA public key via "out-of-band" means are most affected. It is
these end entities who will need access to the new CA public key
protected with the old CA private key. However, they will only require
this for a limited period (until they have acquired the new CA public
key via the "out-of-band" mechanism). This will typically be easily
achieved when these end entity's certificates expire.
The data structure used to protect the new and old CA public keys is
a standard certificate (which may also contain extensions). There are
no new data structures required.
Notes:
1.This scheme does not make use of any of the X.509 v3
extensions as it should be able to work even for version 1
certificates. The presence of the KeyIdentifier extension would
make for efficiency improvements.
2.While the scheme could be generalized to cover cases where
the CA updates its key pair more than once during the validity
period of one of its end entity's certificates, this generalization
seems of dubious value. This means that the validity period of a CA
key pair must be greater than the validity period of any
certificate issued by that CA using that key pair.
3.This scheme forces end entities to acquire the new CA public
key on the expiry of the last certificate they owned which was
signed with the old CA private key (via the "out-of-band" means).
Certificate and/or key update operations occurring at other times
do not necessarily require this (depending on the end entity's
equipment).
Farrell, Adams, Ford [Page 32]
INTERNET-DRAFT June 1996
4.6.1. CA Operator actions
To change the key of the CA, the CA operator does the following:
1.Generate a new key pair.
2.Create a certificate containing the old CA public key
signed with the new private key (the "old with new" certificate).
3.Create a certificate containing the new CA public key
signed with the old private key (the "new with old" certificate).
4.Create a certificate containing the new CA public key
signed with the new private key (the "new with new" certificate).
5.Publish these new certificates via the directory and/or
other means. (A CAKeyUpdAnn message.)
6.Export the new CA public key so that end entities may
acquire it using the "out-of-band" mechanism.
The old CA private key is then no longer required. The old CA public
key will however remain in use for some time. The time when the old
CA public key is no longer required (other than for non-repudiation)
will be when all end entities of this CA have acquired the new CA
public key via "out-of-band" means.
The "old with new" certificate should have a validity period starting
at the generation time of the old key pair and ending at the time at
which the CA will next update its key pair.
The "new with old" certificate should have a validity period starting
at the generation time of the new key pair and ending at the time by
which all end entities of this CA will securely possess the new CA
public key.
The "new with new" certificate should have a validity period starting
at the generation time of the new key pair and ending at the time at
which the CA will next update its key pair.
<>
4.6.2. Verifying Certificates.
<>
Normally when verifying a signature the verifier simply(!) verifies
the certificate containing the public key of the signer. However,
once a CA is allowed to update its key there are a range of new
possibilities. These are shown in the table below.
Farrell, Adams, Ford [Page 33]
INTERNET-DRAFT June 1996
Directory contains NEW Directory contains only OLD
and OLD public keys public key (due to e.g.
delay in publication)
PSE PSE Contains PSE Contains PSE Contains
Contains OLD public NEW public OLD public
NEW public key key key
key
Signer's Case 1: Case 3: Case 5: Case 7:
certifica This is In this case Although the In this case
te is the the verifier CA operator the CA
protected standard must access has not operator has
using NEW case where the updated the not updated
public the directory in directory the the directory
key verifier order to get verifier can and so the
can the value of verify the verification
directly the NEW certificate will FAIL
verify the public key directly -
certificat this is thus
e without the same as
using the case 1.
directory
Signer's Case 2: Case 4: Case 6: Case 8:
certifica In this In this case The verifier Although the
te is case the the verifier thinks this CA operator
protected verifier can directly is the has not
using OLD must verify the situation of updated the
public access the certificate case 2 and directory the
key directory without will access verifier can
in order using the the verify the
to get the directory directory, certificate
value of however the directly -
the OLD verification this is thus
public key will FAIL the same as
case 4.
4.6.2.1. Verification in cases 1, 4, 5 and 8.
In these cases the verifier has a local copy of the CA public key
which can be used to verify the certificate directly. This is the
same as the situation where no key change has ever occurred.
Note that case 8 may arise between the time when the CA operator has
generated the new key pair and the time when the CA operator stores
the updated attributes in the directory. Case 5 can only arise if the
CA operator has issued both the signer's and verifier's certificates
during this "gap" (the CA operator should avoid this as it leads to
the failure cases described below).
Farrell, Adams, Ford [Page 34]
INTERNET-DRAFT June 1996
4.6.2.2. Verification in case 2.
In case 2 the verifier must get access to the old public key of the
CA. The verifier does the following:
1.Lookup the CACertificate attribute in the directory and
pick the appropriate value (based on validity periods)
2.Verify that this is correct using the new CA key (which
the verifier has locally).
3.If correct then check the signer's certificate using the
old CA key.
Case 2 will arise when the CA operator has issued the signer's
certificate, then changed key and then issued the verifier's
certificate, so it is quite a typical case.
4.6.2.3. Verification in case 3.
In case 3 the verifier must get access to the new public key of the
CA. The verifier does the following:
1.Lookup the CACertificate attribute in the directory and
pick the appropriate value (based on validity periods).
2.Verify that this is correct using the old CA key (which
the verifier has stored locally).
3.If correct then check the signer's certificate using
the new CA key.
Case 3 will arise when the CA operator has issued the verifier's
certificate, then changed key and then issued the signer's
certificate, so it is also quite a typical case.
4.6.2.4. Failure of verification in case 6.
In this case the CA has issued the verifier's PSE containing the new
key without updating the directory attributes. This means that the
verifier has no means to get a trustworthy version of the CA's old
key and so verification fails.
Note that the failure is the CA operator's fault.
4.6.2.5. Failure of verification in case 7.
In this case the CA has issued the signer's certificate protected
with the new key without updating the directory attributes. This
means that the verifier has no means to get a trustworthy version of
the CA's new key and so verification fails.
Note that the failure is again the CA operator's fault.
Farrell, Adams, Ford [Page 35]
INTERNET-DRAFT June 1996
4.6.3. Revocation - Change of CA key
As we saw above the verification of a certificate becomes more
complex once the CA is allowed to change its key. This is also true
for revocation checks as the CA may have signed the CRL using a newer
private key than the one that is within the user's PSE.
The analysis of the alternatives is as for certificate verification.
4.6.4. Example of CA key update
The following example should make the scheme clearer:
1.A CA is established on 1-Jan-1997, its key pair will be used
for three years (until 31-Dec-1999, party-time).
2.Alice gets a new certificate valid for one year starting 21-
Dec-1999 and acquires the CA public key via the appropriate out of
band means.
3.Alice's is the last certificate created by the CA before the
CA key update and is the one which will expire latest.
4.The CA generates its new key pair on 31-Dec-1999 and produces
the two certificates. The "old-with-new" certificate contains a
validity period from 1-Jan-1997 to 31-Dec-2000. The "new-with-old"
certificate contains a validity period from 1-Jan-2000 to 31-Dec-
2000. The CA operator deletes the old private key.
5.Bob gets certified (again for a year) on 10-Jan-2000. Bob
also acquires the new CA public key via the appropriate "out-of-
band" means.
6.On 11-Jan-2000 Alice sends a signed message to Bob. Bob's
verification is as described in case 2 above.
7.Bob replies with a signed message, Alice's verification
procedure is as given in case 3 above.
8.On 20-Dec-2000 Alice gets a new certificate and acquires the
new CA public key via the "out-of-band" means.
9.At midnight on 31-Dec-2000 the CA operator can delete the
"new-with-old" certificate from the directory (or wherever else).
Farrell, Adams, Ford [Page 36]
INTERNET-DRAFT June 1996
These events are shown in the time-line diagram below.
1996 1997 1998 1999 2000 2001 year
----------+---------------------------+-+-+----+-+----->>
| | | | | |
| | | | | |
| | | | | +-- "new-with-old"
| | | | | deleted
| | | | |
| | | | +-- Alice updated
| | | |
| | | +-- Bob certified
| | |
| | +-- CA key update
| |
| +-- Alice certified
+-- CA established
"old-with-new" validity:
|---------------------------------------------->>>>>>
"new-with-old" validity:
|-------|
"new-with-new" validity:
|--------------->>>>>>
4.7 Certificate Publication
<>
4.8 Revocation Publication
<>
This is the announcement of a specific revocation (which occurred as a
result of a successful revocation request/response exchange), as
opposed to the publication of an actual CRL.
4.9 CRL Publication
<>
4.10 Certificate Update
<>
4.11 Cross-Certificate Update
<>
Farrell, Adams, Ford [Page 37]
INTERNET-DRAFT June 1996
5. Transports
5.1 On-line Management Protocol
<< To be supplied. This subsection will specify a means for
conveying ASN.1-encoded messages for the protocol exchanges described
in Section 4 over a TCP connection. >>
5.2 Management Protocol via E-mail
<< To be supplied. This subsection will specify a means for
conveying ASN.1-encoded messages for the protocol exchanges described
in Section 4 via Internet mail. >>
5.3 Management Protocol via HTTP
<< To be supplied. This subsection will specify a means for
conveying ASN.1-encoded messages for the protocol exchanges described
in Section 4 over WWW browser-server links, employing HTTP or related
WWW protocols. >>
6. Samples
The following samples will be further elaborated in later drafts
(which will include encodings for the messages, etc.) For now we just
present them as walkthroughs.
The overall scenario is as follows: A CA is established and an RA is
certified. The RA gets a "simple" end entity certified (which is
actually a http daemon) and does a few operations involving this end
entity. A "sophisticated" end entity gets itself certified by a
second CA. The first CA asks to be cross-certified by the second CA.
The second CA updates its key pair.
We will use the following names:
first CA cn=theCA;o=small;c=ie
RA cn=theRA;o=sse;c=ie
"simple" end entity cn=httpd;o=sse;c=ie
second CA cn=caTWO;o=bnr;c=ca
"sophisticated" end entity cn=sophisticated;o=bnr;c=ca
We will just use the commonName components of the above names in the
text below.
Farrell, Adams, Ford [Page 38]
INTERNET-DRAFT June 1996
6.1 First CA established
theCA has the following characteristics:
- it uses RSA and MD5 for its own key pair
- it has the following contact points available:
theCA@small.ie for mail
http://www.small.ie/theCA for http
ftp://ftp.small.ie/pub/theCA for ftp
cacontact.theCA.small.ie for TCP/IP
cn=theCA;o=small;c=ie for X.500
- its key pair will be valid for two years
- it is established on Jan. 1st 1997
The following (protocol visible) events occur:
- theCA generates its initial key pair and publishes this in various
ways
- theCA publishes its initial CRL is various ways
6.2 RA Certification
theRA has the following characteristics:
- it uses RSA and MD5 for its own key pair
- it has an email address of: theRA@sse.ie
The following events occur
- theRA generates its key pair and submits request to theCA
- theCA rejects this initial request (public key generated is too
short)
- theRA submits a new request
- theCA accepts request and issues response including certificate
(but with reduced validity period since theCA is now in a bad
mood:-)
- theRA publishes its certificate
6.3 "simple" End entity
simple has the following characteristics:
- it only needs a key pair for signing (i.e. no encryption)
- it is an http daemon
Farrell, Adams, Ford [Page 39]
INTERNET-DRAFT June 1996
The following events occur:
- theRA generates key pair; sends request to theCA on behalf of httpd
- theRA forwards certification information to httpd
- theRA publishes certificate on behalf of httpd
- httpd (i.e., its administrator) imports certification information
- theRA issues certificate update request to theCA
- theCA sends response to theRA including new certificate
- theRA publishes new certificate
- theRA generates new key pair for httpd and issues request for key
update to theCA
- theCA accepts request and issues response to theRA including cert.
- theRA publishes certificate on behalf of httpd
- theRA forwards certification information to httpd
- theRA asks for httpd's certificate to be revoked
- theCA revokes httpd's certificate and publishes the new CRL
6.4 The "sophisticated" end entity
sophisticated has the following characteristics:
- it deals directly with caTWO
- it uses DSA with SHA-1
The following events occur:
- end entity receives init. data (containing CA name and public key)
- end entity generates key pair and submits request to CA
- CA accepts request and issues response to end entity (not
including certificate)
- CA publishes certificate on behalf of end entity
- end entity imports CA response
6.5 Cross-certification
In order to allow sophisticated to use httpd theCA must be certified
by caTWO.
The following events occur:
- theCA issues a request for cross-certification to caTWO
- caTWO accepts this request and issues a cross-certificate (but
with more restrictions than theCA had asked for)
- theCA publishes the cross-certificate
- theCA asks for the cross-certificate to be updated
- caTWO issues the new cross-certificate
- theCA publishes the new cross-certificate
6.6 CA Key Update
Eventually (in late 1998) theCA decides to update its key pair.
The following events occur:
- theCA generates a new key pair
- theCA publishes its new key (and collateral data structures)
Farrell, Adams, Ford [Page 40]
INTERNET-DRAFT June 1996
7. Security Considerations
This entire memo is about security mechanisms.
Authors' Addresses
Stephen Farrell
Software and Systems Engineering Ltd.
Fitzwilliam Court
Leeson Close
Dublin 2
IRELAND
stephen.farrell@sse.ie
Carlisle Adams
Nortel Secure Networks
PO Box 3511, Station C
Ottawa, Ontario
Canada KY 4H7
cadams@bnr.ca
Warwick Ford
Nortel Secure Networks
PO Box 3511, Station C
Ottawa, Ontario
Canada KY 4H7
wford@bnr.ca
| PAFTECH AB 2003-2026 | 2026-04-24 12:34:08 |