[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 2510

Internet Draft                                          S. Farrell (SSE)
PKIX Working Group                                     C. Adams (Nortel)
draft-ietf-pkix-ipki3cmp-00.txt                         W. Ford (Nortel)

Expires in 6 months                                            June 1996


                   Internet Public Key Infrastructure
               Part III: Certificate Management Protocols



Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of 6 months
   and may be updated, replaced, or obsoleted by other documents at
   any time. It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za(Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

  This is the third draft of the Internet Public Key Infrastructure
  X.509 Certificate Management Protocols.  This document is based on
  sections 7, 9 and 10 of draft-ietf-pkix-ipki-00.txt.  Many changes
  have been made as a result of discussion at the Dallas IETF in
  December 1995, the Los Angeles IETF in March 1996, and discussion on
  the ietf-pkix@tandem.com mail list.  The intent of this document is to
  generate further productive discussion and to build consensus.


1. Executive Summary

  << To be supplied. >>


2. PKI Management Overview

  The PKI must be structured to be consistent with the types of
  individuals who must administer it.  Providing such administrators

Farrell, Adams, Ford                                            [Page 1]


INTERNET-DRAFT                                                 June 1996

  with unbounded choices complicates not only the software required but
  also increases the chances that a subtle mistake by an administrator
  or software developer will result in broader compromise. Similarly,
  restricting administrators with cumbersome mechanisms will cause them
  not to use the PKI.

  Management protocols are required to support on-line interactions
  between Public Key Infrastructure (PKI) components.  For example, a
  management protocol might be used between a CA and a client system
  with which a key pair is associated, or between two CAs which cross-
  certify each other.

2.1 PKI Management Model

  Before specifying particular message formats and procedures we first
  define the entities involved in PKI management and their interactions
  (in terms of the PKI management functions required).  We then group
  these functions in order to accomodate different identifiable types
  of end entities.

2.1.1. Definitions of PKI Entities

  The entities involved in PKI management include the end entity (i.e.
  the entity to be named in the subject field of a certificate) and the
  certification authority (i.e. the entity named in the issuer field of
  a certificate). A registration authority may also be involved in PKI
  management.

2.1.1.1. Subjects and End Entities

  The term "subject" is used here to refer to the entity named by the
  subject field of a certificate; when we wish to distinguish the tools
  and/or software used by the subject (e.g. a local certificate
  management module) we will use the term "subject equipment".

  It is important to note that the end entities here will include not
  only human users of applications, but also applications themselves
  (e.g. for IP security). This factor influences the protocols which
  the PKI management operations use; e.g., applications software is far
  more likely to know exactly which certificate extensions are required
  than are human users. PKI management entities are also end entities
  in the sense that they are sometimes named in the subject field of a
  certificate or cross-certificate. Where appropriate, the term "end-
  entity" will be used to refer to end entities who are not PKI
  management entities.

  All end entities require secure local access to some information -- at
  a minimum, their own name and private key, the name of a CA which is
  directly trusted by this subject and that CA's public key (or a
  digest of the public key where a self-certified version is available
  elsewhere). Implementations may use secure local storage for more
  than this minimum (e.g. the end entity's own certificate or

Farrell, Adams, Ford                                            [Page 2]


INTERNET-DRAFT                                                 June 1996

  application-specific information). The form of storage will also vary
  -- from files to tamper resistant cryptographic tokens.  Such local
  trusted storage is referred to here as the end entity's Personal
  Security Environment (PSE).

  << The PSE content is not defined further here as it is very
  dependent on equipment, et cetera. However, an interchange format for
  a generic PSE might be useful - we could consider using a CertRep
  message for this.>>

2.1.1.2. Certification Authority

  The certification authority (CA) may or may not actually be a real
  "third party" from the end entity's point of view. Quite often, the
  CA will actually belong to the same organisation as the end entities
  it supports.

  Again, we use the term CA to refer to the entity named in the issuer
  field of a certificate; when it is necessary to distinguish the
  software or hardware tools used by the CA we use the term "CA
  equipment".

  The CA equipment will often include both an "off-line" component and
  an "on-line" component, with the CA private key only available to the
  "off-line" component. This is, however, a matter for implementors
  (though it is also relevant as a policy issue).

2.1.1.3. Registration Authority

  In addition to end entities and CAs, many environments call for the
  existence of a registration authority (RA) separate from the
  certification authority. The functions which the registration
  authority may carry out will vary from case to case but may include
  personal authentication, token distribution, revocation reporting,
  name assignment, key generation, archival of key pairs, et cetera.

  This document views the RA as an optional component - when it is not
  present the CA is assumed to be able to carry out the RA's functions
  so that the PKI management protocols are the same from the end
  entity's point of view.

  Again, we distinguish, where necessary, between the RA and the tools
  used (the "RA equipment").

  Note that an RA is itself an end entity. We further assume that all
  RAs are in fact certified end entities and that the RA private key is
  usable for signing. How a particular CA equipment identifies some end
  entities as RAs is an implementation issue (so there is no special RA
  certification operation). We do not mandate that the RA is certified
  by the CA with which it is interacting at the moment (so one RA may
  work with more than one CA whilst only being certified once).

Farrell, Adams, Ford                                            [Page 3]


INTERNET-DRAFT                                                 June 1996


  In some circumstances end entities will communicate directly with a
  CA even where an RA is present. For example, for initial registration
  and/or certification the subject may use its RA, but communicate
  directly with the CA in order to refresh its certificate.

  The reasons which justify the presence of an RA can be split into
  those which are due to technical factors and those which are
  organizational in nature. Technical reasons include the following.

  -If hardware tokens are in use, then not all end entities will
   have the equipment needed to initialize these; the RA equipment can
   include the necessary functionality (this may also be a matter of
   policy).

  -Some end entities may not have the capability to publish
   certificates; again, the RA may be suitably placed for this.

  -The RA will be able to issue signed revocation requests on
   behalf of end entities associated with it, whereas the end entity may
   not be able to do this (if the key pair is completely lost).

  Some of the organisational reasons which argue for the presence of an
  RA are the following.

  -It may be more cost effective to concentrate functionality in
   the RA equipment, than to supply functionality to all end entities
   (especially if special token initialization equipment is to be used).

  -Establishing RAs within an organization can reduce the number
   of CAs required, which is sometimes desirable.

  -RAs may be better placed to identify people with their
   "electronic" names, especially if the CA is physically remote from
   the end entity.

  -For many applications there will already be in place some
   administrative structure so that candidates for the role of RA are
   easy to find (which may not be true of the CA).

2.1.2. PKI Management Requirements

  The protocols given here meet the following requirements on PKI
  management.

  2.1.2.1. PKI management must conform to ISO 9594-8 and the
      associated draft amendment (DAM)

  2.1.2.2. PKI management must conform to the other parts of this
      series.

Farrell, Adams, Ford                                            [Page 4]


INTERNET-DRAFT                                                 June 1996

  2.1.2.3. It must be possible to regularly update any key pair
      without affecting any other key pair

  2.1.2.4. The use of confidentiality in PKI management protocols must
      be kept to a minimum in order to ease regulatory problems

  2.1.2.5. PKI management protocols must allow the use of different
      industry-standard cryptographic algorithms, (specifically
      including, RSA, DSA, MD5, SHA-1) -- this means that any given CA,
      RA, or end entity may, in principal, use whichever algorithms suit
      it for its own key pair(s).

  2.1.2.6. PKI management protocols must not preclude the generation
      of key pairs by the end entity concerned, an RA, or a CA -- key
      generation may also occur elsewhere, but for the purposes of PKI
      management we can regard key generation as occurring wherever the
      key is first present at an end entity, RA or CA.

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

  2.1.2.8. PKI management protocols must support the production of
      CRLs by allowing certified end entities to make requests for the
      revocation of certificates - this must be done in such a way that
      the denial-of-service attacks which are possible are not made
      simpler.

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

  2.1.2.10. Final authority for certification creation rests with
      the CA; no RA or end entity equipment should assume that any
      certificate issued by a CA will contain what was requested -- a CA
      may alter certificate field values or may add, delete or alter
      extensions according to its operating policy; the only exception
      to this is the public key, which the CA may not modify (assuming
      that the CA was presented with the public key value). In other
      words, all PKI entities (end entities, RAs and CAs) must be
      capable of handling responses to requests for certificates in
      which the actual certificate issued is different from that
      requested -- for example, a CA may shorten the validity period
      requested.

  2.1.2.11. A graceful, scheduled change-over from one non-compromised
      CA key pair to the next must be supported (CA key update).

  2.1.2.12. A subject whose PSE contains the new CA public key
  (following a CA key update) must also be able to verify certificates
  verifiable using the old public key.

Farrell, Adams, Ford                                            [Page 5]


INTERNET-DRAFT                                                 June 1996

  2.1.2.13. End entities who directly trust the old CA key pair
      must be able to verify certificates signed using the new CA
      private key (following a CA key update).  This is required for
      situations where the old CA public key is "hardwired" into the
      end entity's cryptographic equipment (e.g., smartcard memory).

  2.1.2.14. The Functions of an RA may, in some implementations or
      environments, be carried out by the CA itself. The protocols
      should be designed so that end entities will use the same protocol
      regardless of whether the communication is with an RA or CA.

2.1.3. PKI Management Operations

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

                cert. publish        +------------+
      +---+           +------------  | End Entity |   Operations
      | C |           | 7            +------------+
      | e |  <--------+                | ^      initial
      | r |                          1 | | 2     registration/
      | t |       PKI "users"          | |       certification
      |   |                            | |      key pair recovery
      | / |                            | |      key pair update
      |   |                            | |      certificate update
      | C |                            V |      revocation request
      | R |             -------+-+-----+-+------+-+-----
      | L |   PKI management   | ^              | ^
      |   |      entities    1 | | 2          1 | | 2
      |   |                    V |              | |
      | R |             7   +------+    4       | |
      | e |   <------------ | RA   | <-----+    | |
      | p |      cert.      |      | ----+ |    | |
      | o |       publish   +------+   3 | |    | |
      | s |                              | |    | |
      | i |                              V |    V |
      | t |          8                 +------------+   9
      | o |   <------------------------| CA         |------->
      | r |                            +------------+  "out-of-band"
      | y |      cert. publish              | ^         publication
      |   |      CRL publish                | |
      +---+                                 | |    cross-certification
                                            | | 6  cross-certificate
                                            | |       update
                                            | |
                                            V |
                                          +------+
                                          | CA-2 |
                                          +------+

                           Figure 1 - PKI Entities

Farrell, Adams, Ford                                            [Page 6]


INTERNET-DRAFT                                                 June 1996


  At a high level the set of functions for which management messages
  are defined is as follows.

  -CA establishment: When establishing a new CA, certain steps are
   required (e.g., production of initial CRLs).

  -export of CA public key for "out-of-band" mechanisms: CAs must
   provide their public keys to end-entities. In order to facilitate
   interoperability between different CA and end-entity implementations
   a data structure for this purpose is required.

  -initial registration/certification: This is the process whereby a
   subject first makes itself known to a CA or RA, prior to the CA
   issuing a certificate or certificates for that user. The end result
   of this process (when it is successful) is that a CA issues a
   certificate for an end entity's public key, and returns that
   certificate to the subject and/or posts that certificate in a public
   repository. This process may, and typically will, involve multiple
   "steps", possibly including an initialization of the end entity's
   equipment. For example, the subject equipment must be securely
   initialized with the public key of a CA, to be used in validating
   certificate paths.  Furthermore, a subject typically needs to be
   initialized with its own key pair(s).

  -key pair update:  Every key pair needs to be updated regularly
   (i.e., replaced with a new key pair), and a new certificate needs to
   be issued.

  -certificate update: As certificates expire they may be "refreshed"
   if nothing relevant in the environment has changed.

  -certificate publication: Having gone to the trouble of producing
   a certificate some means for publishing it is needed.

  Note that the above three functions will often be combined.

  -key pair recovery:  As an option, user client key materials (e.g.,
   a user's private key used for decryption purposes) may be backed up
   by a CA, an RA or a key backup system associated with a CA or RA.  If
   a subject needs to recover these backed up key materials (e.g., as a
   result of a forgotten password or a lost key chain file), a
   protocol exchange may be needed to support such recovery.

  -revocation request:  An authorized person advises a CA of an
   abnormal situation requiring certificate revocation.

Farrell, Adams, Ford                                            [Page 7]


INTERNET-DRAFT                                                 June 1996

  -CA key pair update: As with end entities, CA key pairs need to
   be updated regularly; however, different mechanisms are required.

  -cross-certification:  Two CAs exchange the information necessary to
   establish cross-certificates between those CAs.

  -cross-certificate update: Similar to a normal certificate update
   but involving a cross-certificate.

  -CRL publication: As for certificates.

  Note that on-line protocols are not the only way of implementing the
  above functions.  For all functions there are off-line methods of
  achieving the same result, and this specification does not mandate
  use of on-line protocols.  For example, when hardware tokens are
  used, many of the functions may be achieved as part of the physical
  token delivery.

  Later sections define a set of standard protocols supporting the
  above operations.  The protocols for conveying these exchanges in
  different environments (on-line, E-mail, and WWW) are also specified.

  <>


3. Data Structures

  This section contains descriptions of the data structures required
  for PKI management messages. Section 4 describes constraints on their
  values and the sequence of events for each of the various PKI
  management operations. Section 5 describes how these may be
  encapsulated in various transport mechanisms.

3.1 Overall PKI Message

  PKIMessage ::= SEQUENCE {
       header         PKIHeader,
       body           PKIBody,
       protection     PKIProtection
  }

3.1.1. PKI Message Header

  All PKI messages require some header information for addressing and
  transaction identification. Some of this information will also be
  present in a transport-specific envelope; however, if the PKI message
  is signed then this information is also protected (i.e. we
  make no assumption about secure transport).

Farrell, Adams, Ford                                            [Page 8]


INTERNET-DRAFT                                                 June 1996

  The following data structure is used to contain this information:

  PKIHeader ::= SEQUENCE {
       pvno                INTEGER     { ietf-version1 (0) },
       messageType         MessageType,
       transactionID   [1] OCTET STRING           OPTIONAL,
            -- identifies the transaction, i.e. this will be the same in
            -- corresponding request, response and confirmation messages
       messageID       [2] OCTET STRING           OPTIONAL,
            -- identifies this message uniquely (if needed)
       senderNonce     [3] OCTET STRING           OPTIONAL,
       recipNonce      [4] OCTET STRING           OPTIONAL,
            -- nonces used to provide replay protection, senderNonce
            -- is inserted by the creator of this message; recipNonce
            -- is a nonce previously inserted in a related message by
            -- the intended recipient of this message
       messageTime         UTCTime                OPTIONAL,
            -- time of production of this message
       sender              GeneralName,
            -- identifies the sender for addressing purposes
       recipient           GeneralName,
            -- identifies the intended recipient for addressing purposes
       protectionAlg       AlgorithmIdentifier    OPTIONAL,
            -- to include the alg. in e.g. signature calculation
       freeText            CHOICE {
                              IA5String,
                              BNPString }         OPTIONAL,
            -- this may be used to indicate context-specific
            -- instructions (this field is intended for human
            -- consumption)
  }

  MessageType ::= INTEGER {
       InitReq      (0),  -- message asking for initialization
       InitRep      (1),  -- response to above
       CertReq      (2),  -- message asking for a cert.
       CertRep      (3),  -- response to above
       KeyUpdReq    (4),  -- msg asking for new cert for pub key
       KeyUpdRep    (5),  -- response to above
       KeyRecReq    (6),  -- msg. asking for key recovery
       KeyRecRep    (7),  -- response to above
       RevReq       (8),  -- message asking for revocation
       RevRep       (9),  -- response to above
       CrossCertReq (10), -- message asking for cross-certification
       CrossCertRep (11), -- response to above
       CAKeyUpdAnn  (12), -- announcement of CA key pair update
       CertAnn      (13), -- announcement of a certificate

Farrell, Adams, Ford                                            [Page 9]


INTERNET-DRAFT                                                 June 1996

       RevAnn       (14), -- announcement of revocation of a cert
       CRLAnn       (15), -- announcement of CRL
       PKIConfirm   (16)  -- used for confirmation in 3-way protocols
  }

  The transactionID field within the message header is required so that
  the recipient of a response message can correlate this with the
  request issued. In the case of an RA there may be many requests
  "outstanding" at a given moment. The value of this field should be
  unique from the sender's perspective in order to be useful.

  <>

3.1.2. PKI Message Body

  PKIBody ::= CHOICE {       -- message-specific body elements
       [0]  InitReqContent,
       [1]  InitRepContent,
       [2]  CertReqContent,
       [3]  CertRepContent,
       [4]  KeyUpdReqContent,
       [5]  KeyUpdRepContent,
       [6]  KeyRecReqContent,
       [7]  KeyRecRepContent,
       [8]  RevReqContent,
       [9]  RevRepContent,
       [10] CrossCertReqContent,
       [11] CrossCertRepContent,
       [12] CAKeyUpdAnnContent,
       [13] CertAnnContent,
       [14] RevAnnContent,
       [15] CRLAnnContent,
       [16] PKIConfirmContent,
  }

3.1.3. PKI Message Protection

  Some PKI messages will be protected for integrity. In that case the
  following structure is used:

  PKIProtection ::= SEQUENCE {
       alg             AlgorithmIdentifier    OPTIONAL,
            -- when both this field and the protectionAlg field of the
            -- PKIHeader are present, they must be the same
       protectionBits  BIT STRING
  }


Farrell, Adams, Ford                                           [Page 10]


INTERNET-DRAFT                                                 June 1996

  The input to the calculation of the protectionBits is the DER
  encoding of the following data structure:

  ProtectedPart ::= SEQUENCE {
       PKIHeader,
       PKIBody}

  Note that this is equivalent to the ASN.1 notation:

  PKIProtection ::= SIGNATURE SEQUENCE {
       PKIHeader,
       PKIBody}

  The protocols required for PKI management use this structure
  differently, there are four possibilities:

    - no protection: e.g. to pass an "out-of-band" CA public key
    - symmetric protection: used in some registration schemes
    - single signature protection: e.g., when an RA signs a request
    - double signature protection: e.g., when both end entity and RA
      sign a request

3.1.3.1. Unprotected PKI messages

  <>

3.1.3.2. Symmetric protection of PKI messages

  <>

3.1.3.3. Single signatures on PKI messages

  <>

3.1.3.4. Double signatures on PKI messages

  <>

  Some PKI messages may be signed twice. In this case the PKIProtection
  structure is also used as follows:

  pkix-double-sig-alg-id ::= AlgorithmIdentifier -- value TBS
            -- just an OID; no parameters


Farrell, Adams, Ford                                           [Page 11]


INTERNET-DRAFT                                                 June 1996

  The protectionBits field will contain the DER encoding of the
  following data structure:

  TwoSigProtection ::= SEQUENCE {
       firstAlgId      [0] AlgorithmIdentifier OPTIONAL,
       firstSig        BIT STRING,
       secondSigner    GeneralName,
       secondAlgId     [1] AlgorithmIdentifier OPTIONAL,
       secondSig       BIT STRING}

  Where secondSig contains the signature of the DER encoding of the
  following:

  secondSigInput ::= SEQUENCE {
       PKIHeader,
       PKIBody,
       PKIProtection, -- version from 1st signer
       GeneralName,
       AlgorithmIdentifier OPTIONAL  }


3.2 Common Data Structures

  Before specifying the specific types which may be placed in a PKIBody
  we define some useful data structures which are used in more than one
  case.

3.2.1. Requested Certificate Contents

  Various PKI management messages require that the originator of the
  message indicate some of the fields which are required to be present
  in a certificate. The CertTemplate structure allows an end entity
  or RA to specify as much as they can about the certificate they
  require. ReqCertContent is basically the same as a Certificate but
  with all fields optional.

  Note that even if the originator completely specifies the contents of
  a certificate they require, a CA is free to modify fields within the
  certificate actually issued.

  CertTemplate ::= SEQUENCE {
       version    [0] Version               OPTIONAL,
            -- used to ask for a particular syntax version
       serial     [1] INTEGER               OPTIONAL,
            -- used to ask for a particular serial number
       signingAlg [2] AlgorithmIdentifier   OPTIONAL,
            -- used to ask the CA to use this alg. for
            -- signing the cert
       subject    [3] Name                  OPTIONAL,
       validity   [4] OptionalValidity      OPTIONAL,

Farrell, Adams, Ford                                           [Page 12]


INTERNET-DRAFT                                                 June 1996

       issuer     [5] Name                  OPTIONAL,
       publicKey  [6] SubjectPublicKeyInfo  OPTIONAL,
       issuerUID  [7] UniqueIdentifier      OPTIONAL,
       subjectUID [8] UniqueIdentifier      OPTIONAL,
       extensions [9] Extensions            OPTIONAL,
  }        -- the extensions which the requester would like in the cert.

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

  CertTemplates ::= SEQUENCE OF CertTemplate

3.2.2. Encrypted Private Key

  Where private keys are sent in PKI messages the following data
  structure is used.

  EncryptedPrivKey ::= SEQUENCE {
       privKey     BitsAndAlgs,
            -- the private key encrypted
       encSymmKey  BitsAndAlgs OPTIONAL
            -- a symmetric key used to encrypt the private key
  }

  BitsAndAlgs ::= SEQUENCE {
       encKey      BIT STRING,
       encAlg [0]  AlgorithmIdentifier  OPTIONAL,
            -- algorithm used to encrypt the key
       keyAlg [1]  AlgorithmIdentifier  OPTIONAL
            -- algorithm for which the key is intended to be used
  }

  EncryptedPrivKeys ::= SEQUENCE of EncryptedPrivKey

  Use of this data structure requires that the creator and intended
  recipient are respectively able to encrypt and decrypt. Typically,
  this will mean that the end entity has been issued with a secret key
  shared with the generator of the key pair.

  If the recipient of the PKIMessage already possesses a private key
  usable for decryption, then the encSymmKey field may contain a
  session key encrypted using the recipient's public key.

3.2.3. Status codes and Failure Information for PKI messages

  All response messages will include some status information. The
  following values are defined.

  PKIStatus ::= INTEGER {
       granted                (0),
            -- you got exactly what you asked for
       grantedWithMods        (1),
            -- you got something like what you asked for; the
            -- requester is responsible for ascertaining the differences

Farrell, Adams, Ford                                           [Page 13]


INTERNET-DRAFT                                                 June 1996

       rejection              (2),
            -- you don't get it, more information elsewhere in the
            -- message
       waiting                (3),
            -- the request body part has not yet been processed,
            -- expect to hear more later
       revocationWarning      (4)
            -- this message contains a warning that a revocation is
            -- imminent
       revocationNotification (5)
            -- notification that a revocation has occurred
  }

  Responders may use the following syntax to provide more information
  about failure cases.

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

  StatusInfo ::= SEQUENCE {
       status    PKIStatus,
       failInfo  PKIFailureInfo  OPTIONAL
  }

3.2.4. Certificate Identification

  In order to identify particular certificates the following data
  structure is used.

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

  Furthermore, a list of certificates is identified as follows.

  Certs ::= SEQUENCE OF Certificate

3.2.5. Publication Information

  <>

  In order to allow requesters to indicate where and/or how
  certificates should be published, or to allow responders to indicate
  where and/or how certificates have been published, the following
  syntax is used.

  PublicationInfo ::= SEQUENCE OF SEQUENCE {
       pubMethod  OBJECT IDENTIFIER,
       pubDetails OCTET STRING OPTIONAL}

Farrell, Adams, Ford                                           [Page 14]


INTERNET-DRAFT                                                 June 1996

3.2.6. "Out-of-band" CA public key

  Each CA must be able to publish its current public key via some "out-
  of-band" means. While such mechanisms are beyond the scope of this
  document, we define data structures which can support such mechanisms.

  There are generally two methods available; either the CA directly
  publishes its public key and associated attributes, or this
  information is available via the Directory (or equivalent) and the CA
  publishes a hash of this value to allow verification of its integrity
  before use.

  OOBCert ::= Certificate

  OOBCertHash ::= SEQUENCE {
       hashAlg         AlgorithmIdentifier     OPTIONAL,
       certId          CertId                  OPTIONAL,
       hashVal         BIT STRING}
       -- hashVal is calculated over DER encoding of an entire OOBCert


3.3  Operation-Specific Data Structures

3.3.1. Initialization Request

  An Initialization request message (InitReq) contains an
  InitReqContent data structure which specifies the requested
  certificate(s).  Typically, SubjectPublicKeyInfo, KeyId, and Validity
  are the template fields which may be supplied for each certificate
  requested.

  InitReqContent ::= SEQUENCE {
       referenceNum        INTEGER,
       protocolEncKey  [0] SubjectPublicKeyInfo  OPTIONAL,
       certTemplates       CertTemplates
  }

3.3.2. Initialization Response

  An Initialization response message (InitRep) contains an
  InitRepContent data structure which has for each certificate requested
  a StatusInfo field, a subject certificate, and possibly a private key
  (encrypted with a session key, which is itself encrypted with the
  protocolEncKey).  InitRepContent also contains a CA signature
  certificate.

  InitRepContent ::= SEQUENCE {
       caSigCert           Certificate,
       response            SEQUENCE OF CertResponse
  }

Farrell, Adams, Ford                                           [Page 15]


INTERNET-DRAFT                                                 June 1996

3.3.3. Registration/Certification Request

  A Registration/Certification request message (CertReq) contains a
  CertReqContent data structure which specifies the requested
  certificate.

  CertReqContent ::= CertTemplates

3.3.4. Registration/Certification Response

  A registration response message (CertRep) contains a CertRepContent
  data structure which has a CA public key, a status value and
  optionally failure information, a subject certificate, and an
  encrypted private key.

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

  CertResponse ::= SEQUENCE {
       status              StatusInfo,
       certifiedKeyPair    CertifiedKeyPair    OPTIONAL,
  }

  CertifiedKeyPair ::= SEQUENCE {
       certificate     [1] Certificate         OPTIONAL,
       privateKey      [2] EncryptedPrivKey    OPTIONAL
  }

  Only one of the failInfo (in StatusInfo) and certificate fields should
  be present in CertRepResponse (depending on the status). For some
  status values (e.g., waiting) neither of the optional fields will be
  present.

3.3.5. Key update request content

  For key update requests the following syntax is used.  Typically,
  SubjectPublicKeyInfo, KeyId, and Validity are the template fields
  which may be supplied for each key to be updated.  As well, an
  encryption certificate, or a signature certificate, or both, would
  typically be specified in latestCerts.

  KeyUpdReqContent ::= SEQUENCE {
       endEntityName       GeneralName,
       latestCerts         SEQUENCE OF CertId,
       protocolEncKey  [1] SubjectPublicKeyInfo  OPTIONAL,
       certTemplates   [2] CertTemplates OPTIONAL
  }

Farrell, Adams, Ford                                           [Page 16]


INTERNET-DRAFT                                                 June 1996

3.3.6. Key Update response content

  For key update responses the syntax used is identical to the
  initialization response.

  KeyUpdRepContent ::= InitRepContent

3.3.7. Key Recovery Request content

  For key recovery requests the syntax used is identical to the
  initialization request InitReqContent.  Typically,
  SubjectPublicKeyInfo and KeyId are the template fields which may be
  used to supply a signature public key for which a certificate is
  required.

  KeyRecReqContent ::= InitReqContent

3.3.8. Key recovery response content

  For key recovery responses the following syntax is used.  For some
  status values (e.g., waiting) none of the optional fields will be
  present.

  KeyRecRepContent ::= SEQUENCE {
       status              StatusInfo,
       caCerts             Certs                         OPTIONAL,
       newSigCert          Certificate                   OPTIONAL,
       keyPairHist         SEQUENCE OF CertifiedKeyPair  OPTIONAL,
  }

3.3.9. Revocation Request Content

  When requesting revocation of a certificate (or several certificates)
  the following data structure is used. The name of the requestor is
  present in the PKIHeader structure.

  RevReqContent ::= SEQUENCE OF RevDetails

  RevDetails ::= SEQUENCE {
       certDetails         CertTemplate,
            -- allows requestor to specify as much as they can about
            -- the cert. for which revocation is requested
            -- (e.g. for cases in which serialNumber is not available)
       revocationReason    ReasonFlags,
            -- from the DAM, so that CA knows which Dist. point to use
       badSinceDate        UTCTime  OPTIONAL,
            -- indicates best knowledge of sender
       crlEntryDetails     Extensions}
            -- requested crlEntryExtensions

3.3.10. Revocation Response Content

  The response to the above message. If produced, this is sent to the
  requestor of the revocation. (A separate revocation announcement
  message may be sent to the subject of the certificate for which
  revocation was requested.)

Farrell, Adams, Ford                                           [Page 17]


INTERNET-DRAFT                                                 June 1996


  RevRepContent ::= SEQUENCE {
       status              StatusInfo,
       revCerts        [0] SEQUENCE OF CertId OPTIONAL,
            -- identifies the certs for which revocation was requested
       crls            [1] SEQUENCE OF CertificateList  OPTIONAL
            -- the resulting CRLs (there may be more than one)
         }

3.3.11. Cross certification request content

  Cross certification requests use the same syntax as for normal
  certification requests.

  CrossCertReqContent ::= CertReqContent

3.3.12. Cross certification response content

  Cross certification responses use the same syntax as for normal
  certification responses.

  CrossCertRepContent ::= CertRepContent

3.3.13. CA Key Update Announcement content

  When a CA updates its own key pair the following data structure may
  be used to announce this event.

  CAKeyUpdAnnContent ::= SEQUENCE {
       oldWithNew          Certificate, -- old pub signed with new priv
       newWithOld          Certificate, -- new pub signed with old priv
       newWithNew          Certificate  -- new pub signed with new priv
  }

3.3.14. Certificate Announcement

  This data structure may be used to announce the existence of
  certificates.

  Note that this structure (and the CertAnn message itself) is intended
  to be used for those cases (if any) where there is no pre-existing
  method for publication of certificates; it is not intended to be used
  where, for example, X.500 is the method for publication of
  certificates.

  CertAnnContent ::= Certificate

Farrell, Adams, Ford                                           [Page 18]


INTERNET-DRAFT                                                 June 1996

3.3.15. Revocation Announcement

  When a CA has revoked, or is about to revoke, a particular certificate
  it may issue an announcement of this (possibly upcoming) event.

  RevAnnContent ::= SEQUENCE {
       status              PKIStatus,
       certId              CertId,
       revocationTime      UTCTime,
       badSinceDate        UTCTime,
       crlEntryDetails [0] Extensions  OPTIONAL,
            -- crlEntryExtensions (e.g. reason)
       crlDetails      [1] Extensions  OPTIONAL,
            -- crlExtensions (e.g. crl number)
  }

  A CA may use such an announcement to warn (or notify) a subject that
  its certificate is about to be (or has been) revoked. This would
  typically be used where the request for revocation did not come from
  the subject concerned.

3.3.16. CRL Announcement

  When a CA issues a new CRL (or set of CRLs) the following data
  structure may be used to announce this event.

  CRLAnnContent ::= SEQUENCE OF CertificateList

3.3.17. PKI Confirmation content

  This data structure is used in three-way protocols as the final
  PKIMessage. Its content is the same in all cases - actually there is
  no content since the PKIHeader carries all the required information.

  PKIConfirmContent ::= NULL



Farrell, Adams, Ford                                           [Page 19]


INTERNET-DRAFT                                                 June 1996

4. PKI Management Operations

  The certificate management protocol exchanges defined in this section
  support management communications between client systems, each of
  which supports one or more users, and CAs.  In addition, one
  management protocol exchange is defined for use between two CAs, for
  the purpose of establishing cross-certificates. Each exchange is
  defined in terms of a sequence of messages between the two systems
  concerned.  This section defines the contents of the messages
  exchanged.

  The protocols for conveying these exchanges in different environments
  (on-line, E-mail, and WWW) are specified in Section 5.

  The protocol exchanges defined in this document are as follows.

       1.  Registration/Certification
             One-Step Registration/Certification
             User Initialization/Certification
       2.  End-Entity Key Pair Update
             Update for Client-Generated Key Pair
             Update for Centrally-Generated Key Pair
             Centrally-Initiated Key Pair Update
       3.  Encryption Key Pair Recovery
       4.  Revocation Request
       5.  Cross-Certification
       6.  CA Key Pair Update
       7.  Certificate Publication
       8.  Revocation Publication
       9.  CRL Publication
       10. Certificate Update
       11. Cross-Certificate Update

  The following notes apply to the protocol exchange descriptions:

   -In exchanges between a client system and a CA, the protocol
    exchange is initiated by the client system.  The one exception to
    this is the Centrally-Initiated Key Pair Update exchange.
   -To provide an upgrade path, a protocol version indicator is always
    included in the first message of an exchange.
   -A message type indicator is included in the protected part of all
    messages.
   -All messages include an optional transaction identifier which is
    used to assist correlation of request and response messages for
    one transaction.  This identifier is generated by the initiator of
    the exchange and will typically include the initiator's name plus
    a transaction sequence number.
   -The initial message from the client to the CA may optionally
    contain the client system time.  This is used to facilitate the
    correction of client time problems by central administrators.
   -Responses from CA to client include the CA system time.  The
    client can use this time to check that its own system time is
    within a reasonable range.
   -Random numbers are used in some of the protocols to prevent replay
    of the exchanges.

Farrell, Adams, Ford                                           [Page 20]


INTERNET-DRAFT                                                 June 1996

   -Responses can be aborted at any time. An enumerated error code is
    sent from the aborting end and can be decoded into a user readable
    error string at the other end.  Error codes are not specified in
    this version of this document.
   -Items in square brackets [] are optional.
   -In every instance in which a public key is transferred, it is
    transferred in the form of X.509 subjectPublicKeyInfo, including
    algorithm identifier and (optional) parameters.
   -When a new key pair is generated by a client, a key identifier may
    optionally be sent to the CA along with the public key for
    inclusion in the certificate.  However, the CA may override this
    value with a key identifier of its own.  If the client is
    concerned about the key identifier value used, it should check the
    new certificate.
   -Where this description refers to an encryption key pair, this
    could be a key pair for RSA key transport or could be key pair for
    key establishment using, for example, a Diffie-Hellman based
    algorithm.

4.1 Registration/Certification

  There are various approaches to this operation.

4.1.1. One-Step Registration/Certification

  For simple end entities this operation involves an out-of-band (or
  indeed implicit) request to an RA or CA. If no RA is involved then
  the CA in question simply prepares a PSE for the end entity. When an
  RA is involved the RA creates a certification request (CertReq)
  message for the end entity in question and sends this to the
  appropriate CA.

  When an RA is involved the steps required are as follows.

  1.The RA gathers the information required for the certification
    request.
  2.The RA creates the certification request message (CertReq);
    at this point the RA may provide the end entity with its PSE if
    the PSE doesn't need to contain the end entity's own
    certificate(s).
  3.The CertReq message is transported to the CA.
  4.The CA processes the CertReq; this results in the creation of a
    certification response (CertRep) message.
  5.The CertRep message is transported to the RA.
  6.The RA processes the CertRep.  Depending on its content some
    looping may be required; that is, the RA may have to await further
    responses or generate a new CertReq for this end entity <>.  Once
    the required certificates have been acquired the RA can prepare the
    end entity's PSE (assuming that the PSE contains the end entity's
    certificates).
  7.The end entity receives the PSE and if necessary verifies that the
    CA public key contained therein is correct.

Farrell, Adams, Ford                                           [Page 21]


INTERNET-DRAFT                                                 June 1996

  We impose the following constraints on the certification request
  message.

  1.The RA must provide the protectionAlg field of the PKIHeader and
    must protect the CertReq message. The name in the sender field of
    the PKIHeader must be usable when verifying the protection.
  2.The messageType field of the PKIMessage must contain the CertReq
    value.
  3.The CertReqContent supplied must contain values for the following
    fields (i.e. these are mandated for this operation):
          - version
          - subject
          - validity.
  4.If the RA does not provide the subjectPublicKeyInfo field this
    indicates that the RA is requesting a centrally-generated key pair
    and that the CA return the end entity's private key encrypted
    (using an EncPrivKey structure) for the end-entity or for the RA
    according to policy (and the type of PSE in use).
    If the RA does provide the subjectPublicKeyInfo field this does
    not mean that the RA need have generated the end entity's key
    pair, (which is an option) but simply that the RA has a "good"
    copy of the end entity's public key.

  All conforming CA implementations must be able to process any
  certification request received. Some CA implementations may however,
  only ever be able to reject requests which contain specific options
  (e.g., some CA implementations may not allow RAs to request a
  particular serial number for a certificate).

4.1.2. Initialization

4.1.2.1. End-Entity-Generated Encryption Key Pair

4.1.2.1.1. Overview of Exchange

  This protocol exchange is used to support client initialization,
  including certificate issuance, for one user, with provision for
  simultaneously establishing and certifying separate key pairs for
  digital signature and encryption (or encryption key exchange)
  purposes.  Both key pairs are generated by the client and no private
  key is exposed to the CA.  Generation and certification of the
  encryption key pair is optional.

  Prior to conducting this exchange, the user must have registered with
  the CA, using either a face-to-face registration exchange or some
  other means.

  Following registration, the CA creates a secret data item, called an
  authorization code,  and transfers this data item by out-of-band
  means to the user. The authorization code is used to establish
  authentication and integrity protection of the user
  initialization/certification on-line exchange. This is done by
  generating a symmetric key based on the authorization code and using
  this symmetric key for generating Message Authentication Codes (MACs)
  on all exchanges between client and CA.

Farrell, Adams, Ford                                           [Page 22]


INTERNET-DRAFT                                                 June 1996

  In the first two messages exchanged, the client sends its user
  signature public key (and, optionally, a client-generated encryption
  public key) to the CA and the CA returns the currently valid CA
  certificate(s). This exchange of public keys allows the client and CA
  to authenticate each other.

4.1.2.1.2. Detailed Description

  The user receives a reference number and a secret machine-generated
  authorization code from the CA administrator. Both pieces of
  information are transferred to the user in a secure manner which
  preserves their integrity and confidentiality.  The reference number
  is used to uniquely identify the client at the CA and the
  authorization code is used to secure the exchange in terms of
  integrity. The reference number is used instead of a DN to uniquely
  identify the client because a DN may be lengthy and difficult for a
  user to manually type without error.


  After the reference number and authorization code have been entered
  by the user, the client generates:

      - a client random number,
      - (if a new user signature key pair is required) a new user
        signature key pair,
      - (if a new client-generated encryption key pair is required) a
        new encryption key pair.

  The client securely stores locally any new signature private key
  and/or client-generated encryption private key.  The client then
  sends the message InitReq to the CA. The entire structure is
  protected from modification with a MAC based on the authorization
  code.

  Upon receipt of the InitReq message, if the CA recognizes the
  reference number and if the protocol version is valid, it saves the
  client random number, generates its own random number (CA random
  number), and validates the MAC.  Then for the user encryption public
  key, it creates:

      - a new certificate for the user's digital signature public key,
      - (if a new client-generated encryption key pair is required) a
        new certificate for the user's encryption public key.

  The CA responds to the client with the message InitRep. The entire
  structure is protected from modification with a MAC based on the
  authorization code.

  Upon receipt of the InitRep message, the client checks that its own
  system time is sufficiently close to the CA system time, checks the
  client random number, and validates the MAC.  The client then
  securely stores the new certificates and acknowledges the transaction
  by sending back the message PKIConfirm. The fields in this message
  are protected from modification with a MAC based on the authorization
  code.

Farrell, Adams, Ford                                           [Page 23]


INTERNET-DRAFT                                                 June 1996

  Upon receipt of the PKIConfirm message, the CA checks the random
  numbers and validates the MAC. If no errors occur, the CA archives
  the new user public-key certificate(s).

4.1.2.2. Centrally-Generated Encryption Key Pair

4.1.2.2.1. Overview of Exchange

  This protocol exchange is used to support client initialization,
  including certificate issuance, for one user, with provision for
  simultaneously establishing and certifying separate key pairs for
  digital signature and encryption (or encryption key exchange)
  purposes.  The digital signature key pair is generated by the client.
  Optionally, a new encryption key pair is generated by (and,
  optionally, backed up by) a central facility associated with the CA.

  Prior to conducting this exchange, the user must have registered with
  the CA, using either a face-to-face registration exchange or some
  other means.

  Following registration, the CA creates a secret data item, called an
  authorization code,  and transfers this data item by out-of-band
  means to the user. The authorization code is used to establish
  authentication and integrity protection of the user
  initialization/certification on-line exchange. This is done by
  generating a symmetric key based on the authorization code and using
  this symmetric key for generating Message Authentication Codes (MACs)
  on all exchanges between client and CA.

  In the first two messages exchanged, the client sends its user
  signature public key to the CA and the CA returns the currently valid
  CA certificate(s). This exchange of public keys allows the client and
  CA to authenticate each other.

  If a centrally-generated encryption key pair is to be established,
  the private key of the newly generated key pair is sent from the CA
  to the client. The client first generates a protocol encryption key
  pair and sends the public protocol encryption key to the CA. The CA
  creates a random symmetric key called the session key and encrypts
  the user encryption private key with it and then encrypts the session
  key with the public protocol encryption key it received from the
  client. The CA sends the encrypted user encryption private key and
  encrypted session key back to the client. The client uses its private
  protocol decryption key to decrypt the session key and then uses the
  session key to decrypt the encryption private key. The protocol
  encryption key pair and session key are discarded after the exchange.

Farrell, Adams, Ford                                           [Page 24]


INTERNET-DRAFT                                                 June 1996

4.1.2.2.2. Detailed Description

  The user receives a reference number and a secret machine-generated
  authorization code from the CA administrator. Both pieces of
  information are transferred to the user in a secure manner which
  preserves their integrity and confidentiality.  The reference number
  is used to uniquely identify the client at the CA and the
  authorization code is used to secure the exchange integrity-wise. The
  reference number is used instead of a DN to uniquely identify the
  client because a DN may be lengthy and difficult for a user to
  manually type without error.

  After the reference number and authorization code have been entered
  by the user, the client generates:

      - a client random number,
      - (if a new user signature key pair is required) a new user
        signature key pair,
      - (if a new centrally-generated encryption key pair is required)
        a protocol encryption key pair.

  The client securely stores locally any new signature private key
  and/or client-generated encryption private key.  The client then
  sends the message InitReq to the CA. The entire structure is
  protected from modification with a MAC based on the authorization
  code.

  Upon receipt of the InitReq message, if the CA recognizes the
  reference number and if the protocol version is valid, it saves the
  client random number, generates its own random number (CA random
  number), and validates the MAC. It then creates:

      - a new certificate for the user's digital signature public key,
      - (if a new centrally-generated encryption key pair is required)
        a session key, a new user encryption key pair, and a new
        certificate for the user encryption public key.

  The CA responds to the client with the message  InitRep. If a new
  centrally-generated encryption key pair is being generated, the user
  encryption private key is encrypted using the session key and the
  session key is encrypted with the protocol encryption public key. The
  entire structure is protected from modification with a MAC based on
  the authorization code.

  Upon receipt of the InitRep structure, the client checks that its own
  system time is sufficiently close to the CA system time, checks the
  client random number, and validates the MAC.  If a new centrally-
  generated encryption key pair is included, the client decrypts the
  encryption private key.  The client then securely stores the new
  certificates and encryption private key (if present) and acknowledges
  the transaction by sending back the message PKIConfirm. The fields in
  this message are protected from modification with a MAC based on the
  authorization code.

Farrell, Adams, Ford                                           [Page 25]


INTERNET-DRAFT                                                 June 1996

  Upon receipt of the PKIConfirm message, the CA checks the random
  numbers and validates the MAC. If no errors occur, the CA archives
  the new user public-key certificate(s) and (if there is a new
  centrally-generated encryption key pair and key recovery is to be
  supported) the encryption private key.

4.2 End Entity Key Pair Update

4.2.1. End-Entity-Generated Key Pair(s)

4.2.1.1. Overview of Exchange

  This exchange is used to update the signature key pair and/or client-
  generated encryption key pair of a user, (e.g., as a result of
  routine cryptoperiod expiry).


  A user must have a valid signature key pair in order to do this
  exchange. It is up to the client to determine when a new signature
  key pair should be generated; this has to be done prior to the
  expiration of its signature public-key certificate.

  A key pair update request from a client is digitally signed using the
  original user signature private key, this signature being verifiable
  using an existing signature certificate.  If the key pair update is
  for a new user digital signature key, then the client signs the
  request message once more (including the first signature), this time
  using the new signature private key. The reason for this second
  signature is to prove to the CA that the client possesses both the
  new and old private keys.

  The request is verified at the CA by using the matching user
  signature public key.  A protocol signature key pair is used to
  authenticate messages from the CA to the client.  CA responses are
  signed with the protocol signature private key.

  A CA response is validated at the client by using a protocol
  signature public-key certificate which is included in the CA
  response. The protocol signature public-key certificate can be
  validated by using the CA certificate stored at the client. A new
  user initialization (as in Section 4.1) or key pair recovery (as in
  Section 4.5) must be done if the user signature key pair becomes
  invalid.

Farrell, Adams, Ford                                           [Page 26]


INTERNET-DRAFT                                                 June 1996

  In some client system implementations, local key materials are stored
  in an encrypted key data disk file. A user may have several copies of
  this key data file on different computers. It is possible that a key
  update could occur and the user could forget to copy the updated key
  data file to all the computers they use. To help keep the client
  using the latest keys, the client sends the CA the serial number of
  the latest user signature public-key certificate it has in the key
  update request.  Serial numbers are sent so that the CA can check if
  the client has the latest key pair. If the client does not have the
  latest signature private key and the signature public-key certificate
  serial number is equal to that of a previous certificate, the CA
  sends back an error code which indicates that the client has an old
  version of the key data file. After this, the client can either find
  the latest key data file or, if that fails, initiate a key recovery
  exchange.

4.2.1.2. Detailed Description

  The client initiates the key update exchange by creating a new
  signature and/or encryption key pair and generating a random number
  (client random number). The client then sends the message
  KeyUpdReq to the CA . The fields in this message are protected from
  modification and authenticated by a digital signature using the pre-
  existing user signature private key.  If the update includes a new
  signature key pair, the result is additionally signed using the new
  user signature private key.

  Upon receipt of the KeyUpdReq message, the CA checks the protocol
  version, checks the serial number, saves the client random number,
  generates its own random number (CA random number) and verifies the
  signature using the previous user verification key which is archived
  at the CA. If a user digital signature key pair is being updated, the
  CA also checks the second signature. It then generates new user
  signature and/or encryption public-key certificate(s). The CA
  responds with the message KeyUpdRep. The fields in this message are
  protected from modification and authenticated by a digital signature
  using the CA protocol signature private key.

  Upon receipt of the KeyUpdReq message,  the client verifies the
  digital signature using the protocol verification key contained in
  the protocol signature public-key certificate, checks that its own
  system time is close to the CA system time, and checks the received
  client random number. The client then securely stores locally the new
  user public-key certificate(s). It responds with the message
  PKIConfirm. The fields in this message are protected from
  modification and authenticated by a digital signature using the pre-
  existing user signature private key.

  Upon receipt of the PKIConfirm message, the CA checks that the client
  and CA random numbers are the same as the ones initially generated,
  and verifies the received signature using the previous user signature
  public key which is archived at the CA. The CA then archives the new
  user public-key certificate(s) and updates its data stores to reflect
  the new status of the user.

Farrell, Adams, Ford                                           [Page 27]


INTERNET-DRAFT                                                 June 1996

4.2.2. Centrally-Generated Encryption Key Pair

4.2.2.1. Overview of Exchange

  This exchange is used to update the encryption key pair of a user,
  under the assumption that encryption key pairs are generated (and,
  optionally, backed up) centrally. A user must have a valid signature
  key pair in order to do this exchange. It is up to the client to
  determine when a new encryption key pair should be generated; this
  must be done some time before the expiration date in its encryption
  public-key certificate.

4.2.2.2. Detailed Description

  The client initiates the exchange by generating a random number
  (client random number) and a protocol encryption key pair. The client
  then sends the CA the message KeyUpdReq. The fields in this message
  are protected from modification and authenticated by a digital
  signature using the latest user signature private key.

  Upon receipt of the KeyUpdReq message, the CA checks the protocol
  version, checks the serial numbers, saves the client random number,
  generates its own random number (CA random number), generates a

  session key, and verifies the received signature using the latest
  user signature public key which is archived at the CA. It then
  generates a new end-user encryption key pair and encryption public-
  key certificate for the user. In the case where the encryption public-
  key certificate serial number is the second latest, the CA does not
  generate any keys and uses the latest encryption public-key
  certificate and encryption private key that it has. The CA responds
  with the message KeyUpdRep. In this message, the new or latest
  encryption private key is encrypted with the session key and the
  session key is encrypted with the protocol encryption key. The fields
  in this message are protected from modification and authenticated by
  a digital signature using the protocol signature private key.

  Upon receipt of the KeyUpdRep message, the client verifies the
  digital signature using the protocol signature public-key
  certificate, makes sure its own system time is close to the CA system
  time, and checks the received client random number. The client then
  decrypts the new or latest encryption private key and securely stores
  locally the new or latest user encryption public-key certificate and
  encryption private key.  It responds with the message PKIConfirm. The
  fields in this message are protected from modification and
  authenticated by a digital signature using the latest user signature
  private key.

  Upon receipt of the PKIConfirm message, the CA checks that the client
  and CA random numbers are correct and verifies the signature using
  the latest user signature public key which is archived at the CA. If
  no errors occur, the CA archives the new user encryption public-key
  certificate and encryption private key, and updates its data stores
  to reflect the new status of the user.

Farrell, Adams, Ford                                           [Page 28]


INTERNET-DRAFT                                                 June 1996

4.2.3. Centrally-Initiated Key Pair Update

4.2.3.1. Overview of Exchange

  This exchange is used to update the encryption key pair of an user,
  under the assumption that encryption key pairs are generated (and,
  optionally, backed up) centrally. This exchange differs from the
  preceding exchange (Key Pair Update for Centrally-Generated
  Encryption Key Pair) in that the exchange is initiated by the CA
  rather than the client.

4.2.3.2. Detailed Description

  << To be supplied >>

4.3 Encryption Key Pair Recovery

4.3.1 Overview of Exchange

  This protocol exchange is used to support recovery in the event that
  a client no longer has a valid signature key pair (due to expiration
  or revocation), or client system key materials have been lost (e.g.,
  as a result of a forgotten user password).  This exchange assumes a
  system in which an encryption key pair has been centrally generated
  and backed up (by a central system associated with a CA).

  This exchange is very similar to the exchange for User
  Initialization/Certification with Centrally-Generated Encryption Key
  Pair.  The client and CA start without a way to trust one another;
  that is, they have no reliable shared key pairs.

4.3.2 Detailed Description

  The user must first receive, by out-of-band means, a reference number
  and a secret machine-generated authorization code from the CA
  administrator.  The on-line exchange then consists of a sequence of
  KeyRecReq, KeyRecRep and PKIConfirm, which are the same as the
  exchange in 4.1.2 except for two differences.  First, the CA does not
  generate (or archive) a new encryption key pair and encryption public-
  key certificate for the user. Second, the user's entire encryption
  key history (list of encryption public-key certificates and matching
  encryption private keys) are sent back to the client with KeyRecRep.

Farrell, Adams, Ford                                           [Page 29]


INTERNET-DRAFT                                                 June 1996

4.4 Revocation Request

4.4.1 Overview of Exchange

  This protocol exchange is used to support a revocation request from a
  user or other authorized party.

4.4.2 Detailed Description

  << To be supplied >>

4.5 Cross-Certification

  The initiating CA is the CA which will become the subject of the
  cross-certificate, the responding CA will become the issuer of the
  cross-certificate.

  The initiating CA must be "up and running" before initiating the
  cross-certification operation.

  As with registration/certification there are a few possibilities
  here.

4.5.1. One-way request-response scheme:

  The cross-certification scheme is essentially a one way operation,
  that is, when successful, this operation results in the creation of
  one new cross-certificate. If the requirement is that cross-
  certificates be created in "both directions" then each CA in turn
  must initiate a cross-certification operation (or use another
  scheme).

  The followings steps occur:

  1.The initiating CA gathers the information required for the cross
    certification request
  2.The initiating CA creates the cross-certification request message
    (CrossCertReq);
  3.The CrossCertReq message is transported to the responding CA
  4.The responding CA processes the CrossCertReq; this results in the
    creation of a cross-certification response (CrossCertRep) message.
  5.The CrossCertRep message is transported to the initiating CA
  6.The initiating CA processes the CrossCertRep; depending on its
    content some looping may be required, that is, the initiating CA
    may have to await further responses or generate a new CrossCertReq
    for this end entity <>

  Notes:

  1.The CrossCertReq should contain a "complete" certification
    request, that is, all fields (including e.g. a BasicConstraints
    extension) should be specified by the initiating CA.
  2.The CrossCertRep message should contain the OOBcert of the
    responding CA - the initiating CA should then verify this via the
    "out-of-band" mechanism.

Farrell, Adams, Ford                                           [Page 30]


INTERNET-DRAFT                                                 June 1996

4.5.2. Two-way request-response scheme:


4.5.2.1. Overview of Exchange

  This cross certification exchange allows two CAs to simultaneously
  certify each other. This means that each CA will create a certificate
  that contains the CA verification key of the other CA.

  Cross certification is initiated at one CA known as the responder.
  The CA administrator for the responder identifies the CA it wants to
  cross certify and the responder CA equipment generates an
  authorization code. The responder CA administrator passes this
  authorization code by out-of-band means to the requester CA
  administrator. The requester CA administrator enters the
  authorization code at the requester CA in order to initiate the on-
  line exchange.

  The authorization code is used for authentication and integrity
  purposes. This is done by generating a symmetric key based on the
  authorization code and using the symmetric key for generating Message
  Authentication Codes (MACs) on all messages exchanged.

  Serial numbers and protocol version are used in the same manner as in
  the above CA-client exchanges.

4.5.2.2. Detailed Description

  The requester CA initiates the exchange by generating a random number
  (requester random number). The requester CA then sends the responder
  CA the message CrossReq. The fields in this message are protected
  from modification with a MAC based on the authorization code.

  Upon receipt of the CrossReq message, the responder CA checks the
  protocol version, saves the requester random number, generates its
  own random number (responder random number) and validates the MAC. It
  then generates and archives a new requester certificate which
  contains the requester CA public key and is signed with the responder
  CA signature private key. The responder CA responds with the message
  CrossRep. The fields in this message are protected from modification
  with a MAC based on the authorization code.

  Upon receipt of the CrossRep message,  the requester CA checks that
  its own system time is close to the responder CA system time, checks
  the received random numbers and validates the MAC. It then generates
  and archives a new responder certificate which contains the responder
  CA public key and is signed by the requester CA signature private
  key.  The requester CA responds with the message PKIConfirm. The
  fields in this message are protected from modification with a MAC
  based on the authorization code.

  Upon receipt of the PKIConfirm message, the responder CA checks the
  random numbers, archives the responder certificate, and validates the
  MAC. It writes both the request and responder certificates to the

Farrell, Adams, Ford                                           [Page 31]


INTERNET-DRAFT                                                 June 1996

  Directory. It then responds with its own PKIConfirm message. The
  fields in this message are protected from modification with a MAC
  based on the authorization code.

  Upon receipt of the PKIConfirm message, the requester CA checks the
  random numbers and validates the MAC. The requester CA writes both
  the requester and responder certificates to the Directory.

4.6 CA Key Pair Update

  The basis of the procedure described here is that the CA protects its
  new public key using its previous private key and vice versa. Thus
  when a CA updates its key pair it must generate two new cACertificate
  attribute values if certificates are made available using an X.500
  directory.

  When a CA changes its key pair those entities who have acquired the

  old CA public key via "out-of-band" means are most affected. It is
  these end entities who will need access to the new CA public key
  protected with the old CA private key. However, they will only require
  this for a limited period (until they have acquired the new CA public
  key via the "out-of-band" mechanism). This will typically be easily
  achieved when these end entity's certificates expire.

  The data structure used to protect the new and old CA public keys is
  a standard certificate (which may also contain extensions). There are
  no new data structures required.

  Notes:

  1.This scheme does not make use of any of the X.509 v3
    extensions as it should be able to work even for version 1
    certificates. The presence of the KeyIdentifier extension would
    make for efficiency improvements.

  2.While the scheme could be generalized to cover cases where
    the CA updates its key pair more than once during the validity
    period of one of its end entity's certificates, this generalization
    seems of dubious value. This means that the validity period of a CA
    key pair must be greater than the validity period of any
    certificate issued by that CA using that key pair.

  3.This scheme forces end entities to acquire the new CA public
    key on the expiry of the last certificate they owned which was
    signed with the old CA private key (via the "out-of-band" means).
    Certificate and/or key update operations occurring at other times
    do not necessarily require this (depending on the end entity's
    equipment).

Farrell, Adams, Ford                                           [Page 32]


INTERNET-DRAFT                                                 June 1996

4.6.1. CA Operator actions

  To change the key of the CA, the CA operator does the following:

  1.Generate a new key pair.

  2.Create a certificate containing the old CA public key
    signed with the new private key (the "old with new" certificate).

  3.Create a certificate containing the new CA public key
    signed with the old private key (the "new with old" certificate).

  4.Create a certificate containing the new CA public key
    signed with the new private key (the "new with new" certificate).

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

  6.Export the new CA public key so that end entities may
    acquire it using the "out-of-band" mechanism.

  The old CA private key is then no longer required. The old CA public
  key will however remain in use for some time. The time when the old
  CA public key is no longer required (other than for non-repudiation)
  will be when all end entities of this CA have acquired the new CA
  public key via "out-of-band" means.

  The "old with new" certificate should have a validity period starting
  at the generation time of the old key pair and ending at the time at
  which the CA will next update its key pair.

  The "new with old" certificate should have a validity period starting
  at the generation time of the new key pair and ending at the time by
  which all end entities of this CA will securely possess the new CA
  public key.

  The "new with new" certificate should have a validity period starting
  at the generation time of the new key pair and ending at the time at
  which the CA will next update its key pair.

  <>

4.6.2. Verifying Certificates.

  <>

  Normally when verifying a signature the verifier simply(!) verifies
  the certificate containing the public key of the signer. However,
  once a CA is allowed to update its key there are a range of new
  possibilities. These are shown in the table below.

Farrell, Adams, Ford                                           [Page 33]


INTERNET-DRAFT                                                 June 1996

            Directory contains NEW     Directory contains only OLD
              and OLD public keys        public key (due to e.g.
                                          delay in publication)

               PSE      PSE Contains  PSE Contains    PSE Contains
            Contains     OLD public    NEW public      OLD public
           NEW public       key            key            key
               key

Signer's   Case 1:      Case 3:       Case 5:        Case 7:
certifica  This is      In this case  Although the   In this case
te is      the          the verifier  CA operator    the CA

protected  standard     must access   has not        operator  has
using NEW  case where   the           updated the    not updated
public     the          directory in  directory the  the directory
key        verifier     order to get  verifier can   and so the
           can          the value of  verify the     verification
           directly     the NEW       certificate    will FAIL
           verify the   public key    directly -
           certificat                 this is thus
           e without                  the same as
           using the                  case 1.
           directory

Signer's   Case 2:      Case 4:       Case 6:        Case 8:
certifica  In this      In this case  The verifier   Although the
te is      case the     the verifier  thinks this    CA operator
protected  verifier     can directly  is the         has not
using OLD  must         verify the    situation of   updated the
public     access the   certificate   case 2 and     directory the
key        directory    without       will access    verifier can
           in order     using the     the            verify the
           to get the   directory     directory,     certificate
           value of                   however the    directly -
           the OLD                    verification   this is thus
           public key                 will FAIL      the same as
                                                     case 4.

4.6.2.1. Verification in cases 1, 4, 5 and 8.

  In these cases the verifier has a local copy of the CA public key
  which can be used to verify the certificate directly. This is the
  same as the situation where no key change has ever occurred.

  Note that case 8 may arise between the time when the CA operator has
  generated the new key pair and the time when the CA operator stores
  the updated attributes in the directory. Case 5 can only arise if the
  CA operator has issued both the signer's and verifier's certificates
  during this "gap" (the CA operator should avoid this as it leads to
  the failure cases described below).

Farrell, Adams, Ford                                           [Page 34]


INTERNET-DRAFT                                                 June 1996

4.6.2.2. Verification in case 2.

  In case 2 the verifier must get access to the old public key of the
  CA. The verifier does the following:

  1.Lookup the CACertificate attribute in the directory and
    pick the appropriate value (based on validity periods)
  2.Verify that this is correct using the new CA key (which
    the verifier has locally).
  3.If correct then check the signer's certificate using the
    old CA key.

  Case 2 will arise when the CA operator has issued the signer's
  certificate, then changed key and then issued the verifier's
  certificate, so it is quite a typical case.

4.6.2.3. Verification in case 3.

  In case 3 the verifier must get access to the new public key of the
  CA. The verifier does the following:

  1.Lookup the CACertificate attribute in the directory and
    pick the appropriate value (based on validity periods).
  2.Verify that this is correct using the old CA key (which
    the verifier has stored locally).
  3.If correct then  check the signer's certificate using
    the new CA key.

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

4.6.2.4. Failure of verification in case 6.

  In this case the CA has issued the verifier's PSE containing the new
  key without updating the directory attributes. This means that the
  verifier has no means to get a trustworthy version of the CA's old
  key and so verification fails.

  Note that the failure is the CA operator's fault.

4.6.2.5. Failure of verification in case 7.

  In this case the CA has issued the signer's certificate protected
  with the new key without updating the directory attributes. This
  means that the verifier has no means to get a trustworthy version of
  the CA's new key and so verification fails.

  Note that the failure is again the CA operator's fault.

Farrell, Adams, Ford                                           [Page 35]


INTERNET-DRAFT                                                 June 1996

4.6.3. Revocation - Change of CA key

  As we saw above the verification of a certificate becomes more
  complex once the CA is allowed to change its key. This is also true
  for revocation checks as the CA may have signed the CRL using a newer
  private key than the one that is within the user's PSE.

  The analysis of the alternatives is as for certificate verification.

4.6.4. Example of CA key update

  The following example should make the scheme clearer:

  1.A CA is established on 1-Jan-1997, its key pair will be used
    for three years (until 31-Dec-1999, party-time).


  2.Alice gets a new certificate valid for one year starting 21-
    Dec-1999 and acquires the CA public key via the appropriate out of
    band means.

  3.Alice's is the last certificate created by the CA before the
    CA key update and is the one which will expire latest.

  4.The CA generates its new key pair on 31-Dec-1999 and produces
    the two certificates. The "old-with-new" certificate contains a
    validity period from 1-Jan-1997 to 31-Dec-2000. The "new-with-old"
    certificate contains a validity period from 1-Jan-2000 to 31-Dec-
    2000. The CA operator deletes the old private key.

  5.Bob gets certified (again for a year) on 10-Jan-2000. Bob
    also acquires the new CA public key via the appropriate "out-of-
    band" means.

  6.On 11-Jan-2000 Alice sends a signed message to Bob. Bob's
    verification is as described in case 2 above.

  7.Bob replies with a signed message, Alice's verification
    procedure is as given in case 3 above.

  8.On 20-Dec-2000 Alice gets a new certificate and acquires the
    new CA public key via the "out-of-band" means.

  9.At midnight on 31-Dec-2000 the CA operator can delete the
    "new-with-old" certificate from the directory (or wherever else).

Farrell, Adams, Ford                                           [Page 36]


INTERNET-DRAFT                                                 June 1996

  These events are shown in the time-line diagram below.

  1996      1997      1998      1999      2000     2001    year
  ----------+---------------------------+-+-+----+-+----->>
            |                           | | |    | |
            |                           | | |    | |
            |                           | | |    | +-- "new-with-old"
            |                           | | |    |     deleted
            |                           | | |    |
            |                           | | |    +-- Alice updated
            |                           | | |
            |                           | | +-- Bob certified
            |                           | |
            |                           | +-- CA key update
            |                           |
            |                           +-- Alice certified
            +-- CA established

  "old-with-new" validity:
            |---------------------------------------------->>>>>>
  "new-with-old" validity:
                                           |-------|
  "new-with-new" validity:

                                           |--------------->>>>>>

4.7 Certificate Publication

  <>


4.8 Revocation Publication

  <>

  This is the announcement of a specific revocation (which occurred as a
  result of a successful revocation request/response exchange), as
  opposed to the publication of an actual CRL.

4.9 CRL Publication

  <>

4.10 Certificate Update

  <>

4.11 Cross-Certificate Update

  <>

Farrell, Adams, Ford                                           [Page 37]


INTERNET-DRAFT                                                 June 1996

5. Transports

5.1 On-line Management Protocol

  << To be supplied.  This subsection will specify a means for
  conveying ASN.1-encoded messages for the protocol exchanges described
  in Section 4 over a TCP connection. >>

5.2 Management Protocol via E-mail

  << To be supplied.  This subsection will specify a means for
  conveying ASN.1-encoded messages for the protocol exchanges described
  in Section 4 via Internet mail. >>

5.3 Management Protocol via HTTP

  << To be supplied.  This subsection will specify a means for
  conveying ASN.1-encoded messages for the protocol exchanges described
  in Section 4 over WWW browser-server links, employing HTTP or related
  WWW protocols. >>


6. Samples

  The following samples will be further elaborated in later drafts
  (which will include encodings for the messages, etc.) For now we just
  present them as walkthroughs.

  The overall scenario is as follows: A CA is established and an RA is
  certified. The RA gets a "simple" end entity certified (which is
  actually a http daemon) and does a few operations involving this end
  entity. A "sophisticated" end entity gets itself certified by a
  second CA. The first CA asks to be cross-certified by the second CA.
  The second CA updates its key pair.

  We will use the following names:

  first CA                     cn=theCA;o=small;c=ie
  RA                           cn=theRA;o=sse;c=ie
  "simple" end entity          cn=httpd;o=sse;c=ie
  second CA                    cn=caTWO;o=bnr;c=ca
  "sophisticated" end entity   cn=sophisticated;o=bnr;c=ca

  We will just use the commonName components of the above names in the
  text below.

Farrell, Adams, Ford                                           [Page 38]


INTERNET-DRAFT                                                 June 1996

6.1 First CA established

  theCA has the following characteristics:

  - it uses RSA and MD5 for its own key pair
  - it has the following contact points available:
          theCA@small.ie for mail
          http://www.small.ie/theCA for http
          ftp://ftp.small.ie/pub/theCA for ftp
          cacontact.theCA.small.ie for TCP/IP
          cn=theCA;o=small;c=ie for X.500
  - its key pair will be valid for two years
  - it is established on Jan. 1st 1997

  The following (protocol visible) events occur:

  - theCA generates its initial key pair and publishes this in various
    ways
  - theCA publishes its initial CRL is various ways

6.2 RA Certification

  theRA has the following characteristics:

  - it uses RSA and MD5 for its own key pair
  - it has an email address of: theRA@sse.ie

  The following events occur

  - theRA generates its key pair and submits request to theCA
  - theCA rejects this initial request (public key generated is too
    short)
  - theRA submits a new request
  - theCA accepts request and issues response including certificate
    (but with reduced validity period since theCA is now in a bad
    mood:-)
  - theRA publishes its certificate

6.3 "simple" End entity

  simple has the following characteristics:

  - it only needs a key pair for signing (i.e. no encryption)
  - it is an http daemon

Farrell, Adams, Ford                                           [Page 39]


INTERNET-DRAFT                                                 June 1996

  The following events occur:

  - theRA generates key pair; sends request to theCA on behalf of httpd
  - theRA forwards certification information to httpd
  - theRA publishes certificate on behalf of httpd
  - httpd (i.e., its administrator) imports certification information
  - theRA issues certificate update request to theCA
  - theCA sends response to theRA including new certificate
  - theRA publishes new certificate
  - theRA generates new key pair for httpd and issues request for key
    update to theCA
  - theCA accepts request and issues response to theRA including cert.
  - theRA publishes certificate on behalf of httpd
  - theRA forwards certification information to httpd
  - theRA asks for httpd's certificate to be revoked
  - theCA revokes httpd's certificate and publishes the new CRL

6.4 The "sophisticated" end entity

  sophisticated has the following characteristics:

  - it deals directly with caTWO
  - it uses DSA with SHA-1

  The following events occur:

  - end entity receives init. data (containing CA name and public key)
  - end entity generates key pair and submits request to CA
  - CA accepts request and issues response to end entity (not
    including certificate)
  - CA publishes certificate on behalf of end entity
  - end entity imports CA response

6.5 Cross-certification

  In order to allow sophisticated to use httpd theCA must be certified
  by caTWO.

  The following events occur:

  - theCA issues a request for cross-certification to caTWO
  - caTWO accepts this request and issues a cross-certificate (but
    with more restrictions than theCA had asked for)
  - theCA publishes the cross-certificate
  - theCA asks for the cross-certificate to be updated
  - caTWO issues the new cross-certificate
  - theCA publishes the new cross-certificate

6.6 CA Key Update

  Eventually (in late 1998) theCA decides to update its key pair.

  The following events occur:

  - theCA generates a new key pair
  - theCA publishes its new key (and collateral data structures)

Farrell, Adams, Ford                                           [Page 40]

INTERNET-DRAFT                                                 June 1996

7. Security Considerations

   This entire memo is about security mechanisms.





Authors' Addresses

   Stephen Farrell
   Software and Systems Engineering Ltd.
   Fitzwilliam Court
   Leeson Close
   Dublin 2
   IRELAND
   stephen.farrell@sse.ie

   Carlisle Adams
   Nortel Secure Networks
   PO Box 3511, Station C
   Ottawa, Ontario
   Canada KY 4H7
   cadams@bnr.ca

   Warwick Ford
   Nortel Secure Networks
   PO Box 3511, Station C
   Ottawa, Ontario
   Canada KY 4H7
   wford@bnr.ca


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/