draft-ietf-pkix-rfc2510bis-07.txt

PKIX的RFC英文文档

Internet Draft                                                   C. Adams
PKIX Working Group                                          Entrust, Inc.
November, 2002                                                 S. Farrell
Expires 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 Contents

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

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

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

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

Adams & Farrell               Expires May 2003                    [Page 2]




5. Version Negotiation ................................................ 55
   5.1 Supporting RFC 2510 Implementations ............................ 55

Security Considerations ............................................... 56

References ............................................................ 57

Acknowledgements ...................................................... 58

Authors' Addresses .................................................... 58

Appendix A: Reasons for the presence of RAs ........................... 59
Appendix B: PKI Management Message Profiles (REQUIRED) ................ 60
Appendix C: PKI Management Message Profiles (OPTIONAL) ................ 70
Appendix D: Request Message Behavioral Clarifications ................. 77
Appendix E: The Use of "Revocation Passphrase" ........................ 78
Appendix F: "Compilable" ASN.1 Module Using 1988 Syntax ............... 80
Appendix G: Registration of MIME Type for E-Mail or HTTP Use .......... 91

Full Copyright Statement .............................................. 92

































Adams & 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.  Where




Adams & 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