Internet Draft                                                   C. AdamsPKIX Working Group                                          Entrust, Inc.November, 2002                                                 S. FarrellExpires in 6 Months                                Baltimore Technologies                Internet X.509 Public Key Infrastructure                    Certificate Management Protocols                   <draft-ietf-pkix-rfc2510bis-07.txt>Status of this Memo      This document is an Internet-Draft and is in full conformance with   all provisions of Section 10 of RFC2026.   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 six 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."   The list of current Internet-Drafts can be accessed at   http://www.ietf.org/ietf/1id-abstracts.txt   The list of Internet-Draft Shadow Directories can be accessed at   http://www.ietf.org/shadow.html.   This Internet-Draft will expire in May, 2003.  Comments or    suggestions for improvement may be made on the "ietf-pkix" mailing   list, or directly to the authors.Copyright Notice   Copyright (C) The Internet Society (2002).  All Rights Reserved.Abstract   This document describes the Internet X.509 Public Key Infrastructure   (PKI) Certificate Management Protocols. Protocol messages are defined   for all relevant aspects of certificate creation and management.   Note that "certificate" in this document refers to an X.509v3   Certificate as defined in [COR95, X509-AM].   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,   as shown) are to be interpreted as described in [RFC2119].Adams & Farrell               Expires May 2003                    [Page 1]Table of Contents1. PKI Management Overview ............................................  4   1.1 PKI Management Model ...........................................  4   1.2 Definitions of PKI Entities ....................................  4   1.3 PKI Management Requirements ....................................  6   1.4 PKI Management Operations ......................................  82. Assumptions and Restrictions ....................................... 12   2.1 End Entity Initialization ...................................... 12   2.2 Initial Registration/Certification ............................. 12   2.3 Proof of Possession (POP) of Private Key ....................... 15   2.4 Root CA Key Update ............................................. 173. Data Structures .................................................... 21   3.1 Overall PKI Message ............................................ 21   3.2 Common Data Structures ......................................... 28   3.3 Operation-Specific Data Structures ............................. 38      3.3.1  Initialization Request ................................... 38      3.3.2  Initialization Response .................................. 38      3.3.3  Certification Request .................................... 38      3.3.4  Certification Response ................................... 39      3.3.5  Key Update Request ....................................... 40      3.3.6  Key Update Response ...................................... 40      3.3.7  Key Recovery Request ..................................... 40      3.3.8  Key Recovery Response .................................... 40      3.3.9  Revocation Request ....................................... 41      3.3.10 Revocation Response ...................................... 41      3.3.11 Cross-Certification Request .............................. 41      3.3.12 Cross-Certification Response ............................. 42      3.3.13 CA Key Update Announcement ............................... 42      3.3.14 Certificate Announcement ................................. 42      3.3.15 Revocation Announcement .................................. 42      3.3.16 CRL Announcement ......................................... 43      3.3.17 PKI Confirmation ......................................... 43      3.3.18 Certificate Confirmation ................................. 43      3.3.19 PKI General Message ...................................... 44      3.3.20 PKI General Response ..................................... 47      3.3.21 Error Message ............................................ 47      3.3.22 Polling Request and Response ............................. 474. Mandatory PKI Management Functions ................................. 49   4.1 Root CA Initialization ......................................... 49   4.2 Root CA Key Update ............................................. 50   4.3 Subordinate CA Initialization .................................. 50   4.4 CRL Production ................................................. 50   4.5 PKI Information Request ........................................ 50   4.6 Cross-Certification ............................................ 51   4.7 End Entity Initialization ...................................... 53   4.8 Certificate Request ............................................ 54   4.9 Key Update ..................................................... 54Adams & Farrell               Expires May 2003                    [Page 2]5. Version Negotiation ................................................ 55   5.1 Supporting RFC 2510 Implementations ............................ 55Security Considerations ............................................... 56References ............................................................ 57Acknowledgements ...................................................... 58Authors' Addresses .................................................... 58Appendix A: Reasons for the presence of RAs ........................... 59Appendix B: PKI Management Message Profiles (REQUIRED) ................ 60Appendix C: PKI Management Message Profiles (OPTIONAL) ................ 70Appendix D: Request Message Behavioral Clarifications ................. 77Appendix E: The Use of "Revocation Passphrase" ........................ 78Appendix F: "Compilable" ASN.1 Module Using 1988 Syntax ............... 80Appendix G: Registration of MIME Type for E-Mail or HTTP Use .......... 91Full Copyright Statement .............................................. 92Adams & Farrell               Expires May 2003                    [Page 3]1 PKI Management Overview   The PKI must be structured to be consistent with the types of   individuals who must administer it.  Providing such administrators   with unbounded choices 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 Certification Authority   (CA) and a client system with which a key pair is associated, or   between two CAs that issue cross-certificates for each other.1.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 accommodate different identifiable types   of end entities.1.2 Definitions of PKI Entities   The entities involved in PKI management include the end entity (i.e.,   the entity to whom the certificate is issued) and the   certification authority (i.e., the entity that issues the certificate).    A registration authority MAY also be involved in PKI management.1.2.1 Subjects and End Entities   The term "subject" is used here to refer to the entity to whom the    certificate is issued, typically named in the subject or   subjectAltName 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, the term "end entity" (EE) rather than subject is preferred   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; for example, application 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 or    subjectAltName field of a certificate or cross-certificate.  WhereAdams & Farrell               Expires May 2003                    [Page 4]   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 entity and that CA's public key (or a   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   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).   Though PSE formats are beyond the scope of this document (they are   very dependent on equipment, et cetera), a generic interchange format   for PSEs is defined here - a certification response message 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 organization 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 implementers   (though it is also relevant as a policy issue).   We use the term "root CA" to indicate a CA that 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 is not meant   to imply that a root CA is necessarily at the top of any hierarchy,   simply that the CA in question is trusted directly.   A "subordinate CA" is one that 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.Adams & Farrell               Expires May 2003                    [Page 5]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.   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 RAs have private keys   that are usable for signing. How a particular CA equipment identifies   some end entities as RAs is an implementation issue (i.e., this   document specifies no special RA certification operation). We do not