draft-ietf-pkix-roadmap-09.txt

PKIX的RFC英文文档

     - Top CA - A CA that is at the top of a PKI hierarchy. Note: This 
       is often also called a "Root CA," since in data structures terms 
       and in graph theory, the node at the top of a tree is the 
       "root." However, to minimize confusion in this document, we 
       elect to call this node a "Top CA," and reserve "Root CA" where 
       there is a single CA directly trusted by the EE. Readers new to 
       PKIX should be aware that these terms are not used consistently 
       throughout the PKIX documents, as the Internet PKI profile 
       [2459bis] uses "Root CA" to refer to what this and other 
       documents call a "Top CA," and "most-trusted CA" to refer to 
       what this and other documents call a "Root CA." 
    
    
1.3 History 
    
   The PKIX working group was formed in October of 1995 to develop 
   Internet standards necessary to support PKIs. The first work item was 
   a profile of the ITU-T Recommendation X.509 PKC [FORMAT]. X.509, 
   which is a widely accepted basis for a PKI, including data formats 
   and procedures related to distribution of public keys via PKCs 
   digitally signed by CAs. X.509 does not however include a profile to 
   specify the support requirements for many of the PKC data structure's 
   sub- fields, for any of the extensions, nor for certain data values. 
   The Internet PKI profile [FORMAT] went through many draft versions 
   before becoming an RFC. Other profiles have been developed in PKIX 
   for particular algorithms to make use of the Internet PKI Profile 
   [FORMAT]. There has been no sense of conflict between the authors 
   that developed these profiles as they are seen as complimentary. The 
   Internet PKI profile has been a draft standard for more than six 
 
Arsenault, Turner                                                    5 
 
Internet-Draft                PKIX Roadmap                  July 2002 

   months and is currently going through an update process to clarify 
   any inconsistencies and to bolster certain sections, see [2459bis]. 
    
   In parallel with the profile development, work was undertaken to 
   develop the protocols necessary to manage PKI-related information 
   was. The first developed was the Certificate Management Protocol 
   (CMP). It defines a message protocol to initialize, certify, update, 
   and revoke PKI entities [CMP]. The demand for an enrollment protocol 
   and the desire to use PKCS-10 message format as the certificate 
   request syntax lead to the development of two different documents in 
   two different groups. The Certificate Request Syntax (CRS) draft was 
   developed in the SMIME WG which used PKCS-10 [PKCS10] as the 
   certification request message format. Certificate Request Message 
   Format [CRMF] draft was also developed but in the PKIX WG. It was to 
   define a simple enrollment protocol that would subsume both the CMP 
   and CRS enrollment protocols, but it did not use PKCS-10 as the 
   certificate request message format. Then the certificate management 
   message format document, was developed to define an extended set of 
   management messages that flow between the components of the Internet 
   PKI. Certificate Management Messages over CMS (CMC) was developed to 
   allow the use of an existing protocol (S/MIME) as a PKI management 
   protocol, without requiring the development of an entirely new 
   protocol such as CMP [CMC]. It also included [PKCS10] as the 
   certificate request syntax, which caused work on the CRS draft to 
   stop. Information from the certificate management message format 
   document was moved into [CMP] and [CMC] so work on the certificate 
   management message format document was discontinued. After some 
   operational experience with [CMP], two drafts, one for using HTTP as 
   the transport protocol and one for Transmission Control Protocol 
   (TCP), were written to solve problems encountered by implementors. 
   These drafts were merged into one draft Transport Protocols for CMP 
   [TPCMP]. [CMP] has been a draft standard for more than six months and 
   is currently undergoing revisions to document. The transport section 
   has been removed and will remain in [TPCMP]. 
    
   Another long debated topic in the WG dealt with certificate 
   revocation. Numerous drafts have been developed to address different 
   issues related certificate revocations. CMP supports revocation 
   request, response, revocation announcement, and requests for CRL 
   messages. CMC defines revocation request, revocation response, and 
   requests for CRL messages, but uses CMS as the encapsulating 
   protocol. [OCSP] was developed to address concerns that not all 
   relying parties want to go through the process checking CRLs from 
   every CA in the certification path. It defines an on-line mechanism 
   to determine the status of a given certificate, which may provide 
   more timely revocation information than is possible with CRLs. The 
   Simple Certification Verification Protocol (SCVP) was produced to 
   allow relying parties to off-load all of their certification 
   verification to another entity [SCVP]. The WG was arguably split over 
   whether such a function should be supported and whether it should be 
   its own protocol or included in OCSP. In response, a draft defining 
   OCSP Extensions was produced to include the functions of SCVP. [OCSP] 
   has been a draft standard for more than six months and is in the 
 
Arsenault, Turner                                                    6 
 
Internet-Draft                PKIX Roadmap                  July 2002 

   process of being revised [OCSPv2]. To capture the work from the OCSP 
   Extensions, two drafts were developed: Delegated Path Validation 
   [DPV] and Delegated Path Discovery [DPD]. The WG recognizes an eed to 
   address online delegated path validation and delegated path 
   discovery. At least three candidates currently exist. There are: 
   OCSPv2, SCVP, and DVCS. Given this multiplicity, the WG undertook to 
   produce [DPREQ] in order to factilate selection from among these or 
   possibly others. 
    
   One other certificate status draft called Open CRL Distribution Point 
   (OCDP) was produced which documented two extensions: one to support 
   an alternative CRL partitioning mechanism to the CRL Distribution 
   Point mechanism documented in the Internet PKI Profile [FORMAT] and 
   one to support identifying other revocation sources available to 
   certificate-users. The work from this draft was subsumed by an ITU-T 
   | ISO/IEC Amendment to X.509, hence work on this draft was halted. 
    
   Development of the operational protocols has been slightly more 
   straightforward. Four documents for the Light Weight Directory Access 
   Protocol (LDAP) have been developed one for defining LDAPv2 as an 
   access protocol to repositories [PKI-LDAPv2]; two for storing PKI 
   information in an directory [SCHEMA] and [ADDSCHEMA]; and one for 
   LDAPv3 requirements for PKI [PKI-LDAPv3]. Using the File Transfer 
   Protocol (FTP) and the Hyper Text Transmission Protocol (HTTP) to 
   retrieve PKCs and CRLs from PKI repositories was documented in 
   [FTPHTTP]. Recognizing that LDAP directories are not the only 
   repository service, the working group draft a Repository Locator 
   Service [RLS] to make use of DNS SRV records to locate where and how 
   PKI information can be retrieved from a repository. 
    
   In late 1998 the PKIX charter was revised to include protocols for 
   time stamping and data certification services. [TSP] was developed to 
   define protocols required to interact with a Time Stamp Authority 
   (TSA) who asserts that a datum existed priot to a given time. [DVCS] 
   allows to verify and assert the validity of all signatures attached 
   to the signed document using all appropriate status information and 
   PKCs or to verify and assert the validity of one or more PKCs at the 
   specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating 
   mechanism (though in [TSP] request for a time stamp are not required 
   to use [CMS]). A draft for extending trust in tokens in time was 
   developed to use [DCVS] to maintain the trust in a token issued by a 
   non- repudiation Trusted Third Party (NR TTP) after the key initially 
   used to establish trust in the token expires; however, this draft has 
   expired. The [TRNRS] draft was developed to describe those features 
   of a service which processes signed documents that must be present in 
   order for that service to constitute a "technical non- repudiation" 
   service. 
    
   Around the same time, a work item for ACs, defined in [X.509], was 
   added. ACs are similar to PKCs, but they do not bind public keys to 
   identities rather they bind attributes to identities. The attributes 
   bound to the identity can represent anything, but are mostly used to 
   support rule-based and role-based access control decisions. Two 
 
Arsenault, Turner                                                    7 
 
Internet-Draft                PKIX Roadmap                  July 2002 

   drafts have since been developed: the Internet Attribute Certificates 
   Profile for Authorizations [AC] and the Limited Attribute Certificate 
   Acquisition Protocol [LAAP]. The first profiles the fields and 
   extensions of the AC and the second provides a deliberately limited 
   protocol to access a repository when LDAP is not appropriate. 
    
   Other drafts have been produced to address specific issues. [DHPOP] 
   was developed to define two mechanisms by which a signature can 
   produced using a Diffie-Hellman pair. This draft provides a mechanism 
   to use Diffie-Hellam key pairs to authenticate a PKCS-10 
   certification request. [REP] was developed during the revision to the 
   Internet PKI Profile [FORMAT] to separate the definitions of the 
   object identifiers and encoding rules for keys and digital signatures 
   in PKCs. The Qualified Certificates [QC] and Permanent Identifier 
   [PI] drafts were developed to address naming issues. 
    
   From the alphabet soup above, it is clear why this roadmap is 
   required. 
    
    
2 PKI 
    
2.1 Theory 
    
   At the heart of recent efforts to improve Internet security are a 
   group of security protocols such as Secure Multipurpose Internet Mail 
   Extensions (S/MIME), Transport Layer Security (TLS), and Internet 
   Protocol Security (IPSec). All of these protocols rely on public-key 
   cryptography to provide services such as confidentiality, data 
   integrity, data origin authentication, and non-repudiation. The 
   purpose of a PKI is to provide trusted and efficient key and public 
   key certificate management, thus enabling the use of authentication, 
   non-repudiation, and confidentiality. 
    
   Users of public key-based systems must be confident that, any time 
   they rely on a public key, the subject that they are communicating 
   with owns the associated private key, this applies whether an 
   encryption or digital signature mechanism is used. This confidence is 
   obtained through the use of PKCs, which are data structures that bind 
   public key values to subjects. The binding is achieved by having a 
   trusted CA verify the subject's identity and digitally sign each PKC. 
    
   A PKC has a limited valid lifetime, which is indicated in its signed 
   contents. Because a PKC's signature and timeliness can be 
   independently checked by a certificate-using client, PKCs can be 
   distributed via untrusted communications and server systems, and can 
   be cached in unsecured storage in certificate-using systems. 
    
   PKCs are used in the process of validating signed data. Specifics 
   vary according to which algorithm is used, but the general process 
   works as follows (Note: there is no specific order in which the 
   checks listed below must be made; implementors are free to implement 
   them in the most efficient way for their systems): 
 
Arsenault, Turner                                                    8 
 
Internet-Draft                PKIX Roadmap                  July 2002 

    
     - The recipient of signed data verifies that the claimed identity 
       of the user is in accordance with the identity contained in the 
       PKC; 
      
     - The recipient validates that no PKC in the path is revoked (e.g., 
       by retrieving a suitably-current Certificate Revocation List 
       (CRL) or querying an on-line certificate status responder), and 
       that all PKCs are within their validity periods at the time the 
       data was signed; 
      
     - The recipient verifies that the data are not claimed to have any 
       values for which the PKC indicates that the signer is not 
       authorized; 
      
     - The recipient verifies that the data have not been altered since 
       signing, by using the public key in the PKC. 
      
     - If all of these checks pass, the recipient can accept that the 
       data was signed by the purported signer. The process for keys 
       used for encryption is similar. 
    
   Note: It is of course possible that the data was signed by someone 
   very different from the signer, if for example the purported signer's 
   private key was compromised. Security depends on all parts of the 
   certificate-using system, including but not limited to: physical 
   security of the place the computer resides; personnel security (i.e., 
   the trustworthiness of the people who actually develop, install, run, 
   and maintain the system); the security provided by the operating 
   system on which the private key is used; and the security provided 
   the CA. A failure in any one of these areas can cause the entire 
   system security to fail. PKIX is limited in scope, however, and only 
   directly addresses issues related to the operation of the PKI 
   subsystem. For guidance in many of the other areas, see [POLPROC]. 
    
    
2.2 Architecture Model 
    
   A PKI is defined as: 
    
   The set of hardware, software, people, policies and procedures needed 
   to create, manage, store, distribute, and revoke PKCs based on 
   public-key cryptography. 
    
   A PKI consists of five types of components [MISPC]: 
    
     - Certification Authorities (CAs) that issue and revoke PKCs; 
      
     - Organizational Registration Authorities (ORAs) that vouch for the 
       binding between public keys and certificate holder identities