view Side-By-Side changes

Expires in 6 months                                            June                                        December 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 fourth draft of the Internet Public Key Infrastructure X.509 
Certificate Management Protocols. This document is based version builds on 
  sections 7, 9 draft-ietf-
pkix-ipki3cmp-01.txt and discussions on the PKIX mailing list (ietf-
pkix@tandem.com) and 10 of draft-ietf-pkix-ipki-00.txt.  Many changes 
  have been made as a result of discussion at the Dallas Montreal IETF in 
  December 1995, meeting (June 1996).

Summary of changes since the Los Angeles IETF in March 1996, third draft:

- New messages defined to ask for general information from a PKI 
management entity (RA/CA).
- New fields added allowing for:
       proof of possession of a private key; 
       request for publication of a certificate; and discussion on 
  the ietf-pkix@tandem.com mail list. 
       request for archival of a private key.
- ASN.1 simplifications.
- First concrete definition of what is mandatory for conformance.
- File- and socket-based protocols defined.

1. Introduction
The intent layout of this document draft is to 
  generate further productive as follows:

- Section 1 contains an overview of PKI management

Farrell, Adams                                               [Page 1]


INTERNET-DRAFT                                         December 1996

- Section 2 contains discussion of assumptions and restrictions
- Section 3 contains data structures used for PKI management messages
- Section 4 defines the functions which are to build consensus. 
 
 
1. Executive Summary 
   
  << To be supplied. >> 
   

2. carried out in PKI 
management including those which must be supported by conforming 
implementations and those which are optional
- Section 5 describes a simple protocol for transporting PKI messages
1.1 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 complicates 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 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 accommodate different identifiable types of 
end entities. 
   
2.1.1. 

1.2 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. 

1.2.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". In general, we prefer 
the term "end entity" rather than subject in order to avoid confusion 
with the field name.

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 

Farrell, Adams                                              [Page 2]


INTERNET-DRAFT                                         December 1996

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 
fingerprint 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 

Though PSE content is not defined further here as it is formats are out of scope of this document (they are very 
dependent on equipment, et cetera. However, an cetera), a generic interchange format for  
  a generic PSE might be useful 
PSEs is defined here - we could consider using a CertRep certification response message for this.>> 
   
2.1.1.2. may be used.

1.2.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" "off-
line" component. This is, however, a matter for implementors implementers (though it 
is also relevant as a policy issue). 
   
2.1.1.3. Registration Authority 
   
  In addition

We use the term "root CA" to end entities and CAs, indicate a CA which is directly trusted 
by an end entity, that is, securely acquiring the value of a root CA 
public key requires some out-of-band step(s). This term does not 
indicate that a root CA is at the top of any hierarchy, simply that the 
CA in question is trusted directly.

A subordinate CA is one which is not a root CA for the end entity in 
question. Often, a subordinate CA will not be a root CA for any entity 
but this is not mandatory.
1.2.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. 


Farrell, Adams                                              [Page 3]

INTERNET-DRAFT                                         December 1996

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 keys are 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. 

1.3 PKI Management Requirements 

The reasons which justify protocols given here meet the presence of an RA can be split into 
  those which are due following requirements on PKI 
management. 

1. PKI management must conform to technical factors ISO 9594-8 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 associated 
amendments (certificate extensions) 

2. PKI management must conform to initialize these; the RA equipment can 
   include the necessary functionality (this may also be a matter other parts 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 this series. 

3. It must be able possible to issue signed revocation requests on 
   behalf regularly update any key pair without 
affecting any other key pair.

4. The use of end entities associated with it, whereas the end entity may 
   not confidentiality in PKI management protocols must 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 kept 
to a minimum in order to ease regulatory problems 
   
  2.1.2.5. problems.

5. PKI management protocols must allow the use of different 
      industry-standard 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. 

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 
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. 

7. PKI management protocols must support the publication of certificates 
by the end entity concerned, by an RA or by a CA.  Different 
implementations and different environments may choose any of the above 

Farrell, Adams                                              [Page 4]


INTERNET-DRAFT                                         December 1996

approaches. 
   
  2.1.2.8. 

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 denial-of-
service attacks which are possible are not made simpler. 
   
  2.1.2.9. 

9. PKI management protocols must be usable over a variety of "transport" 
mechanisms, specifically including, including mail, http, TCP/IP and ftp. 
   
  2.1.2.10. 

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. 

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 An end-entity 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 also be able to 
verify certificates signed using the new CA private key (following a CA key update).  This is required key.  (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. equipment). 

12. The Functions of an RA may, in some implementations or  
environments, be carried out by the CA itself. The protocols  
      should must 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 

1.4 13. Where an end entity requests a certificate containing a given 
public key value, the end entity must show the ability to use the 
corresponding private key value. This is accomplished in various ways, 
depending on the type of certification request. See the section "Proof 
of Possession of Private Key" for details.

1.5 PKI Management Operations 

  The following diagram shows the relationship between the entities 
defined above in terms of the PKI management operations. The numbers letters in 
the diagram indicate "protocols" in the sense that a defined set of PKI 
management messages can be sent along each of the numbered lettered lines. 

                cert. publish        +------------+ 
      +---+           +------------  | End Entity |   Operations 
      | C |           | 7 g            +------------+ 
      | e |  <--------+                | ^      initial 
      | r |                          1                          a | | 2 b     registration/ 


Farrell, Adams                                              [Page 5]

INTERNET-DRAFT                                         December 1996

      | t |       PKI "users"          | |       certification 
      |   |                            | |      key pair recovery 
      | / |                            | |      key pair update 
      |   |                            | |      certificate update 
      | C |                            V |      revocation request 
      | R |             -------+-+-----+-+------+-+----- 
      | L |   PKI management   | ^              | ^ 
      |   |      entities    1    a | | 2          1 b          a | | 2 b 
      |   |                    V |              | | 
      | R |             7             g   +------+    4    d       | | 
      | e |   <------------ | RA   | <-----+    | | 
      | p |      cert.      |      | ----+ |    | | 
      | o |       publish   +------+   3   c | |    | | 
      | s |                              | |    | | 
      | i |                              V |    V | 
      | t |          8          h                 +------------+   9   i 
      | o |   <------------------------| CA         |-------> 
      | r |                            +------------+  "out-of-band" 
      | y |      cert. publish              | ^         publication 
      |   |      CRL publish                | | 
      +---+                                 | |    cross-certification 
                                          e | | 6 f  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 operations for which management messages are 
defined is can be grouped as follows. 
   
  -CA

1 CA establishment: When establishing a new CA, certain steps are 
required (e.g., production of initial CRLs). 
   
  -export 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 
key).
2 End entity initialisation: this includes importing a CA public key 
and end-entity implementations requesting information about the options supported by a data structure for this purpose is required. 
   
  -initial PKI 
management entity.
3 Certification: various operations result in the creation of new 
certificates:
3.1 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 
3.2 
Farrell, Adams                                              [Page 6]


INTERNET-DRAFT                                         December 1996

1.1 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 
1.2 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 
1.3 certificate update: As certificates expire they may be 
"refreshed" if nothing relevant in the environment has 
changed. 
   
  -certificate 
1.4 CA key pair update: As with end entities, CA key pairs need 
to be updated regularly; however, different mechanisms are 
required. 
1.5 cross-certification:  Two CAs exchange the information 
necessary to establish cross-certificates between those CAs. 
1.6 cross-certificate update: Similar to a normal certificate 
update  but involving a cross-certificate. 
2 Certificate/CRL discovery operations: some PKI management 
operations result in the publication of certificates or CRLs
2.1 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 
2.2 CRL publication: As for certificates. 
3 Recovery operations: some PKI management operations are used when 
an end entity has "lost" it's PSE
3.1 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 
4 Revocation operations: some PKI operations result in the creation 
of new CRL entries and/or new CRLs
4.1 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 
5 PSE operations: whilst the information necessary to 
   establish cross-certificates between those CAs. 
   
  -cross-certificate update: Similar to definition of PSE operations (e.g. 
moving a normal certificate update  
   but involving PSE, changing a cross-certificate. 
   
  -CRL publication: As for certificates. PIN, etc.) are beyond the scope of this 
specification, we do define a PKIMessage which can form the basis 
of such operations.
Note that on-line protocols are not the only way of implementing the 
above functions. operations.  For all functions operations 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 operations 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, (file based, on-line, E-mail, and WWW) are may also be 
specified. 
   
  <> 
   

3. Data Structures 
   
  This section contains descriptions of the data structures required 


Farrell, Adams                                              [Page 7]


INTERNET-DRAFT                                         December 1996

2. Assumptions and restrictions
2.1 End entity initialisation
The first step for and end entity in dealing with PKI management messages. Section 4 describes constraints on their 
  values 
entities is to request information about the PKI functions supported and 
optionally to securely acquire a copy of the sequence relevant root CA public 
key(s).

2.2 Initial registration/certification
There are many schemes which can be used to achieve initial registration 
and certification of events end entities. No one method is suitable for each of all 
situations due to the various PKI 
  management operations. Section 5 describes how these range of policies which a CA 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 implement and 
  transaction identification. Some the 
variation in the types of this information will also be 
  present in a transport-specific envelope; end entity which can occur.

We can however, if classify the PKI message 
  is signed then initial registration / certification 
schemes which are supported by this information specification. Note that the word 
"initial", above, is also protected (i.e. crucial - 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 are dealing with the transaction, i.e. this will be situation where 
the same end entity 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 question has had no previous contact with the creator of PKI. 
Where the end entity already possesses certified keys then some 
simplifications are possible.

Having classified the schemes which are supported by this message; recipNonce 
            -- specification 
we can then specify some as mandatory and some as optional. The goal is 
that the mandatory schemes cover a nonce previously inserted sufficient number of the cases which 
will arise in real use, whilst the optional schemes are available for 
special cases which arise less frequently. In this way we achieve a related message by 
            -- 
balance between flexibility and ease of implementation.

We will now describe the intended recipient classification of this message 
       messageTime         UTCTime                OPTIONAL, 
            -- time initial registration / 
certification schemes.
2.2.1 Criteria used
2.2.1.1 Initiation of production registration / certification
In terms of this message 
       sender              GeneralName, 
            -- identifies the sender for addressing purposes 
       recipient           GeneralName, 
            -- identifies PKI messages which are produced we can regard the intended recipient for addressing purposes 
       protectionAlg       AlgorithmIdentifier    OPTIONAL, 
            -- to include 
initiation of 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), -- initial registration / certification exchanges as 
occurring wherever the first PKI message asking for cross-certification 
       CrossCertRep (11), -- response relating 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 end entity is required so 
produced. Note that the recipient real world initiation of a response message can correlate this with the 
  request issued. In registration / 
certification procedure may occur elsewhere (e.g. a personnel department 
may telephone an RA operator).

The possible locations are: at the case of end entity, an RA there or a CA.
2.2.1.2 End entity message origin authentication
The on-line messages produced by the end entity which requires a 
certificate may be many requests 
  "outstanding" at a given moment. authenticated or not. The value requirement here is to 
authenticate the origin of this field should be 
  unique any messages from the sender's perspective in order end entity to be useful. 
   
  <> 
   
3.1.2. the 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. 
(CA/RA).

In that case the 
  following structure is used: 
   
  PKIProtection ::= SEQUENCE { 
       alg             AlgorithmIdentifier    OPTIONAL, 
            -- when both this field and specification, such authentication is achieved by the protectionAlg field of PKI 
(CA/RA) issuing the 
            -- PKIHeader are present, they must end entity with a secret value (initial 
authentication key) and reference value (used to identify the 
transaction) via some out-of-band means. The initial authentication key 
can then be used to protect relevant PKI messages.

We can thus classify the same 
       protectionBits  BIT STRING 
  } initial registration/certification scheme 

Farrell, Adams, Ford Adams                                              [Page 10] 8]


INTERNET-DRAFT                                                 June                                         December 1996 
   
  The input

according to whether or not the calculation of the protectionBits is on-line end-entity -> PKI messages are 
authenticated or not.

Note 1: We do not discuss the DER 
  encoding authentication of the following data structure: 
   
  ProtectedPart ::= SEQUENCE { 
       PKIHeader, 
       PKIBody} 
   
  Note that PKI -> end entity 
messages here as this is equivalent to always required. In any case, it can be 
achieved simply once 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 root-CA public key 
    - symmetric protection: used in some has been installed at the 
end entity's equipment or based on the initial authentication key.

Note 2: An initial registration schemes 
    - single signature protection: e.g., when an RA signs a request 
    - double signature protection: e.g., when both / certification procedure can be secure 
where the messages from the end entity and RA 
      sign are authenticated via some out-
of-band means (e.g. a request 
   
3.1.3.1. Unprotected PKI messages 
   
  <> 
   
3.1.3.2. Symmetric protection subsequent visit).
2.2.1.3 Location 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. key generation
In this case the PKIProtection 
  structure specification, key generation is also used regarded 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 occurring wherever 
either the DER encoding public or private component 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 key pair first occurs in more than one 
  case. 
   
3.2.1. Requested Certificate Contents 
   
  Various a 
PKI management messages require message. Note that this does not preclude a centralised key 
generation service - the originator of actual key pair may have been generated 
elsewhere and transported to the 
  message indicate some end entity, RA or CA.

There are thus three possibilities for the location of key generation: 
the fields which are required to be present 
  in end-entity, an RA or a certificate. The CertTemplate structure allows CA.
2.2.1.4 Confirmation of successful certification
Following the creation of an initial certificate for an end entity 
  or RA to specify as much as they entity, 
additional assurance can about be gained by having the certificate they 
  require. ReqCertContent is basically end entity explicitly 
confirm successful receipt of the same as a Certificate but 
  with all fields optional. 
   
  Note that even if message containing (or indicating the originator completely specifies 
creation of) the contents of 
  a certificate they require, a CA is free to modify fields within certificate. Naturally, this confirmation message must 
be protected (based on 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 initial authentication key or other means).

This gives two further possibilities: confirmed or not.
2.2.2 Mandatory schemes
The criteria above allow for a particular serial large number 
       signingAlg [2] AlgorithmIdentifier   OPTIONAL, 
            -- used to ask of initial registration / 
certification schemes. This specification mandates that conforming RA/CA 
equipment must support both of the CA to use this alg. for 
            -- signing schemes listed below. Conforming end 
entity equipment must support one of 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, 
  }        -- schemes listed below.
2.2.2.1 Centralised scheme
In terms of the extensions which classification above, this scheme is where:

- initiation occurs at the requester would like in certifying CA;
- no on-line message authentication is required;
- key generation occurs at 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 certifying CA;
- no confirmation message is required.

In terms of message flow, this scheme means that the following data 
  structure only message 
required is used. 
   
  EncryptedPrivKey ::= SEQUENCE { 
       privKey     BitsAndAlgs, 
            -- sent from the private key encrypted 
       encSymmKey  BitsAndAlgs OPTIONAL 
            -- a symmetric key used CA to encrypt the private key 
  }
   
  BitsAndAlgs ::= SEQUENCE { 
       encKey      BIT STRING, 
       encAlg [0]  AlgorithmIdentifier  OPTIONAL, 
            -- algorithm used to encrypt end entity. The message must contain 
the key 
       keyAlg [1]  AlgorithmIdentifier  OPTIONAL 
            -- algorithm entire PSE for which the key is intended to end entity. Some out-of-band means must be used 
  } 
   
  EncryptedPrivKeys ::= SEQUENCE of EncryptedPrivKey

  Use of this data structure requires that 
provided to allow the creator and intended 
  recipient are respectively able end entity to encrypt and decrypt. Typically, authenticate the message received.
2.2.2.2 Basic authenticated scheme
In terms of the classification above, this will mean that scheme is where:

- initiation occurs at the end entity has been issued with
- message authentication is required
- key generation occurs at the end entity
- a secret confirmation message is required


Farrell, Adams                                              [Page 9]

INTERNET-DRAFT                                         December 1996

In terms of message flow, the scheme is as follows:

      End entity                                           CA
      ==========                                      =============
                    out-of-band distribution of 
                    initial authentication key 
  shared and 
                    reference value
      Key generation
      Creation of certification request
      Protect request with IAK
                    -->>--certification request-->>
                                                     verify request
                                                     process request
                                                     create response
                    --<<--certification response--<<--
      handle response
      create confirmation
                    -->>--confirmation message-->>--
                                                     verify confirmation

(Where verification of the confirmation message fails, the CA must 
revoke the newly issued certificate if necessary.)
2.3 Proof of Possession of Private Key
In order to prevent certain attacks, the generator PKI management operations 
specified here require end-entities to prove that they have possession 
of (i.e., are able to use) the private key pair. 
   
  If corresponding to the recipient of public 
key for which a certificate is requested.

This is accomplished in a different ways, depending on the PKIMessage already possesses type of key 
for which a certificate is requested. If a private key 
  usable can be used for decryption, multiple 
purposes (e.g. an RSA key) then any of the encSymmKey field methods may contain a 
  session key encrypted using be used.

This specification explicitly allows for cases where an end entity 
supplies the recipient's public key. 
   
3.2.3. Status codes relevant proof to an RA 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 RA subsequently attests to 
the 
            -- message 
       waiting                (3), 
            -- CA that the request body part required proof has not yet been processed, 
            -- expect received (and validated!). For 
example, an end entity wishing to hear more later 
       revocationWarning      (4) 
            -- this message contains a warning that have a revocation is 
            -- imminent 
       revocationNotification (5) 
            -- notification signing key certified could 
send the appropriate signature to the RA which then simply notifies the 
relevant CA that a revocation the end entity has occurred 
  } 
   
  Responders supplied the required proof. Of 
course, such a situation may use be disallowed by some policies.
2.3.1 Signature Keys
For signature keys, the following syntax end-entity can sign a value to provide more information 
  about failure cases. 
   
  PKIFailureInfo ::= BIT STRING {    -- since we prove possession 
of the private key.
2.3.2 Encryption Keys
For encryption keys, the end-entity can fail be required to decrypt a value 
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 prove possession of the following data 
  structure private key. This can be achieved 
either directly or indirectly. 

The direct method is used. 
   
  CertId ::= SEQUENCE { 
       issuer           GeneralName, 
       serialNumber     INTEGER 
  } 
  
  Furthermore, to issue a list of certificates is identified as follows.
  
  Certs ::= SEQUENCE OF Certificate 
   
3.2.5. Publication Information 
   
  <> 
   
  In order random challenge to allow requesters which an immediate 
response is required.

The indirect method is 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 issue a certificate which is used. 
   
  PublicationInfo ::= SEQUENCE OF SEQUENCE { 
       pubMethod  OBJECT IDENTIFIER, 
       pubDetails OCTET STRING OPTIONAL} encrypted for the 

Farrell, Adams, Ford Adams                                              [Page 14] 10]


INTERNET-DRAFT                                                 June                                         December 1996 
   
3.2.6. "Out-of-band"

end entity (and have the end entity demonstrate its ability to decrypt 
this certificate in the confirmation message). This allows a CA public to issue 
a certificate in a form which can only be used by the intended end 
entity.

This specification uses the indirect method because this requires no 
extra messages to be sent (i.e., the proof can be demonstrated using the 
{request, response, confirmation} triple of messages).

2.3.3 Key Agreement Keys
For key 
   
  Each agreement keys, the end entity and the PKI management entity 
(i.e. CA or RA) must be able to publish its current public establish a shared secret key via some "out- 
  of-band" means. While such mechanisms are beyond in order to prove 
that the scope end entity has possession of the private key.

Note that this 
  document, we define data structures need not impose any restrictions on the keys which can support such mechanisms. 
   
  There are generally two methods available; either the be 
certified by a given CA directly 
  publishes -- in particular, for Diffie-Hellman keys the 
end entity may freely choose its public key and associated attributes, or this 
  information is available via algorithm parameters -- provided that 
the Directory CA can generate a short-term (or equivalent) and one-time) key pair with the 
appropriate parameters when necessary.

2.4 Root CA 
  publishes a hash of this value key update
This discussion only applies to allow verification CAs which are a root CA for some end 
entity.

The basis of the procedure described here is that the CA protects 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, 
new public key using its previous private key and Validity vice versa. Thus when 
a CA updates its key pair it must generate two new cACertificate 
attribute values if certificates 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 made available using an 
  InitRepContent data structure which has for each certificate requested 
  a StatusInfo field, a subject certificate, and possibly X.500 
directory. 

When a private CA changes its key 
  (encrypted with a session key, which pair those entities who have acquired the old 
CA public key via "out-of-band" means are most affected. It is itself encrypted these end 
entities who will need access to the new CA public key protected with 
the 
  protocolEncKey).  InitRepContent also contains a old 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 private key. However, they will only require this for a 
  CertReqContent data structure which specifies 
limited period (until they have acquired the requested 
  certificate. 
   
  CertReqContent ::= CertTemplates 
   
3.3.4. Registration/Certification Response 
   
  A registration response message (CertRep) contains a CertRepContent 
  data structure which has a new 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 key via the failInfo (in StatusInfo) 
"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 fields (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 present in CertRepResponse (depending on the status). For some 
  status values (e.g., waiting) neither able to work even for version 1 certificates. The presence of 
the optional fields will KeyIdentifier extension would make for efficiency improvements. 

2.While the scheme could be 
  present. 
   
3.3.5. Key update request content 
   
  For generalized to cover cases where the CA 
updates its key update requests pair more than once during the following syntax is used.  Typically, 
  SubjectPublicKeyInfo, KeyId, and Validity are validity period of one of 
its end entity's certificates, this generalization seems of dubious 
value. This means that the template fields 
  which may be supplied for each key to be updated.  As well, an 
  encryption certificate, or validity period of a signature certificate, or both, would 
  typically CA key pair must be specified in latestCerts. 
   
  KeyUpdReqContent ::= SEQUENCE { 
       endEntityName       GeneralName, 
       latestCerts         SEQUENCE OF CertId, 
       protocolEncKey  [1] SubjectPublicKeyInfo  OPTIONAL, 
       certTemplates   [2] CertTemplates OPTIONAL 
  } 

Farrell, Adams, Ford Adams                                              [Page 16] 11]


INTERNET-DRAFT                                                 June                                         December 1996 
   
3.3.6. Key Update response content 
   
  For key update responses the syntax used is identical to

greater than the 
  initialization response.
   
  KeyUpdRepContent ::= InitRepContent 
   
3.3.7. Key Recovery Request content 
   
  For validity period of any certificate issued by that CA 
using that key recovery requests the syntax used is identical pair. 

3.This scheme forces end entities to acquire the 
  initialization request InitReqContent.  Typically, 
  SubjectPublicKeyInfo and KeyId are the template fields which may be 
  used to supply a signature new CA public key for which a certificate is 
  required.
   
  KeyRecReqContent ::= InitReqContent 
    
3.3.8. Key recovery response content 
   
  For key recovery responses on 
the following syntax is used.  For some 
  status values (e.g., waiting) none expiry 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 last 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 owned which serialNumber is not available) 
       revocationReason    ReasonFlags, 
            -- from was signed with the DAM, so that 
old 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 private key (via the above message. If produced, "out-of-band" means).  Certificate and/or 
key update operations occurring at other times do not necessarily 
require this is sent to the 
  requestor of (depending on the revocation. (A separate revocation announcement 
  message may be sent to end entity's equipment). 
2.4.1 CA Operator actions 
  To change the subject key 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 CA, the same syntax as for normal 
  certification responses. 
   
  CrossCertRepContent ::= CertRepContent 
   
3.3.13. CA Key Update Announcement content 
   
  When operator does the following: 

  1.Generate a CA updates its own new key pair pair. 

  2.Create a certificate containing the following data structure may 
  be used to announce this event. 
   
  CAKeyUpdAnnContent ::= SEQUENCE { 
       oldWithNew          Certificate, -- old pub CA public key signed with 
the new priv 
       newWithOld          Certificate, -- private key (the "old with new" certificate). 

  3.Create a certificate containing the new pub CA public key signed with 
the old priv 
       newWithNew          Certificate  -- private key (the "new with old" certificate). 

  4.Create a certificate containing the new pub CA public key signed with 
the new priv 
  } 
   
3.3.14. Certificate Announcement 
   
  This data structure may be used to announce private key (the "new with new" certificate). 

  5.Publish these new certificates via the existence of 
  certificates. 
   
  Note directory and/or other means. 
(A CAKeyUpdAnn message.) 

  6.Export the new CA public key so that this structure (and end entities may acquire it 
using the CertAnn message itself) is intended 
  to be used for those cases (if any) where there "out-of-band" mechanism. 

The old CA private key is then no pre-existing 
  method for publication of certificates; it is not intended to be used 
  where, longer required. The old CA public key 
will however remain in use for example, X.500 is some time. The time when the method for publication of 
  certificates. 
   
  CertAnnContent ::= Certificate 
   
Farrell, Adams, Ford                                           [Page 18] 
INTERNET-DRAFT                                                 June 1996 
   
3.3.15. Revocation Announcement 
   
  When a old CA has revoked, or 
public key is about to revoke, a particular certificate 
  it may issue an announcement no longer required (other than for non-repudiation) will 
be when all end entities 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 have acquired the subject concerned. 
   
3.3.16. CRL Announcement 
   
  When a new CA issues public key 
via "out-of-band" means. 

The "old with new" certificate should have 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 validity period starting at 
the final 
  PKIMessage. Its content is generation time of the same in all cases - actually there is 
  no content since old key pair and ending at the PKIHeader carries all time at which 
the required information. 
   
  PKIConfirmContent ::= NULL 
   


Farrell, Adams, Ford                                           [Page 19] 
INTERNET-DRAFT                                                 June 1996 
   
4. PKI Management Operations CA will next update its key pair. 

The "new with old" 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 should have a sequence of messages between the two systems 
  concerned.  This section defines validity period starting at 
the contents generation time of the messages 
  exchanged. 
   
  The protocols for conveying these exchanges in different environments 
  (on-line, E-mail, new key pair and WWW) are specified in Section 5. 
   
  The protocol exchanges defined in ending at the time by which 
all end entities of 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 will securely possess the protocol exchange descriptions: 
   
   -In exchanges between new CA public key. 

The "new with new" certificate should have a client system 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. 

2.4.2 Verifying Certificates. 
Normally when verifying a CA, signature the protocol 
    exchange is initiated by verifier simply(!) verifies the client system.  The one exception to 
    this is 
certificate containing the Centrally-Initiated Key Pair Update exchange. 
   -To provide an upgrade path, public key of the signer. However, once a protocol version indicator CA 
is always 
    included in the first message allowed to update its key there are a range of an exchange. 
   -A message type indicator is included new possibilities. 
These are shown in the protected part of all 
    messages. 
   -All messages include an optional transaction identifier which is 
    used to assist correlation of request table below. 


Farrell, Adams                                              [Page 12]


INTERNET-DRAFT                                         December 1996

            Repository contains NEW     Repository contains only OLD 
              and response messages for 
    one transaction. 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: 
certifi-   This identifier is generated by the initiator of      In this case  Although the exchange and will typically include   In this case 
cate is    the initiator's name plus 
    a transaction sequence number. 
   -The initial message from          the client to verifier  CA operator    the CA may optionally 
    contain 
protected  standard     must access   has not        operator  has 
using NEW  case where   the client system time.  This is used to facilitate           updated the 
    correction of client time problems by central administrators. 
   -Responses from CA to client include    not updated 
public     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          directory in some of  directory the protocols to prevent replay 
    of  the exchanges. 

Farrell, Adams, Ford                                           [Page 20] 
INTERNET-DRAFT                                                 June 1996 
   
   -Responses directory 
key        verifier     order to get  verifier can be aborted at any time. An enumerated error code is 
    sent from the aborting end   and so the 
           can be decoded into a user readable 
    error string at          the other end.  Error codes are not specified in 
    this version value of this document. 
   -Items in square brackets [] are optional. 
   -In every instance in which a  verify the     verification 
           directly     the NEW       certificate    will FAIL 
           verify the   public key    directly - 
           certificate                this is transferred, it is 
    transferred in thus 
           without                    the same as 
           using the                  case 1. 
           directory 
 
Signer's   Case 2:      Case 4:       Case 6:        Case 8: 
certifi-   In this      In this case  The verifier   Although the 
cate is    case 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 verifier  thinks this    CA along with 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 for 
    inclusion        directory    without       will access    verifier can 
           in order     using the certificate.  However,     the CA may override this 
    value with a key identifier of its own.  If            verify the client is 
    concerned about 
           to get the key identifier   directory     directory,     certificate 
           value used, it should check of                   however 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    directly - 
           the OLD                    verification   this operation involves an out-of-band (or 
  indeed implicit) request to an RA or CA. If no RA is involved then thus 
           public key                 will FAIL      the CA same as 
                                                     case 4. 

2.4.2.1 Verification in question simply prepares a PSE for the end entity. When an 
  RA is involved cases 1, 4, 5 and 8. 
In these cases the RA creates verifier has a certification request (CertReq) 
  message for local copy of the end entity in question and sends this CA public key which 
can be used to verify the 
  appropriate CA. 
   
  When an RA certificate directly. This is involved the steps required are same 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 
situation where no key change has ever occurred. 

Note that case 8 may provide the end entity with its PSE if 
    the PSE doesn't need to contain arise between the end entity's own 
    certificate(s). 
  3.The CertReq message is transported to time when 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 operator has 
generated the RA. 
  6.The RA processes new key pair and the CertRep.  Depending on its content some 
    looping may be required; that is, time when the RA may have to await further 
    responses or generate a new CertReq for this end entity <>.  Once CA operator stores the required certificates have been acquired 
updated attributes in the RA directory. Case 5 can prepare only arise if the 
    end entity's PSE (assuming that CA 
operator has issued both the PSE contains signer's and verifier's certificates during 
this "gap" (the CA operator should avoid this as it leads to the end entity's 
    certificates). 
  7.The end entity receives failure 
cases described below). 
2.4.2.2 Verification in case 2. 
In case 2 the PSE and if necessary verifies that verifier must get access to the 
    CA old public key contained therein is correct. of the CA. 
The verifier does the following: 


Farrell, Adams, Ford Adams                                              [Page 21] 13]

INTERNET-DRAFT                                                 June                                         December 1996 
   
  We impose

1.Lookup the following constraints on CACertificate attribute in the certification request 
  message. 
   
  1.The RA must provide directory and pick the protectionAlg field of 
appropriate value (based on validity periods) 
2.Verify that this is correct using the PKIHeader and 
    must protect new CA key (which the CertReq message. The name in verifier 
has locally). 
3.If correct then check the sender field of signer's certificate using the PKIHeader must be usable old CA key. 

Case 2 will arise when verifying the protection. 
  2.The messageType field of CA operator has issued the PKIMessage must contain signer's 
certificate, then changed key and then issued the CertReq 
    value. 
  3.The CertReqContent supplied verifier's 
certificate, so it is quite a typical case. 

2.4.2.3 Verification in case 3. 
In case 3 the verifier must contain values for get access to the following 
    fields (i.e. these are mandated for this operation): 
          - version 
          - subject 
          - validity. 
  4.If new public key of the RA CA. 
The verifier does not provide the subjectPublicKeyInfo field this 
    indicates that following: 

1.Lookup the RA is requesting a centrally-generated key pair CACertificate attribute in the directory and pick the 
appropriate value (based on validity periods).  
2.Verify that this is correct using the old CA return the end entity's private key encrypted 
    (using an EncPrivKey structure) for (which the end-entity or for verifier 
has stored locally). 
3.If correct then  check the RA 
    according to policy (and signer's certificate using the type of PSE in use). 
    If new CA key. 

Case 3 will arise when the RA does provide CA operator has issued the subjectPublicKeyInfo field verifier's 
certificate, then changed key and then issued the signer's certificate, 
so it is also quite a typical case. 

2.4.2.4 Failure of verification in case 6. 
In this does 
    not mean that case the RA need have generated CA has issued the end entity's verifier's PSE containing the new key 
    pair, (which is an option) but simply 
without updating the directory attributes. This means that the RA verifier 
has no means to get a "good" 
    copy trustworthy version of the end entity's public key. 
   
  All conforming CA's old key and so 
verification fails. 

Note that the failure is the 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 operator's fault. 
2.4.2.5 Failure of Exchange 
   
  This protocol exchange is used to support client initialization, 
  including verification in case 7. 
In this case the CA has issued the signer's certificate issuance, for one user, protected with provision for 
  simultaneously establishing and certifying separate key pairs for 
  digital signature and encryption (or encryption key exchange) 
  purposes.  Both 
the new key pairs are generated by without updating the client and directory attributes. This means that 
the verifier has no private 
  key is exposed means to get a trustworthy version of the CA.  Generation CA's new 
key and certification of so verification fails. 

Note that the 
  encryption failure is again the CA operator's fault. 
2.4.3 Revocation - Change of CA key pair 
As we saw above the verification of a certificate becomes more complex 
once the CA is optional. 
   
  Prior allowed to conducting this exchange, change its key. This is also true for 
revocation checks as the user must CA may have registered with signed the CA, CRL using either a face-to-face registration exchange or some 
  other means. 
   
  Following registration, newer 
private key than the CA creates a secret data item, called an 
  authorization code,  and transfers this data item by out-of-band 
  means to one that is within the user. user's PSE. 

The authorization code is used to establish 
  authentication and integrity protection analysis of the user 
  initialization/certification on-line exchange. This alternatives is done by 
  generating a symmetric key based on as for certificate verification. 


3. Data Structures 
This section contains descriptions of the authorization code and using 
  this symmetric key data structures required for generating Message Authentication Codes (MACs) 
  on all exchanges between client and CA. 
PKI management messages. Section 4 describes constraints on their values 

Farrell, Adams, Ford Adams                                              [Page 22] 14]


INTERNET-DRAFT                                                 June                                         December 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 sequence of public keys allows the client and CA 
  to authenticate events for each other. 
   
4.1.2.1.2. Detailed Description 
   
  The user receives a reference number and a secret machine-generated 
  authorization code from of the CA administrator. Both pieces various PKI management 
operations. Section 5 describes how these may be encapsulated in various 
transport mechanisms. 
3.1 Overall PKI Message 
All of 
  information are transferred to the user messages used in a secure manner which 
  preserves their integrity and confidentiality. PKI management use the following structure:

  PKIMessage ::= SEQUENCE { 
      header           PKIHeader, 
      body             PKIBody, 
      protection   [0] PKIProtection OPTIONAL,
      extraCerts   [1] SEQUENCE OF Certificate OPTIONAL
  }

The reference number PKIHeader contains information which is used common to uniquely identify the client at the CA and many PKI messages.

The PKIBody contains message-specific information.

The PKIProtection contains bits which protect the 
  authorization code is used PKI message.

The extra certificates field can contain certificates which may be 
useful to secure the exchange in terms of 
  integrity. The reference number is recipient. For example, this can be used instead of by a DN CA or RA to uniquely 
  identify 
present an end entity with certificates which it needs to verify it's 
own new certificate (if the client because CA that issued the end entity's certificate 
is not a DN may be lengthy and difficult root CA for the end entity). 

Note also that this field does not necessarily contain a 
  user certification 
path - the recipient may have to manually type without error. 
   
   
  After sort, select from, or otherwise process 
the reference number extra certificates in order to use them.
3.1.1 PKI Message Header 
All PKI messages require some header information for addressing 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) 
transaction identification. Some of this information will also be 
present in 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 transport-specific envelope; however, if the PKI 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 then this information is required) a 
        new certificate for the user's encryption public key. also protected (i.e. we make no 
assumption about secure transport). 

The CA responds following data structure is used to contain this information: 

  PKIHeader ::= SEQUENCE { 
      pvno                INTEGER     { ietf-version1 (0) }, 
      sender              GeneralName, 
      -- identifies the client with sender
      recipient           GeneralName, 
      -- identifies the intended recipient
      messageTime     [0] GeneralizedTime        OPTIONAL, 
      -- time of production of this message InitRep. The entire 
  structure is protected from modification with a MAC based on (used when sender
      -- believes that the 
  authorization code. 
   
  Upon receipt of transport will be "suitable"; i.e., 
      -- that the InitRep message, the client checks that its own 
  system time is sufficiently close will still be meaningful upon receipt)
      protectionAlg   [1] AlgorithmIdentifier    OPTIONAL, 
      -- algorithm used for calculation of protection bits
      senderKID       [2] KeyIdentifier          OPTIONAL,
      recipKID        [3] KeyIdentifier          OPTIONAL,


Farrell, Adams                                              [Page 15]


INTERNET-DRAFT                                         December 1996

      -- to identify specific keys used for protection
      transactionID   [4] OCTET STRING           OPTIONAL, 
      -- identifies the CA system time, checks the 
  client random number, and validates the MAC.  The client then 
  securely stores transaction, i.e. this will be the new certificates same in 
           -- corresponding request, response and acknowledges confirmation messages
      senderNonce     [5] OCTET STRING           OPTIONAL, 
      recipNonce      [6] OCTET STRING           OPTIONAL, 
      -- nonces used to provide replay protection, senderNonce 
      -- is inserted by the transaction creator of this message; recipNonce 
      -- is a nonce previously inserted in a related message by sending back 
      -- the intended recipient of this message PKIConfirm. 
      freeText        [7] PKIFreeText            OPTIONAL
      -- this may be used to indicate context-specific 
      -- instructions (this field is intended for human 
      -- consumption) 
  }

  PKIFreeText ::= CHOICE { 
      iA5String  [0] IA5String, 
      bMPString  [1] BMPString
  }

The fields in pvno field is fixed for this message 
  are protected from modification with a MAC based on version of IPKI.

The sender field contains the authorization 
  code. 
   
Farrell, Adams, Ford                                           [Page 23] 
INTERNET-DRAFT                                                 June 1996 
   
  Upon receipt name of the PKIConfirm message, sender of the CA checks PKIMessage. This 
name (in conjunction with senderKID, if supplied) should be usable to 
verify the random 
  numbers and validates protection on the MAC. message.  If no errors occur, the CA archives nothing about 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 sender is used 
known 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 sending entity (e.g., in the CA. 
   
  Prior to conducting this exchange, InitReqContent message, where 
the user end entity may not know its own DN, e-mail name, IP address, etc.), 
then the "sender" field must have registered with contain a "NULL" value; that is, the CA, using either 
SEQUENCE OF relative distinguished names is of zero length.  In such a face-to-face registration exchange or some 
  other means. 
   
  Following registration, 
case the CA creates senderKID field must hold an identifier (i.e., a reference 
number) which indicates to the receiver the appropriate shared secret data item, called an 
  authorization code,  and transfers this data item by out-of-band 
  means 
information to use to verify the user. message.

The authorization code is used to establish 
  authentication and integrity protection recipient field contains the name of the user 
  initialization/certification on-line exchange. recipient of the 
PKIMessage. This is done by 
  generating a symmetric key based on name (in conjunction with recipKID, if supplied) should 
be usable to verify the authorization code and using 
  this symmetric key for generating Message Authentication Codes (MACs) protection on all exchanges between client and CA. 
   
  In the first two messages exchanged, message.

The protectionAlg field specifies the client sends its user 
  signature public key algorithm used to protect 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. 
message. If a centrally-generated encryption key pair no protection bits are supplied (PKIProtection is to optional) 
then this field must be omitted; if protection bits are supplied then 
this field must be established, supplied.

senderKID and recipKID are usable to indicate which keys have been used 
to protect the private key message (recipKID will normally only be required where 
protection of the newly generated key pair is sent from the CA 
  to the client. message uses DH keys).

The client first generates a protocol encryption key 
  pair and sends transactionID field within the public protocol encryption key to message header is required so that 
the CA. The CA 
  creates recipient of a random symmetric key called the session key and encrypts 
  the user encryption private key with it and then encrypts the session 
  key response message can correlate this with a previously 
issued request. For example, in 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. case of an RA there may be many 
requests "outstanding" at a given moment.


Farrell, Adams, Ford Adams                                              [Page 24] 16]


INTERNET-DRAFT                                                 June                                         December 1996 
   
4.1.2.2.2. Detailed Description

The user receives a reference number senderNonce and a secret machine-generated 
  authorization code from the CA administrator. Both pieces of 
  information are transferred to recipNonce fields protect the user in a secure manner which 
  preserves their integrity and confidentiality. PKIMessage against 
replay attacks.

The reference number 
  is used to uniquely identify messageTime field contains the client time at which the CA and sender created the 
  authorization code is used 
message. This may be useful to secure the exchange integrity-wise. The 
  reference number is used instead of a DN allow end entities to uniquely identify correct their local 
time to be consistent with the 
  client because time on a DN central system.

The freeText field may be lengthy and difficult for used to send a user human-readable message 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 
recipient.
3.1.2 PKI Message Body 
  PKIBody ::= CHOICE {       -- message-specific body elements 
      ir      [0]  InitReqContent, 
      ip      [1]  InitRepContent, 
      cr      [2]  CertReqContent, 
      cp      [3]  CertRepContent, 
      kur     [4]  KeyUpdReqContent, 
      kup     [5]  KeyUpdRepContent, 
      krr     [6]  KeyRecReqContent, 
      krp     [7]  KeyRecRepContent, 
      rr      [8]  RevReqContent, 
      rp      [9]  RevRepContent, 
      ccr     [10] CrossCertReqContent, 
      ccp     [11] CrossCertRepContent, 
      ckuann  [12] CAKeyUpdAnnContent, 
      cann    [13] CertAnnContent, 
      rann    [14] RevAnnContent, 
      crlann  [15] CRLAnnContent, 
      conf    [16] PKIConfirmContent, 
      nested  [17] NestedMessageContent,
      infor   [18] PKIInfoReqContent,
      infop   [19] PKIInfoRepContent,
      error   [20] ErrorMsgContent
  }

The specific types are described in section 3.3 below.
3.1.3 PKI Message Protection 
Some PKI messages will be protected for integrity. (Note that if an 
asymmetric algorithm is required) used to protect 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 and the CA. The entire structure is 
  protected from modification with a MAC based on relevant 
public component has been certified already, then the authorization 
  code. 
   
  Upon receipt origin of message 
can also be authenticated.  On the InitReq message, if the CA recognizes the 
  reference number and other hand, if the protocol version public component 
is valid, it saves the 
  client random number, generates its own random number (CA random 
  number), and validates the MAC. It uncertified then creates: 
   
      - a new certificate for the user's digital signature public key, 
      - (if a new centrally-generated encryption key pair message origin cannot be automatically 
authenticated, but may be authenticated via out-of-band means.) 

When protection is required) 
        a session key, a new user encryption key pair, and a new 
        certificate for applied the user encryption public key. following structure is used: 

  PKIProtection ::= BIT STRING 

The CA responds input to the client with calculation of the message  InitRep. If a new 
  centrally-generated encryption key pair protectionBits is being generated, the user 
  encryption private key is encrypted using DER encoding 
of the session key and following data structure: 

  ProtectedPart ::= SEQUENCE { 


Farrell, Adams                                              [Page 17]


INTERNET-DRAFT                                         December 1996

      header    PKIHeader, 
      body      PKIBody
  }

Depending on the 
  session key is encrypted with circumstances the protocol encryption public key. The 
  entire structure is protected PKIProtection bits may contain a MAC 
or signature. Only the following cases can occur:

- shared secret information

In this case the sender and recipient share secret information 
(established via out-of-band means or from modification with a previous PKI management 
operation). The protection bits will typically contain a MAC based on value and 
the authorization code. 
   
  Upon receipt of protectionAlg will be the InitRep structure, following:

  PasswordBasedMac ::= OBJECT IDENTIFIER

  PBMParameter ::= SEQUENCE {
      salt                OCTET STRING,
      owf                 AlgorithmIdentifier,
      -- AlgId for a One-Way Function (SHA-1 recommended)
      iterationCount      INTEGER,
      -- number of times the client checks that its own 
  system time OWF is sufficiently close to applied
      mac                 AlgorithmIdentifier
      -- the CA system time, checks MAC AlgId (e.g., DES-MAC or Triple-DES-MAC [PKCS #11])
  }

In the 
  client random number, and validates above protectionAlg the MAC.  If a new centrally- 
  generated encryption key pair salt value is included, the client decrypts appended to the 
  encryption private key. shared 
secret input. The client OWF is then securely stores applied iterationCount times, where the new 
  certificates and encryption private key (if present) and acknowledges 
salted secret is the transaction by sending back input to the message PKIConfirm. The fields in 
  this message are protected from modification with a MAC based on first iteration and, for each 
successive iteration, the 
  authorization code. 
   
Farrell, Adams, Ford                                           [Page 25] 
INTERNET-DRAFT                                                 June 1996 
   
  Upon receipt of input is set to be the PKIConfirm message, output of the CA checks previous 
iteration. The output of the random 
  numbers and validates final iteration (called "BASEKEY" for 
ease of reference, with a size of "H") is what is used to form the MAC. 
symmetric key. If no errors occur, the CA archives 
  the new user public-key certificate(s) and (if there is MAC algorithm requires a new 
  centrally-generated encryption K-bit key pair and key recovery K <= H, 
then the most significant K bits of BASEKEY are used. If K > H, then all 
of BASEKEY is to be 
  supported) used for 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 most significant H bits of Exchange 
   
  This exchange the key, OWF("1" 
|| BASEKEY) is used to update for the signature key pair and/or client- 
  generated encryption key pair next most significant H bits of a user, (e.g., as a result the key, 
OWF("2" || BASEKEY) is used for the next most significant H bits of 
  routine cryptoperiod expiry). 
   
   
  A user must 
the key, and so on, until all K bits have a valid signature been derived. [Here "N" is 
the ASCII byte encoding the number N and "||" represents 
concatenation.]

- DH key pair pairs

Where the sender and receiver possess Diffie-Hellman certificates with 
compatible DH parameters, then in order to do this 
  exchange. It is up to protect the client to determine when message the end 
entity must generate a new signature symmetric key pair should be generated; this has to be done prior to the 
  expiration of based on its signature public-key certificate. 
   
  A private DH key pair update request from a client is digitally signed using value 
and the 
  original user signature private key, this signature being verifiable 
  using an existing signature certificate.  If DH public key of the recipient of the PKI message. The 
protection bits will typically contain a MAC value keyed with this 
derived symmetric key pair update is and the protectionAlg will be the following:.


Farrell, Adams                                              [Page 18]


INTERNET-DRAFT                                         December 1996

  DHBasedMac ::= OBJECT IDENTIFIER

  DHBMParameter ::= SEQUENCE {
      owf                 AlgorithmIdentifier,
      -- AlgId for a new user digital signature key, then One-Way Function (SHA-1 recommended)
      mac                 AlgorithmIdentifier
      -- the client signs MAC AlgId (e.g., DES-MAC or Triple-DES-MAC [PKCS #11])
  }

In the 
  request message once more (including above protectionAlg OWF is applied to the first signature), this time 
  using result of the new signature private key. The reason Diffie-
Hellman computation. The OWF output (called "BASEKEY" for this second 
  signature ease of 
reference, with a size of "H") is what is used to prove to the CA that form the client possesses both symmetric 
key. If the 
  new MAC algorithm requires a K-bit key and old private keys. 
   
  The request K <= H, then the most 
significant K bits of BASEKEY are used. If K > H, then all of BASEKEY is verified at 
used for the CA by using most significant H bits of the matching user 
  signature public key.  A protocol signature key pair key, OWF("1" || BASEKEY) 
is used to 
  authenticate messages from for the CA to next most significant H bits of the client.  CA responses are 
  signed with key, OWF("2" || 
BASEKEY) is used for the protocol signature private key. 
   
  A CA response next most significant H bits of the key, and so 
on, until all K bits have been derived. [Here "N" is validated at the client by using ASCII byte 
encoding the number N and "||" represents concatenation.]

- signature

Where the sender possesses a protocol signature public-key certificate which is included in key pair it may simply sign the CA 
  response. 
PKI message. The protocol protection bits will contain a signature public-key certificate can be 
  validated by using the CA certificate stored at value and the client. A new 
  user initialization (as in Section 4.1) or key pair recovery (as in 
  Section 4.5) must 
protectionAlg will be done if the user an AlgorithmIdentifier for a digital signature key pair becomes 
  invalid. 
   
Farrell, Adams, Ford                                           [Page 26] 
INTERNET-DRAFT                                                 June 1996 
(e.g., md5WithRSAEncryption or dsaWithSha-1). 

- multiple protection

In some client system implementations, local key materials are stored 
  in cases where an encrypted key data disk file. A user may have several copies of 
  this key data file on different computers. It is possible that end entity sends a key 
  update could occur and the user could forget protected PKI message to copy an RA, the updated key 
  data file 
RA may forward that message 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 a CA, attaching it's own protection. This 
is accomplished by nesting the key 
  update request.  Serial numbers are entire message sent so that the CA can check if by 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 end entity 
within a new PKI message. The structure used is equal to that of as follows.

  NestedMessageContent ::= ANY 
  -- This will be a previous certificate, PKIMessage

3.2 Common Data Structures 
Before specifying the CA 
  sends back an error code specific types which indicates that the client has an old 
  version of the key data file. After this, the client can either find 
  the latest key may be placed in a PKIBody we 
define some useful data file or, if structures which are used in more than one case. 
3.2.1 Requested Certificate Contents 
Various PKI management messages require 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 originator of the 
message 
  KeyUpdReq to indicate some of the CA . The fields in this message which are protected from 
  modification and authenticated by required to be present in 
a digital signature using certificate. The CertTemplate structure allows an end entity or RA to 
specify as much as they wish about the pre- 
  existing user signature private key.  If certificate it requires. 
ReqCertContent is basically the update includes same as a new 
  signature key pair, Certificate but with all 
fields optional. 

Note that even if the result is additionally signed using originator completely specifies the new 
  user signature private key. 
   
  Upon receipt contents of the KeyUpdReq message, the a 

Farrell, Adams                                              [Page 19]


INTERNET-DRAFT                                         December 1996

certificate it requires, a CA checks the protocol 
  version, checks the serial number, saves is free to modify fields within the client random number, 
  generates its own random 
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 (CA random number) and verifies the 
  signature using 
      signingAlg [2] AlgorithmIdentifier   OPTIONAL, 
      -- used to ask the previous user verification key which is archived 
  at CA to use this alg. for signing the CA. If a user digital signature key pair is being updated, cert 
      subject    [3] Name                  OPTIONAL, 
      validity   [4] OptionalValidity      OPTIONAL, 
      issuer     [5] Name                  OPTIONAL, 
      publicKey  [6] SubjectPublicKeyInfo  OPTIONAL, 
      issuerUID  [7] UniqueIdentifier      OPTIONAL, 
      subjectUID [8] UniqueIdentifier      OPTIONAL, 
      extensions [9] Extensions            OPTIONAL
      -- the 
  CA also checks extensions which the second signature. It then generates new user 
  signature and/or encryption public-key certificate(s). The CA 
  responds with requester would like in the message KeyUpdRep. The fields cert. 
  }

  OptionalValidity ::= SEQUENCE { 
      notBefore  [0] UTCTime OPTIONAL, 
      notAfter   [1] UTCTime OPTIONAL 
  }

3.2.2 Encrypted Values 
Where encrypted values (restricted, in this message are 
  protected from modification and authenticated by a digital signature 
  using the CA protocol signature specification, to be either 
private key. 
   
  Upon receipt of keys or certificates) are sent in PKI messages the KeyUpdReq message, following 
data structure is used. 

  EncryptedValue ::= SEQUENCE { 
      encValue          BIT STRING, 
      -- the client verifies encrypted value itself
      intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
      -- the 
  digital signature using intended algorithm for which the protocol verification key contained in value will be used
      symmAlg       [1] AlgorithmIdentifier  OPTIONAL, 
      -- the protocol signature public-key certificate, checks that its own 
  system time is close symmetric algorithm used to encrypt the CA system time, and checks value 
      encSymmKey    [2] BIT STRING           OPTIONAL,
      -- 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 (encrypted) symmetric key which is archived at the CA. The CA then archives the new 
  user public-key certificate(s) and updates its data stores used to reflect 
  the new status of encrypt 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 value
      keyAlg        [3] AlgorithmIdentifier  OPTIONAL 
      -- algorithm used to update encrypt the encryption symmetric key pair 
  }

Use of a user, 
  under the assumption this data structure requires that encryption key pairs the creator and intended 
recipient are generated (and, 
  optionally, backed up) centrally. A user must have a valid signature 
  key pair in order respectively able to do encrypt and decrypt. Typically, this exchange. It is up to 
will mean that the client sender and recipient have, or are able to 
  determine when generate, a new encryption key pair should be generated; this 
  must be done some time before 
shared secret key. 

If the expiration date in its encryption 
  public-key certificate. 
   
4.2.2.2. Detailed Description 
   
  The client initiates recipient of the exchange by generating a random number 
  (client random number) and PKIMessage already possesses a protocol encryption private key pair. The client 
usable for decryption, then sends the CA the message KeyUpdReq. The fields in this message 
  are protected from modification and authenticated by encSymmKey field may contain a digital 
  signature session 

Farrell, Adams                                              [Page 20]


INTERNET-DRAFT                                         December 1996

key encrypted 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 recipient's public key which is archived at the CA. It then 
  generates a new end-user encryption key pair key. 
3.2.3 Status codes and encryption public- 
  key certificate Failure Information 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. PKI messages 
All response messages will include some status information. The CA responds 
  with the message KeyUpdRep. In this message, 
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 new or latest 
  encryption private key 
      -- requester is encrypted with responsible for ascertaining the session key and differences 
      rejection              (2), 
      -- you don't get it, more information elsewhere in the 
  session key is encrypted with message
      waiting                (3), 
      -- the protocol encryption key. The fields 
  in request body part has not yet been processed, 
      -- expect to hear more later 
      revocationWarning      (4), 
      -- this message are protected from modification and authenticated by contains a digital signature using the protocol signature private key. 
   
  Upon receipt of the KeyUpdRep message, warning that a revocation is 
      -- imminent 
      revocationNotification (5), 
      -- notification that a revocation has occurred 
      keyUpdateWarning       (6)
      -- update already done for the client verifies oldCertId specified in 
      -- FullCertTemplate
  }

Responders may use the 
  digital signature using the protocol signature public-key 
  certificate, makes sure its own system time is close 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) 
      -- more TBS
  }

  PKIStatusInfo ::= 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 
  }

3.2.5 "Out-of-band" root CA system 
  time, and checks public key 
Each root CA must be able to publish its current public key via some 

Farrell, Adams                                              [Page 21]


INTERNET-DRAFT                                         December 1996

"out- of-band" means. While such mechanisms are beyond the received client random number. The client then 
  decrypts scope of this 
document, we define data structures which can support such mechanisms. 

There are generally two methods available; either the new or latest encryption private CA directly 
publishes its public key and securely stores 
  locally the new associated attributes, or latest user encryption public-key certificate this information 
is available via the Directory (or equivalent) and 
  encryption private key.  It responds with the message PKIConfirm. CA publishes a 
hash of this value to allow verification of its integrity before use. 

  OOBCert ::= Certificate 

The fields in within this message certificate are protected from modification and 
  authenticated by a digital signature using restricted as follows:

- The certificate should be self-signed, i.e. the latest user signature 
  private key. 
   
  Upon receipt of the PKIConfirm message, the CA checks that should be 
verifiable using the client 
  and CA random numbers are correct subjectPublicKey field.
- The subject and verifies the signature using issuer fields should be identical.
- If the latest user signature public key which subject field is archived at the CA. If 
  no errors occur, the CA archives NULL then both subjectAltNames and 
issuerAltNames extensions must be present and have exactly the new user encryption public-key same 
value.
- The values of all other extensions should be suitable for a self-
certificate (e.g. key identifiers for subject and encryption private key, and updates its data stores 
  to reflect issuer should be 
the new status same).

  OOBCertHash ::= SEQUENCE { 
      hashAlg     [0] AlgorithmIdentifier     OPTIONAL, 
      certId      [1] CertId                  OPTIONAL, 
      hashVal         BIT STRING
      -- hashVal is calculated over DER encoding 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 
      -- subjectPublicKey field of Exchange 
   
  This exchange is used to update the encryption key pair corresponding cert. 
  }

The intention of an user, 
  under the assumption hash value here is that encryption key pairs are generated (and, 
  optionally, backed up) centrally. This exchange differs from anyone who has securely 
gotten the 
  preceding exchange (Key Pair Update hash value (via the out-of-band means) can verify a self-
signed certificate for Centrally-Generated 
  Encryption Key Pair) in that the exchange CA. The hash value is initiated by the CA 
  rather than only calculated over 
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 subjectPublicKey field in order to allow the event CA to change its self-
signed certificate (e.g. perhaps to modify some policy constraints). 

3.2.6 Archival Options
Requesters may indicate that they wish the PKI to archive a client no longer has a valid signature private key 
value using the following structure:

  PKIArchiveOptions ::= CHOICE {
      encryptedPrivKey     [0] EncryptedValue,
      -- the actual value of the private key
      keyGenParameters     [1] KeyGenParameters,
      -- parameters which allow the private key pair (due to expiration 
  or revocation), or client system be re-generated
      archiveRemGenPrivKey [2] BOOLEAN
      -- set to TRUE if sender wishes receiver to archive the private
      -- key materials have been lost (e.g., 
  as a result of a forgotten user password).  This exchange assumes a 
  system in key pair which the receiver generates in response to
      -- this request; set to FALSE if no archival is desired.
}

  KeyGenParameters ::= OCTET STRING


Farrell, Adams                                              [Page 22]

INTERNET-DRAFT                                         December 1996

      -- actual syntax is <<TBS>>
      -- an encryption alternative to sending the key pair has been centrally generated 
  and backed up (by a central system associated with a CA). 
   
  This exchange is very similar to send the exchange for User 
  Initialization/Certification with Centrally-Generated Encryption Key 
  Pair.  The client and CA start without a way information 
      -- about how to trust one another; 
  that is, they have no reliable shared re-generate the key pairs. 
   
4.3.2 Detailed Description 
   
  The user must (e.g. for many RSA 
      -- implementations one could send the first receive, by out-of-band means, a reference random number 
  and a secret machine-generated authorization code from tested 
      -- for primality)

<<Microsoft's PFX stuff could be re-used here?>>
3.2.7 Publication Information
Requesters may indicate that they wish the CA 
  administrator.  The on-line exchange then consists of PKI to publish a sequence of 
  KeyRecReq, KeyRecRep and PKIConfirm, which are certificate 
using the same as structure below. 

If the 
  exchange in 4.1.2 except for two differences.  First, dontPublish option is chosen, the CA does requester indicates that the 
PKI should not 
  generate (or archive) a new encryption key pair and encryption public- 
  key certificate for publish the user. Second, certificate (this may indicate that the user's entire encryption 
  key history (list of encryption public-key certificates and matching 
  encryption private keys) are sent back 
requester intends to publish 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 certificate him/herself).

If the dontCare method is chosen, the CA which will become requester indicates that the subject of PKI 
may publish the 
  cross-certificate, certificate using whatever means it chooses.

The pubLocation field, if supplied, indicates where the responding CA will become the issuer of requester would 
like the 
  cross-certificate. 
   
  The initiating CA must certificate to be "up and running" before initiating found (note that the 
  cross-certification operation. 
   
  As with registration/certification there are CHOICE within 
GeneralName includes a few possibilities 
  here. 
   
4.5.1. One-way request-response scheme: 
   
  The cross-certification scheme URL and an IP address, for example).

  PKIPublicationInfo ::= SEQUENCE {
     action     INTEGER {
                  dontPublish (0),
                  pleasePublish (1)
                },
     pubInfos  SEQUENCE OF SinglePubInfo OPTIONAL
       -- pubInfos should not be present if action is essentially "dontPublish"
       -- (if action is "pleasePublish" and pubInfos is omitted, 
       -- "dontCare" is assumed)
  }

  SinglePubInfo ::= SEQUENCE {
      pubMethod    INTEGER {
          dontCare    (0),
          x500        (1),
          web         (2)
      },
      pubLocation  GeneralName OPTIONAL
  }

3.2.8  "Full" Request Template
The following structure groups together the fields which may be sent as 
part of a one way operation, 
  that is, when successful, certification request:

  FullCertTemplates ::= SEQUENCE OF FullCertTemplate

  FullCertTemplate ::= SEQUENCE {
      certReqId              INTEGER,
      -- to match this operation results request with corresponding response
      -- (note:  must be unique over all FullCertReqs in the creation this message)


Farrell, Adams                                              [Page 23]

INTERNET-DRAFT                                         December 1996

      certTemplate           CertTemplate,
      popoSigningKey     [0] POPOSigningKey      OPTIONAL,
      archiveOptions     [1] PKIArchiveOptions   OPTIONAL,
      publicationInfo    [2] PKIPublicationInfo  OPTIONAL,
      oldCertId          [3] CertId              OPTIONAL
      -- id. of cert. which is being updated by this one new cross-certificate.
  }

If the requirement certification request is that cross- 
  certificates be created in "both directions" then each CA in turn 
  must initiate for a cross-certification operation (or use another 
  scheme). 
   
  The followings steps occur: 
   
  1.The initiating CA gathers the information required signing key pair (i.e., a request 
for a verification certificate), then the cross 
    certification request 
  2.The initiating CA creates proof of possession of the cross-certification request message 
    (CrossCertReq); 
  3.The CrossCertReq message 
private signing key is transported to demonstrated through use of the responding CA 
  4.The responding CA processes POPOSigningKey 
structure.

  POPOSigningKey ::= SEQUENCE {
      alg                 AlgorithmIdentifier,
      signature           BIT STRING
      -- the CrossCertReq; this results in signature (using "alg") on the 
    creation of a cross-certification response (CrossCertRep) message. 
  5.The CrossCertRep message is transported to DER-encoded 
      -- POPOSigningKeyInput structure given below
  }

  POPOSigningKeyInput ::= SEQUENCE {
      authInfo            CHOICE {
          sender              [0] GeneralName,
          -- from PKIHeader (used only if an authenticated identity
          -- has been established for the initiating CA 
  6.The initiating CA processes sender (e.g., a DN from a
          -- previously-issued and currently-valid certificate)
          publicKeyMAC        [1] BIT STRING
          -- used if no authenticated GeneralName currently exists for
          -- the CrossCertRep; depending sender; publicKeyMAC contains a password-based MAC
          -- (using the protectionAlg AlgId from PKIHeader) on its 
    content some looping the
          -- DER-encoded value of publicKey
      }
      publicKey           SubjectPublicKeyInfo    -- from CertTemplate
  }

On the other hand, if the certification request is for an encryption key 
pair (i.e., a request for an encryption certificate), then the proof of 
possession of the private decryption key may be required, that is, demonstrated by the 
inclusion of the private key (encrypted) in the FullCertTemplate (in the 
PKIArchivalOptions structure). Alternatively (i.e., if the private key 
is not included), the initiating CA may have to await further responses or generate return not the certificate, but an 
encrypted certificate (i.e., the certificate encrypted under a new CrossCertReq randomly-
generated symmetric key, and the symmetric key encrypted under the 
public key for this which the certification request is being made).  The 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 proves knowledge of the private decryption key to the CA by 
MACing the initiating CA. 
  2.The CrossCertRep PKIConfirm message should contain using a key derived from this symmetric 
key.  [Note that if several FullCertTemplates are included in the OOBcert of 
PKIMessage, then the 
    responding CA - uses a different symmetric key for each 
FullCertTemplate and the initiating CA should then verify this via MAC uses a key derived from the 
    "out-of-band" mechanism. concatenation 
of all these keys.]  The MACing procedure uses the PasswordBasedMac 
AlgId defined in Section 3.1.


Farrell, Adams, Ford Adams                                              [Page 30] 24]


INTERNET-DRAFT                                                 June                                         December 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

3.3 Operation-Specific Data Structures 
3.3.1 Initialization Request 
An Initialization request message (InitReq) contains an InitReqContent 
data structure which specifies 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 requested certificate(s).  Typically, 
SubjectPublicKeyInfo, KeyId, and Validity are the responder CA equipment generates template fields which 
may be supplied for each certificate requested.

  InitReqContent ::= SEQUENCE { 
      protocolEncKey      [0] SubjectPublicKeyInfo  OPTIONAL,
      fullCertTemplates       FullCertTemplates
  }

3.3.2 Initialization Response 
An Initialization response message (InitRep) contains 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 InitRepContent 
data structure which has for authentication each certificate requested a PKIStatusInfo 
field, a subject certificate, and integrity 
  purposes. This is done by generating possibly a symmetric private key based on (normally 
encrypted with a session key, which is itself encrypted with the 
  authorization code and using 
protocolEncKey).  

  InitRepContent ::= CertRepContent

3.3.3 Registration/Certification Request 

A Registration/Certification request message (CertReq) contains a 
CertReqContent data structure which specifies the symmetric key for generating Message 
  Authentication Codes (MACs) on all messages exchanged. 
   
  Serial numbers requested certificate. 

  CertReqContent ::= FullCertTemplates 

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 protocol version are used in optionally 
failure information, a subject certificate, and an encrypted private 
key. 

  CertRepContent ::= SEQUENCE { 
      caPub           [1] Certificate             OPTIONAL, 
      response            SEQUENCE OF CertResponse 
  }

  CertResponse ::= SEQUENCE { 
      certReqId           INTEGER,
      -- to match this response with corresponding request
      status              PKIStatusInfo, 
      certifiedKeyPair    CertifiedKeyPair    OPTIONAL
  }

  CertifiedKeyPair ::= SEQUENCE { 
      certificate     [0] Certificate         OPTIONAL,


Farrell, Adams                                              [Page 25]


INTERNET-DRAFT                                         December 1996

      encryptedCert   [1] EncryptedValue      OPTIONAL,
      privateKey      [2] EncryptedValue      OPTIONAL,
      publicationInfo [3] PKIPublicationInfo  OPTIONAL 
  }

Only one of the same manner as failInfo (in PKIStatusInfo) and certificate fields 
should be present in CertRepResponse (depending on the above CA-client exchanges. 
   
4.5.2.2. Detailed Description 
   
  The requester CA initiates status). For some 
status values (e.g., waiting) neither of the exchange by generating a random number 
  (requester random number). optional fields will be 
present. 

The requester CA then sends CertifiedKeyPair structure must contain either a Certificate or an 
EncryptedCert, and an optional EncryptedPrivateKey (i.e. not both a 
Certificate and EncryptedCert).

Given an EncryptedCert and the responder 
  CA relevant decryption key the message CrossReq. certificate 
may be obtained. The fields in purpose of this message are protected 
  from modification with is to allow a MAC based on CA to return the authorization code. 
   
  Upon receipt 
value of a certificate, but with the CrossReq message, constraint that only the responder intended 
recipient can obtain the actual certificate. The benefit of this 
approach is that a CA checks may reply with a certificate even in the 
  protocol version, saves absence 
of a proof that the requester random number, generates its 
  own random number (responder random number) and validates is the MAC. It 
  then generates and archives a new requester certificate end entity which 
  contains can use the requester CA public 
relevant private key and (note that the proof is signed with not obtained until the 
PKIConfirm message is received by the CA). Thus the responder CA signature private key. The responder CA responds with the message 
  CrossRep. The fields will not have to 
revoke that certificate 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 event that 
  its own system time is close to the responder CA system time, checks something goes wrong.
3.3.5 Key update request content 
For key update requests the received random numbers following syntax is used.  Typically, 
SubjectPublicKeyInfo, KeyId, and validates Validity are the MAC. It then generates 
  and archives a new responder certificate template fields which contains the responder 
  CA public 
may be supplied for each 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 to be updated. 

  KeyUpdReqContent ::= SEQUENCE { 
      protocolEncKey      [0] SubjectPublicKeyInfo  OPTIONAL, 
      fullCertTemplates   [1] FullCertTemplates     OPTIONAL 
  }

3.3.6 Key Update response content 
For key update responses the 
  random numbers, archives syntax used is identical to the responder certificate, and validates 
initialization response.

  KeyUpdRepContent ::= InitRepContent 

3.3.7 Key Recovery Request content 

For key recovery requests the 
  MAC. It writes both syntax used is identical to the 
initialization request InitReqContent.  Typically, SubjectPublicKeyInfo 
and responder certificates 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 

Farrell, Adams, Ford Adams                                              [Page 31] 26]


INTERNET-DRAFT                                                 June                                         December 1996 
   
  Directory. It then responds with its own PKIConfirm message. The

status values (e.g., waiting) none of the optional fields in this message are protected from modification with will be 
present.

  KeyRecRepContent ::= SEQUENCE { 
      status                  PKIStatusInfo,
      newSigCert          [0] Certificate                   OPTIONAL, 
      caCerts             [1] SEQUENCE OF Certificate       OPTIONAL,
      keyPairHist         [2] SEQUENCE OF CertifiedKeyPair  OPTIONAL
  }

3.3.9 Revocation Request Content 
When requesting revocation of a MAC 
  based on certificate (or several certificates) 
the authorization code. 
   
  Upon receipt following data structure is used. The name of the PKIConfirm message, the requester CA checks the 
  random numbers and validates the MAC. The requester CA writes both is 
present in the PKIHeader structure. 

  RevReqContent ::= SEQUENCE OF RevDetails

  RevDetails ::= SEQUENCE { 
      certDetails         CertTemplate, 
      -- allows requester and responder certificates to specify as much as they can about 
      -- the Directory. 
   
4.6 CA Key Pair Update 
   
  The basis of the procedure described here cert. for which revocation is that requested 
      -- (e.g. for cases in which serialNumber is not available)
      revocationReason    ReasonFlags, 
      -- from the DAM, so that 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 knows which Dist. point to use
      badSinceDate        GeneralizedTime  OPTIONAL, 
      -- indicates best knowledge of sender 
      crlEntryDetails     Extensions 
      -- requested crlEntryExtensions 
  }

3.3.10 Revocation Response Content 
The response to the 
   
  old CA public key via "out-of-band" means are most affected. It above message. If produced, this is 
  these end entities who will need access sent to the new CA public key 
  protected with 
requester of 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 revocation. (A separate revocation announcement message 
may be easily 
  achieved when these end entity's certificates expire. 
   
  The data structure used sent to protect the new and old CA public keys is 
  a standard subject of the certificate (which for which revocation was 
requested.) 

  RevRepContent ::= SEQUENCE { 
      status              PKIStatusInfo, 
      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 also contain extensions). There are 
  no new data structures required. 
   
  Notes: 
   
  1.This scheme does not make be more than one) 
  }

3.3.11 Cross certification request content 
Cross certification requests use of any of the X.509 v3 
    extensions same syntax as it for normal 
certification requests with the restriction that the key should have 
been generated by the requesting CA and should not be able sent to work even for version 1 
    certificates. The presence of the KeyIdentifier extension would 
    make 
responding CA. 

  CrossCertReqContent ::= CertReqContent 


Farrell, Adams                                              [Page 27]


INTERNET-DRAFT                                         December 1996

3.3.12 Cross certification response content 

Cross certification responses use the same syntax as for efficiency improvements. 
     
  2.While normal 
certification responses with the scheme could restriction that no encrypted private 
key can be generalized to cover cases where 
    the sent.

  CrossCertRepContent ::= CertRepContent 

3.3.13 CA Key Update Announcement content 
When a CA updates its own key pair more than once during the validity 
    period of one of its end entity's certificates, following data structure may be 
used to announce 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 event.

  CAKeyUpdAnnContent ::= SEQUENCE { 
      oldWithNew          Certificate, -- old CA public key pub signed with the new private key (the "old with new" certificate). 
       
  3.Create a certificate containing the priv 
      newWithOld          Certificate, -- new CA public key pub signed with the old private key (the "new with old" certificate). 
       
  4.Create a certificate containing the priv 
      newWithNew          Certificate  -- new CA public key pub 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 priv 
  }

3.3.14 Certificate Announcement 
This data structure may be used to announce the new CA public key so existence of 
certificates. 

Note that end entities may 
    acquire it using this structure (and the "out-of-band" mechanism. 
   
  The old CA private key CertAnn message itself) is intended to 
be used for those cases (if any) where there is then no longer required. The old CA public 
  key will however remain in use pre-existing method 
for some time. The time when publication of certificates; it is not intended to be used where, 
for example, X.500 is the old method for publication of certificates. 

  CertAnnContent ::= Certificate 

3.3.15 Revocation Announcement 
When a CA public key has revoked, or is no longer required (other than for non-repudiation) 
  will be when all end entities about to revoke, a particular certificate 
it may issue an announcement of this (possibly upcoming) event. 

  RevAnnContent ::= SEQUENCE { 
      status              PKIStatus, 
      certId              CertId, 
      willBeRevokedAt     GeneralizedTime, 
      badSinceDate        GeneralizedTime, 
      crlDetails          Extensions  OPTIONAL 
      -- extra CRL details(e.g., crl number, reason, location, etc.) 
}

A CA have acquired the new CA 
  public key via "out-of-band" means. 
   
  The "old with new" certificate should have may use such an announcement to warn (or notify) a validity period starting 
  at subject that its 
certificate is about to be (or has been) revoked. This would typically 
be used where the generation time of request for revocation did not come from the old key pair and ending at subject 
concerned.

The willBeRevokedAt field contains 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 entry will securely possess be 
added to the new CA 
  public key. 
   
  The "new with new" certificate should have relevant CRLs.

3.3.16 CRL Announcement 
3.3.17 

Farrell, Adams                                              [Page 28]


INTERNET-DRAFT                                         December 1996

When 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 issues a signature new CRL (or set of CRLs) the verifier simply(!) verifies 
  the certificate containing the public key of following data structure 
may be used to announce this event. 

  CRLAnnContent ::= SEQUENCE OF CertificateList 

3.3.18 PKI Confirmation content 
This data structure is used in three-way protocols as the signer. However, 
  once a CA final 
PKIMessage. Its content is allowed to update its key the same in all cases - actually there is no 
content since the PKIHeader carries all the required information. 

  PKIConfirmContent ::= NULL 

3.3.19 PKI Information Request content

  PKIInfoReqContent ::= BIT STRING {
      caProtEncCert       (0),
      signKeyPairTypes    (1),
      enckeyPairTypes     (2),
      preferredSymmAlg    (3),
      caKeyUpdateInfo     (4),
      currentCRL          (5)
  }

3.3.20 PKI Information Response content
  PKIInfoRepContent ::= SEQUENCE {
      caProtEncCert      [0] Certificate                      OPTIONAL,
      signKeyPairTypes   [1] SEQUENCE OF AlgorithmIdentifier  OPTIONAL,
      encKeypairTypes    [2] SEQUENCE OF AlgorithmIdentifier  OPTIONAL,
      preferredSymmAlg   [3] AlgorithmIdentifier              OPTIONAL,
      caKeyUpdateInfo    [4] CAKeyUpdAnnContent               OPTIONAL,
      currentCRL         [5] CertificateList                  OPTIONAL
  }

3.3.21 Error Message content
  ErrorMsgContent ::= SEQUENCE {
      pKIStatusInfo          PKIStatusInfo,
      errorCode              INTEGER                          OPTIONAL,
      -- implementation-specific error codes
      errorDetails           CHOICE { IA5String, BMPString }  OPTIONAL
      -- implementation-specific error details
  }

4. PKI Management functions
The PKI management functions outlined in section 1 above are a range of new 
  possibilities. These described 
in this section.

This section is split into two, the first part dealing with functions 
which are shown "mandatory" in the table below. 
   
Farrell, Adams, Ford                                           [Page 33] 
INTERNET-DRAFT                                                 June 1996 
   
            Directory contains NEW     Directory contains only OLD sense that all end-entity and OLD public keys        public key (due CA/RA 
implementations must be able to e.g. 
                                          delay provide functionality described via one 
of the transport mechanisms defined 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 section 5. This part is      In this case  Although the   In this case 
te is      the 
effectively the verifier  CA operator profile of the CA 
 
protected  standard PKI management functionality which must access   has not        operator  has 
using NEW  case where   the           updated the 
be supported.


Farrell, Adams                                              [Page 29]

INTERNET-DRAFT                                         December 1996

The second part defines "additional" functions.

Note that not updated 
public     the          directory all PKI management functions result in  directory the creation of a 
PKI message.
4.1 Mandatory Functions
4.1.1 Root CA initialisation
A newly created root CA must produce a "self-certificate" which is a 
Certificate structure with the directory profile defined for the "newWithNew" 
certificate issued following a root CA key        verifier update.

In  order to get  verifier can   and so the 
           can          the value of  verify the     verification 
           directly make the NEW CA's self certificate    will FAIL 
           verify useful to end entities which 
do not acquire this information via "out-of-band" means, the CA must 
also produce a fingerprint for its public key    directly - 
           certificat key. End entities which 
acquire this is thus 
           e without value securely via some "out-of-band" means can then 
verify the same as 
           using CA's self-certificate and hence the                  case 1. 
           directory 
 
Signer's   Case 2:      Case 4:       Case 6:        Case 8: 
certifica  In this      In this case other attributes 
contained therein.

The verifier   Although data structure used to carry the 
te fingerprint is      case the     the verifier  thinks this OOBCertHash.

The root 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 also produce an initial revocation list.

4.1.2 Root CA key        directory    without       will access    verifier can 
           in order     using the     the            verify the 
           to get update

4.1.3 Subordinate CA initialisation
From the   directory     directory,     certificate 
           value perspective of                   however the    directly - PKI management protocols the OLD                    verification   this initialisation of a 
subordinate CA 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 initialisation of an end-entity. The 
only difference is that the subordinate CA public key must also produce an initial 
revocation list.
4.1.4 CRL production
Before issuing any certificates a newly established CA (which issues 
CRLs) must produce "empty" versions of each CRL which can is to be 
periodically produced.
4.1.5 PKI information request
The above operations produce various data structures which are used in 
PKI management protocols.

When a PKI entity wishes to verify the certificate directly. This is the 
  same as acquire information about the situation where no key change has ever occurred. 
   
  Note that case 8 current status 
of a CA it may arise between send that CA a PKIInfoReq PKIMessage. The response will 
be a PKIInfoRep message.

The CA should respond to the time when request with a response providing all of 
the CA operator has 
  generated information requested by the new key pair requester. If some of the information 
cannot be provided then an error message should be returned.

The PKIInfoReq and PKIInfoRep messages are protected using a MAC based 
on shared secret information (i.e., PasswordBasedMAC) or any other 
authenticated means (if the time when end entity has an existing certificate).
4.1.6 Cross certification
The initiating CA is the CA operator stores which will become the updated attributes in subject of the directory. Case 5 can only arise if cross-
certificate, the responding CA operator has issued both will become the signer's and verifier's certificates 
  during this "gap" (the CA operator should avoid this as it leads to issuer of the failure cases described below). cross-

Farrell, Adams, Ford Adams                                              [Page 34] 30]


INTERNET-DRAFT                                                 June                                         December 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.

certificate. 

The verifier does the following: 
   
  1.Lookup initiating CA must be "up and running" before initiating the CACertificate attribute in the directory and 
    pick the appropriate value (based on validity periods) 
  2.Verify cross-
certification operation. 

As with registration/certification there are a few possibilities here. 
4.1.6.1 One-way request-response scheme: 
The cross-certification scheme is essentially a one way operation; that 
is, when successful, this is correct using operation results in the creation of one new CA key (which 
cross-certificate. If the verifier has locally). 
  3.If correct requirement is that cross- certificates be 
created in "both directions" then check the signer's certificate using the 
    old CA key. 
   
  Case 2 will arise when the each 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 turn must get access to initiate a cross-
certification operation (or use another scheme). 

This scheme is suitable where the new public key two CAs in question can already verify 
each other's signatures (they have some common points of trust) or where 
there is an out-of-band verification of the 
  CA. The verifier does origin of the following: 
   
  1.Lookup certification 
request.

The followings steps occur: 

1.The initiating CA gathers the CACertificate attribute in information required for the directory and 
    pick cross 
certification request; 
2.The initiating CA creates the appropriate value (based on validity periods). 
  2.Verify that this cross-certification request message 
(CrossCertReq); 
3.The CrossCertReq message is correct using transported to the old responding CA; 
4.The responding CA key (which processes the verifier has stored locally). 
  3.If correct then  check CrossCertReq -- this results in the signer's certificate using 
creation of a cross-certification response (CrossCertRep) message; 
5.The CrossCertRep message is transported to the new initiating CA; 
6.The initiating CA key. 
   
  Case 3 will arise when the CA operator has issued processes the verifier's 
  certificate, then changed key and then issued CrossCertRep (depending on its content 
some looping may be required; that is, the signer's 
  certificate, so it is also quite initiating CA may have to 
await further responses or generate a typical case. 
   
4.6.2.4. Failure of verification in case 6. 
   
  In this case new CrossCertReq for the 
responding CA);
7.The initiating CA has issued the verifier's PSE containing the new 
  key without updating creates a PKIConfirm message and transports it to 
the directory attributes. This means responding CA.

Notes: 

1.The CrossCertReq should contain a "complete" certification request, 
that the 
  verifier has no means to get is, all fields (including e.g. a trustworthy version of BasicConstraints extension) should 
be specified by the CA's old 
  key and so verification fails. 
   
  Note that initiating CA.
2.The CrossCertRep message should contain the failure is verification certificate 
of the responding CA operator's fault. 
   
4.6.2.5. Failure of verification in case 7. 
   
  In this case - the initiating CA has issued should then verify this via the signer's certificate protected 
"out-of-band" mechanism. 
4.1.7 End entity initialisation
As with the new key without updating the directory attributes. This 
  means that the verifier has no means to get a trustworthy version CAs, end entity's must be initialised. Initialisation of 
  the CA's new key and so end 
entities requires two steps:

      - acquisition of PKI information
      - out-of-band verification fails. 
   
  Note that the failure is again the CA operator's fault. of root-CA public key

4.1.7.1 Acquisition of PKI information
The information required is:


Farrell, Adams, Ford Adams                                              [Page 35] 31]

INTERNET-DRAFT                                                 June                                         December 1996 
   
4.6.3. Revocation

- Change of CA key 
   
  As we saw above the verification of a certificate becomes more 
  complex once current root-CA public key
- (if the certifying CA is allowed to change its key. This is also true 
  for revocation checks as the CA may have signed the CRL using not a newer 
  private key than root-CA) the one that is within certification path from 
the user's PSE. 
   
  The analysis of root CA to the alternatives is as for certificate verification. 
   
4.6.4. Example of certifying CA key update 
   
  The following example should make together with appropriate revocation 
lists
- the scheme clearer: 
   
  1.A algorithms and algorithm parameters which the certifying CA is established on 1-Jan-1997, its key pair will be used 
supports for three years (until 31-Dec-1999, party-time). 
     
   
  2.Alice gets each relevant usage

Additional information could be required (e.g. supported extensions
or CA policy information) in order to produce a new certificate valid certification request 
which will be successful. However, for one year starting 21- 
    Dec-1999 and acquires simplicity we do not mandate that 
the CA public key end entity acquires this information via the appropriate out of 
    band means. 
     
  3.Alice's PKI messages. The end 
result is simply that some certification requests may fail (e.g., if the last certificate created by the CA before 
end entity wants to generate its own encryption key but the CA key update and doesn't 
allow that).

The required information is acquired as follows:

  - the one which will expire latest. 
     
  4.The end entity sends a pKIInfoReq to the certifying CA generates its new key pair on 31-Dec-1999 and produces requesting 
(with the two certificates. The "old-with-new" certificate contains xxxxxx bits set) the information it requires;

  - the certifying CA responds with a 
    validity period from 1-Jan-1997 to 31-Dec-2000. The "new-with-old" 
    certificate pKIInfoRep message which contains 
the requested information.

4.1.8 Certificate Update
When a validity period from 1-Jan-2000 certificate is due to 31-Dec- 
    2000. The CA operator deletes expire the old private key. 
     
  5.Bob gets certified (again for a year) on 10-Jan-2000. Bob 
    also acquires relevant end entity may request 
that the new CA public key via update the appropriate "out-of- 
    band" means. 
     
  6.On 11-Jan-2000 Alice sends certificate - that is, that the CA issue a signed message to Bob. Bob's 
    verification is as described new 
certificate which differs from the previous one only in case 2 above. 
     
  7.Bob replies with a signed message, Alice's verification 
    procedure terms of PKI 
attributes (serialNumber, validity, some extensions) and is as given in case 3 above. 
     
  8.On 20-Dec-2000 Alice gets otherwise 
identical.

Two options must be catered for here, where the end entity initiates 
this operation, and where the CA initiates the operation and then 
creates a message informing the end entity of the existence of the new 
certificate.

4.2 Additional Functions

4.2.1 Cross certification
4.2.1.1 Two-way request-response scheme: 
4.2.1.1.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 and acquires 
that contains the 
    new CA public verification key via of the "out-of-band" means. 
     
  9.At midnight on 31-Dec-2000 other CA. 

Cross certification is initiated at one CA known as the responder.  The 
CA operator can delete administrator for the 
    "new-with-old" certificate from responder identifies the directory (or wherever else). 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. 


Farrell, Adams, Ford Adams                                              [Page 36] 32]


INTERNET-DRAFT                                                 June                                         December 1996 
   
  These events

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 shown used 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 
            +-- same manner as in 
the above CA-client exchanges. 

4.2.1.1.2 Detailed Description 
The requester CA established 
   
  "old-with-new" validity: 
            |---------------------------------------------->>>>>> 
  "new-with-old" validity: 
                                           |-------| 
  "new-with-new" validity: 
   
                                           |--------------->>>>>> 
   
4.7 Certificate Publication 
 
  <> 
   

4.8 Revocation Publication 
   
  <> 
  
  This is initiates the announcement of a specific revocation (which occurred as a 
  result of exchange by generating a successful revocation request/response exchange), as 
  opposed to random number 
(requester random number). The requester CA then sends 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 responder CA 
the protocol exchanges described message CrossReq. The fields in Section 4 over a TCP connection. >> 
   
5.2 Management Protocol via E-mail 
   
  << To be supplied.  This subsection will specify this message are protected from 
modification with a means for 
  conveying ASN.1-encoded messages for MAC based on 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 authorization code. 

Upon receipt of 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 CrossReq message, the messages, etc.) For now we just 
  present them as walkthroughs. 
   
  The overall scenario is as follows: A responder CA is established checks the 
protocol version, saves the requester random number, generates its own 
random number (responder random number) and an RA is 
  certified. The RA gets a "simple" end entity certified (which is 
  actually a http daemon) validates the MAC. It then 
generates and does a few operations involving this end 
  entity. A "sophisticated" end entity gets itself certified by archives a 
  second CA. The first CA asks to be cross-certified by new requester certificate which contains the second CA. 
  The second 
requester CA updates its public key pair. 
   
  We will use and is signed with the following names: 
   
  first responder CA                     cn=theCA;o=small;c=ie 
  RA                           cn=theRA;o=sse;c=ie 
  "simple" end entity          cn=httpd;o=sse;c=ie 
  second signature 
private key. The responder CA                    cn=caTWO;o=bnr;c=ca 
  "sophisticated" end entity   cn=sophisticated;o=bnr;c=ca 
   
  We will just use responds with the message CrossRep. The 
fields in this message are protected from modification with a MAC based 
on the commonName components authorization code. 

Upon receipt of the above names in CrossRep message,  the 
  text below. 
   
Farrell, Adams, Ford                                           [Page 38] 
INTERNET-DRAFT                                                 June 1996 
   
6.1 First requester CA established 
   
  theCA has the following characteristics: 
   
  - it uses RSA and MD5 for checks that 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 system time is various ways 
   
6.2 RA Certification 
   
  theRA has close to the following characteristics: 
   
  - it uses RSA responder CA system time, checks the 
received random numbers and MD5 for its own key pair 
  - it has an email address of: theRA@sse.ie 
   
  The following events occur 
   
  - theRA validates the MAC. It then generates its key pair and submits request to theCA 
  - theCA rejects this initial request (public key generated is too 
    short) 
  - theRA submits 
archives a new request 
  - theCA accepts request and issues response including responder certificate 
    (but with reduced validity period since theCA which contains the responder CA 
public key and is now in a bad 
    mood:-) 
  - theRA publishes its certificate 
   
6.3 "simple" End entity 
   
  simple has signed by 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 requester CA signature private key.  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 
requester CA responds with the message PKIConfirm. The fields in this 
message are protected from modification with a MAC based on behalf the 
authorization code. 

Upon receipt 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 the PKIConfirm message, the responder CA checks the 
random numbers, archives the responder certificate, and issues request for key 
    update to theCA 
  - theCA accepts validates the 
MAC. It writes both the request and issues response responder certificates to theRA including cert. 
  - theRA publishes certificate the 
Directory. It then responds with its own PKIConfirm message. The fields 
in this message are protected from modification with a MAC based on behalf the 
authorization code. 

Upon receipt 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 PKIConfirm message, the following characteristics: 
   
  - it deals directly with caTWO 
  - it uses DSA with SHA-1 
   
  The following events occur: 
   
  - end entity receives init. data (containing requester CA name and public key) 
  - end entity generates key pair checks the 
random numbers and submits request to CA 
  - validates the MAC. The requester CA accepts request writes both the 
requester and issues response responder certificates to end the Directory. 
4.2.2 End entity (not 
    including certificate) initialisation
As with CAs, end entities must be initialised. Initialisation of end 
entities requires two steps:

      - acquisition of PKI information
      - out-of-band verification of root-CA public key

4.2.2.1 Acquisition of PKI information
See previous section.


Farrell, Adams                                              [Page 33]


INTERNET-DRAFT                                         December 1996

4.2.2.2 Import of CA publishes certificate on behalf key fingerprint
An end entity must possess the public key of it's root CA. One method to 
achieve this is to provide the end entity 
  - with the CA's public key 
fingerprint via some secure "out-of-band" means. The end entity imports CA response 
   
6.5 Cross-certification 
   
  In order to can 
then securely use the CA's self-certificate.

The data structure used is the OOBcertHash

5. Transports 
The transport protocols specified below allow sophisticated end entities, RAs and CAs 
to use httpd theCA must pass PKI messages between them. There should be certified 
  by caTWO. 
   
  The following events occur: 
   
  - theCA issues a request no requirement for cross-certification 
specific security mechanisms to caTWO 
  - caTWO accepts be applied at this request level as the PKI 
messages should be suitably protected.

Caution should be taken that no "password" encrypted value is sent 
across a network using these protocols. If values are to be encrypted 
based on passwords then they should be transported using off-line means 
(e.g. files).
5.1 File based protocol
A file containing a PKI message should contain only the DER encoding of 
one PKI message, i.e. there should be no extraneous header or trailer 
information in the file.

Such files can be used to transport PKI messages using e.g. FTP. 
5.2 Socket based Management Protocol 
The following simple socket based protocol is to be used for transport 
of PKI messages. This protocol is suitable for cases where an end entity 
(or an RA) initiates a transaction and issues can poll to pick up the results. 

If a cross-certificate (but 
    with more restrictions than theCA had asked for) 
  - theCA publishes transaction is initiated by a PKI entity (RA or CA) then an end 
entity must either supply a listener process or be supplied with a 
polling reference (see below) in order to allow it to pick up the PKI 
message from the PKI management component.

The protocol basically assumes a listener process (on an RA or CA) which 
can accept PKI messages on a well defined port (port number TBS). 
Typically an initiator binds to this port and submits the initial PKI 
message for a given transaction ID. The responder replies with a PKI 
message and/or with a reference number to be used later when polling for 
the actual PKI message response. 

If a number of PKI response messages are to be produced for a given 
request (say if some part of the request is handled more quickly than 
another) then a new polling reference is also returned.

When the final PKI response message has been picked up by the initiator 
then no new polling reference is supplied.

The initiator of a transaction sends a "socket PKI message" to the 
recipient. The recipient responds with a similar message.



Farrell, Adams                                              [Page 34]


INTERNET-DRAFT                                         December 1996

A "socket PKI message" consists of:

      length (32-bits), flag (8-bits), value (defined below)

The length field contains the number of octets of the remainder of the 
message (i.e. number of octets of "value" plus one).

Message name
flag
value
comment




msgReq        `00'H  DER-encoded PKI message      PKI message from initiator
pollRep       `01'H  polling reference (32-bits)  poll response where no PKI 
                                                  message response ready; use 
                                                  polling reference value for 
                                                  later polling
pollReq       `02'H  polling reference (32 bits)  request for a PKI message 
                                                  response to initial message
negPollRep    `03'H  `00'H                        no further polling responses 
                                                  (i.e., transaction complete)
partialMsgRep `04'H  next polling reference       partial response to initial
                     (32-bits),                   message plus new polling
                     DER encoded PKI message      reference to use to get next
                                                  part of response
finalMsgRep   `05'H  DER encoded PKI message      final (and possibly sole) 
                                                  response to initial message
errorMsgRep   `06'H  human readable error         produced when an error is
                     message                      detected (e.g., a polling
                                                  reference is received which 
                                                  doesn't exist or is finished 
                                                  with)

Where a PKIConfirm message is to be transported (always from the 
initiator to the responder) then a msgReq message is sent and a 
negPollRep is returned.

The sequence of messages which can occur is then:

a) end entity sends msgReq and receives one of pollRep, negPollRep, 
partialMsgRep or finalMsgRep in response.
b) end entity sends pollReq message and receives one of negPollRep, 
partialMsgRep, finalMsgRep or ErrorMsgRep in response.
5.3 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. >> 


Farrell, Adams                                              [Page 35]

INTERNET-DRAFT                                         December 1996

5.4 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 

<<TBS>>

SECURITY CONSIDERATIONS 

   This entire memo is about security mechanisms. 

One cryptographic consideration is worth explicitly spelling out. In the 
protocols specified above, when an end entity is required to prove 
possession of a decryption key, it is effectively challenged 
to decrypt something (its own certificate). This scheme (and many 
others!) could be vulnerable to an attack if the possessor of the 
decryption key in question could be fooled into decrypting an arbitrary 
challenge and returning the cleartext to an attacker. Although in this 
specification a number of other failures in security are required in 
order for this attack to succeed, it is conceivable that some future 
services (e.g., notary, trusted time) could potentially be vulnerable to 
such attacks. For this reason we re-iterate the general rule that 
implementations should be very careful about decrypting arbitrary 
"ciphertext" and revealing recovered "plaintext" since such a 
practice can lead to serious security vulnerabilities.



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 K1Y 4H7 
   cadams@entrust.com 



APPENDIX A: Reasons for the presence of RAs

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). 


Farrell, Adams                                              [Page 36]


INTERNET-DRAFT                                         December 1996

  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). 


Appendix B. PKI management message profiles.

This appendix contains detailed profiles for those PKIMessages which 
must be supported by conforming implementations.

Profiles for the PKIMessages used in the following PKI management 
operations are provided:

- root CA key update
- information  request/reponse
- cross-certification (1-way)
- initial registration and certification
	- centralised scheme
	- basic authenticated scheme

<<Later revisions will extend the above to include profiles for the 
operations listed below>>

- certificate update
	- end entity initiated
	- PKI initiated
- key update
- revocation request
- certificate publcation
- CRL publication
1. General Rules for interpretation of these profiles.

1. Where fields are not mentioned in individual profiles then they 
should be absent (if OPTIONAL or DEFAULT) from the relevant 
message. For example, pvno is never mentioned since it is always 
fixed for this version of the specification.
2. Where structures occur in more than one message, they are 
separately profiled as appropriate.
3. The algorithmIdentifiers from PKIMessage structures are profiled 
separately.
4. A "special" X.500 DN is called the "NULL-DN"; this means a DN 
containing a zero-
5. 
Farrell, Adams                                              [Page 37]


INTERNET-DRAFT                                         December 1996

1. length SEQUENCE OF rdns (it's DER encoding is then `3000'H).
2. Where a GeneralName is required for a field but no suitable 
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 
(i.e. the Name field of the CHOICE is to contain a NULL-DN). 
This special value can be called a "NULL-GeneralName".
3. Where a profile omits to specify the value for a GeneralName 
then the NULL-GeneralName value is to be present in the relevant 
PKIMessage field. This occurs with the sender field of the 
PKIHeader for some messages.
4. Where any ambiguity arises due to naming of fields, the profile 
names these using a "dot" notation (e.g., 
"certTemplate.subject" means the subject field within a field 
called certTemplate).
5. Where a "SEQUENCE OF types" is part of a message, a zero-based 
array notation is used to describe fields within the SEQUENCE OF 
(e.g., FullCertTemplates[0].certTemplate.subject refers to a 
subfield of the first FullCertTemplate contained in a request 
message).
6. All PKI message exchanges (other than the centralised initial 
registration/certification scheme) require a PKIConfirm message 
to be sent by the initiating entity.  This message is not 
included in many of the profiles given below since its body is 
NULL and its header contents are clear from the context.  Any 
authenticated means can be used for the protectionAlg (e.g., 
password-based MAC, if shared secret information is known, or 
signature).


<<profiles TBS>>


Appendix C: "Compilable" ASN.1 Module


  PKIMessage ::= SEQUENCE { 
      header           PKIHeader, 
      body             PKIBody, 
      protection   [0] PKIProtection OPTIONAL,
      extraCerts   [1] SEQUENCE OF Certificate OPTIONAL


Farrell, Adams                                              [Page 38]


INTERNET-DRAFT                                         December 1996

  }

  PKIHeader ::= SEQUENCE { 
      pvno                INTEGER     { ietf-version1 (0) }, 
      sender              GeneralName, 
      -- identifies the sender
      recipient           GeneralName, 
      -- identifies the intended recipient
      messageTime     [0] GeneralizedTime        OPTIONAL, 
      -- time of production of this message (used when sender
      -- believes that the transport will be "suitable"; i.e., 
      -- that the time will still be meaningful upon receipt)
      protectionAlg   [1] AlgorithmIdentifier    OPTIONAL, 
      -- algorithm used for calculation of protection bits
      senderKID       [2] KeyIdentifier          OPTIONAL,
      recipKID        [3] KeyIdentifier          OPTIONAL,
      -- to identify specific keys used for protection
      transactionID   [4] OCTET STRING           OPTIONAL, 
      -- identifies the transaction, i.e. this will be the same in 
           -- corresponding request, response and confirmation messages
      senderNonce     [5] OCTET STRING           OPTIONAL, 
      recipNonce      [6] 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 
      freeText        [7] PKIFreeText            OPTIONAL
      -- this may be used to indicate context-specific 
      -- instructions (this field is intended for human 
      -- consumption) 
  }

  PKIFreeText ::= CHOICE { 
      iA5String  [0] IA5String, 
      bMPString  [1] BMPString
  }

  PKIBody ::= CHOICE {       -- message-specific body elements 
      ir      [0]  InitReqContent, 
      ip      [1]  InitRepContent, 
      cr      [2]  CertReqContent, 
      cp      [3]  CertRepContent, 
      kur     [4]  KeyUpdReqContent, 
      kup     [5]  KeyUpdRepContent, 
      krr     [6]  KeyRecReqContent, 
      krp     [7]  KeyRecRepContent, 
      rr      [8]  RevReqContent, 
      rp      [9]  RevRepContent, 
      ccr     [10] CrossCertReqContent, 
      ccp     [11] CrossCertRepContent, 
      ckuann  [12] CAKeyUpdAnnContent, 
      cann    [13] CertAnnContent, 


Farrell, Adams                                              [Page 39]

INTERNET-DRAFT                                         December 1996

      rann    [14] RevAnnContent, 
      crlann  [15] CRLAnnContent, 
      conf    [16] PKIConfirmContent, 
      nested  [17] NestedMessageContent,
      infor   [18] PKIInfoReqContent,
      infop   [19] PKIInfoRepContent,
      error   [20] ErrorMsgContent
  }

  PKIProtection ::= BIT STRING 

  ProtectedPart ::= SEQUENCE { 
      header    PKIHeader, 
      body      PKIBody
  }

  PasswordBasedMac ::= OBJECT IDENTIFIER

  PBMParameter ::= SEQUENCE {
      salt                OCTET STRING,
      owf                 AlgorithmIdentifier,
      -- AlgId for a One-Way Function (SHA-1 recommended)
      iterationCount      INTEGER,
      -- number of times the OWF is applied
      mac                 AlgorithmIdentifier
      -- the MAC AlgId (e.g., DES-MAC or Triple-DES-MAC [PKCS #11])
  }

  DHBasedMac ::= OBJECT IDENTIFIER

  DHBMParameter ::= SEQUENCE {
      owf                 AlgorithmIdentifier,
      -- AlgId for a One-Way Function (SHA-1 recommended)
      mac                 AlgorithmIdentifier
      -- the MAC AlgId (e.g., DES-MAC or Triple-DES-MAC [PKCS #11])
  }

  NestedMessageContent ::= ANY 
  -- This will be a PKIMessage

  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, 
      issuer     [5] Name                  OPTIONAL, 
      publicKey  [6] SubjectPublicKeyInfo  OPTIONAL, 
      issuerUID  [7] UniqueIdentifier      OPTIONAL, 


Farrell, Adams                                              [Page 40]

INTERNET-DRAFT                                         December 1996

      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 
  }

  EncryptedValue ::= SEQUENCE { 
      encValue          BIT STRING, 
      -- the encrypted value itself
      intendedAlg   [0] AlgorithmIdentifier  OPTIONAL,
      -- the intended algorithm for which the value will be used
      symmAlg       [1] AlgorithmIdentifier  OPTIONAL, 
      -- the symmetric algorithm used to encrypt the value 
      encSymmKey    [2] BIT STRING           OPTIONAL,
      -- the (encrypted) symmetric key used to encrypt the value
      keyAlg        [3] AlgorithmIdentifier  OPTIONAL 
      -- algorithm used to encrypt the symmetric key 
  }

  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 
      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 
      keyUpdateWarning       (6)
      -- update already done for the oldCertId specified in 
      -- FullCertTemplate
  }

  PKIFailureInfo ::= BIT STRING { 
  -- since we can fail in more than one way! 
      badAlg           (0), 
      badMessageCheck  (1) 
      -- more TBS
  }

  PKIStatusInfo ::= SEQUENCE {


Farrell, Adams                                              [Page 41]

INTERNET-DRAFT                                         December 1996

      status    PKIStatus, 
      failInfo  PKIFailureInfo  OPTIONAL
  }

  CertId ::= SEQUENCE { 
      issuer           GeneralName, 
      serialNumber     INTEGER 
  }

  OOBCert ::= Certificate 

  OOBCertHash ::= SEQUENCE { 
      hashAlg     [0] AlgorithmIdentifier     OPTIONAL, 
      certId      [1] CertId                  OPTIONAL, 
      hashVal         BIT STRING
      -- hashVal is calculated over DER encoding of the 
      -- subjectPublicKey field of the corresponding cert. 
  }

  PKIArchiveOptions ::= CHOICE {
      encryptedPrivKey     [0] EncryptedValue,
      -- the actual value of the private key
      keyGenParameters     [1] KeyGenParameters,
      -- parameters which allow the private key to be re-generated
      archiveRemGenPrivKey [2] BOOLEAN
      -- set to TRUE if sender wishes receiver to archive the private
      -- key of a key pair which the receiver generates in response to
      -- this request; set to FALSE if no archival is desired.
}

  KeyGenParameters ::= OCTET STRING
      -- actual syntax is <<TBS>>
      -- an alternative to sending the key is to send the information 
      -- about how to re-generate the key (e.g. for many RSA 
      -- implementations one could send the first random number tested 
      -- for primality)

  PKIPublicationInfo ::= SEQUENCE {
     action     INTEGER {
                  dontPublish (0),
                  pleasePublish (1)
                },
     pubInfos  SEQUENCE OF SinglePubInfo OPTIONAL
       -- pubInfos should not be present if action is "dontPublish"
       -- (if action is "pleasePublish" and pubInfos is omitted, 
       -- "dontCare" is assumed)
  }

  SinglePubInfo ::= SEQUENCE {
      pubMethod    INTEGER {
          dontCare    (0),
          x500        (1),


Farrell, Adams                                              [Page 42]

INTERNET-DRAFT                                         December 1996

          web         (2)
      },
      pubLocation  GeneralName OPTIONAL
  }

  FullCertTemplates ::= SEQUENCE OF FullCertTemplate

  FullCertTemplate ::= SEQUENCE {
      certReqId              INTEGER,
      -- to match this request with corresponding response
      -- (note:  must be unique over all FullCertReqs in this message)
      certTemplate           CertTemplate,
      popoSigningKey     [0] POPOSigningKey      OPTIONAL,
      archiveOptions     [1] PKIArchiveOptions   OPTIONAL,
      publicationInfo    [2] PKIPublicationInfo  OPTIONAL,
      oldCertId          [3] CertId              OPTIONAL
      -- id. of cert. which is being updated by this one
  }

  POPOSigningKey ::= SEQUENCE {
      alg                 AlgorithmIdentifier,
      signature           BIT STRING
      -- the signature (using "alg") on the DER-encoded 
      -- POPOSigningKeyInput structure given below
  }

  POPOSigningKeyInput ::= SEQUENCE {
      authInfo            CHOICE {
          sender              [0] GeneralName,
          -- from PKIHeader (used only if an authenticated identity
          -- has been established for the sender (e.g., a DN from a
          -- previously-issued and currently-valid certificate)
          publicKeyMAC        [1] BIT STRING
          -- used if no authenticated GeneralName currently exists for
          -- the sender; publicKeyMAC contains a password-based MAC
          -- (using the protectionAlg AlgId from PKIHeader) on the
          -- DER-encoded value of publicKey
      },
      publicKey           SubjectPublicKeyInfo    -- from CertTemplate
  }

  InitReqContent ::= SEQUENCE { 
      protocolEncKey      [0] SubjectPublicKeyInfo  OPTIONAL,
      fullCertTemplates       FullCertTemplates
  }

  InitRepContent ::= CertRepContent

  CertReqContent ::= FullCertTemplates 

  CertRepContent ::= SEQUENCE { 
      caPub           [1] Certificate             OPTIONAL, 


Farrell, Adams                                              [Page 43]

INTERNET-DRAFT                                         December 1996

      response            SEQUENCE OF CertResponse 
  }

  CertResponse ::= SEQUENCE { 
      certReqId           INTEGER,
      -- to match this response with corresponding request
      status              PKIStatusInfo, 
      certifiedKeyPair    CertifiedKeyPair    OPTIONAL
  }

  CertifiedKeyPair ::= SEQUENCE { 
      certificate     [0] Certificate         OPTIONAL,
      encryptedCert   [1] EncryptedValue      OPTIONAL,
      privateKey      [2] EncryptedValue      OPTIONAL,
      publicationInfo [3] PKIPublicationInfo  OPTIONAL 
  }

  KeyUpdReqContent ::= SEQUENCE { 
      protocolEncKey      [0] SubjectPublicKeyInfo  OPTIONAL, 
      fullCertTemplates   [1] FullCertTemplates     OPTIONAL 
  }

  KeyUpdRepContent ::= InitRepContent 

  KeyRecReqContent ::= InitReqContent 

  KeyRecRepContent ::= SEQUENCE { 
      status                  PKIStatusInfo,
      newSigCert          [0] Certificate                   OPTIONAL, 
      caCerts             [1] SEQUENCE OF Certificate       OPTIONAL,
      keyPairHist         [2] SEQUENCE OF CertifiedKeyPair  OPTIONAL
  }

  RevReqContent ::= SEQUENCE OF RevDetails

  RevDetails ::= SEQUENCE { 
      certDetails         CertTemplate, 
      -- allows requester 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        GeneralizedTime  OPTIONAL, 
      -- indicates best knowledge of sender 
      crlEntryDetails     Extensions 
      -- requested crlEntryExtensions 
  }

  RevRepContent ::= SEQUENCE { 
      status              PKIStatusInfo, 
      revCerts        [0] SEQUENCE OF CertId OPTIONAL, 
      -- identifies the cross-certificate 
  - theCA asks certs for which revocation was requested 


Farrell, Adams                                              [Page 44]

INTERNET-DRAFT                                         December 1996

      crls            [1] SEQUENCE OF CertificateList  OPTIONAL 
      -- the cross-certificate to resulting CRLs (there may be updated 
  - caTWO issues the more than one) 
  }

  CrossCertReqContent ::= CertReqContent 

  CrossCertRepContent ::= CertRepContent 

  CAKeyUpdAnnContent ::= SEQUENCE { 
      oldWithNew          Certificate, -- old pub signed with new cross-certificate 
  - theCA publishes the priv 
      newWithOld          Certificate, -- 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 pub signed with old priv 
      newWithNew          Certificate  -- new key pair 
  - theCA publishes its pub signed with new key (and collateral data structures) priv 
  }

  CertAnnContent ::= Certificate 

  RevAnnContent ::= SEQUENCE { 
      status              PKIStatus, 
      certId              CertId, 
      willBeRevokedAt     GeneralizedTime, 
      badSinceDate        GeneralizedTime, 
      crlDetails          Extensions  OPTIONAL 
      -- extra CRL details(e.g., crl number, reason, location, etc.) 
}

  CRLAnnContent ::= SEQUENCE OF CertificateList 

  PKIConfirmContent ::= NULL 

  PKIInfoReqContent ::= BIT STRING {
      caProtEncCert       (0),
      signKeyPairTypes    (1),
      enckeyPairTypes     (2),
      preferredSymmAlg    (3),
      caKeyUpdateInfo     (4),
      currentCRL          (5)
  }

  PKIInfoRepContent ::= SEQUENCE {
      caProtEncCert      [0] Certificate                      OPTIONAL,
      signKeyPairTypes   [1] SEQUENCE OF AlgorithmIdentifier  OPTIONAL,
      encKeypairTypes    [2] SEQUENCE OF AlgorithmIdentifier  OPTIONAL,
      preferredSymmAlg   [3] AlgorithmIdentifier              OPTIONAL,
      caKeyUpdateInfo    [4] CAKeyUpdAnnContent               OPTIONAL,
      currentCRL         [5] CertificateList                  OPTIONAL
  }

  ErrorMsgContent ::= SEQUENCE {
      pKIStatusInfo          PKIStatusInfo,
      errorCode              INTEGER                          OPTIONAL,
      -- implementation-specific error codes
      errorDetails           CHOICE { IA5String, BMPString }  OPTIONAL


Farrell, Adams, Ford Adams                                              [Page 40] 45]

INTERNET-DRAFT                                                 June                                         December 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

      -- implementation-specific error details
  }



----