draft-ietf-pkix-roadmap-09.txt

PKIX的RFC英文文档

       and other attributes; 
      

 
Arsenault, Turner                                                    9 
 
Internet-Draft                PKIX Roadmap                  July 2002 

     - PKC holders are issued certificates and can sign digital 
       documents and decrypt documents using private keys; 
      
     - Clients that validate digital signatures and their certification 
       paths from a known public key of a trusted CA and that encrypt 
       document using public key from certificates of PKC holders; 
      
     - Repositories that store and make available PKCs and Certificate 
       Revocation Lists (CRLs). 
    
   Figure 1 is a simplified view of the architectural model assumed by 
   the PKIX Working Group. 
    
     +---+     cert. publish        +------------+       
     |   |  <---------------------  | End Entity | <------- 
     | C |                          +------------+      "out-of-band" 
     |   |                            | ^                loading 
     | e |                            | |      initial 
     | r |                            | |       registration/ 
     | t |                            | |       certification 
     |   |                            | |      key pair recovery 
     | / |                            | |      key pair update 
     |   |                            | |      certificate update 
     | C |  PKI "USERS"               V |      revocation request 
     | R | -------------------+-+-----+-+------+-+------------------- 
     | L |  PKI MANAGEMENT    | ^              | ^ 
     |   |    ENTITIES        | |              | | 
     |   |                    V |              | | 
     | R |                 +------+            | | 
     | e |   <------------ | RA   | <-----+    | | 
     | p |      cert.      |      | ----+ |    | | 
     | o |       publish   +------+     | |    | | 
     | s |                              | |    | | 
     | i |                              V |    V | 
     | t |                            +------------+ 
     | o |   <------------------------|     CA     |-------> 
     | r |                            +------------+  "out-of-band" 
     | y |      cert. publish              | ^         publication 
     |   |      CRL publish                | | 
     +---+                                 | |    cross-certification 
                                           | |    cross-certificate 
                                           | |       update 
                                           | | 
                                           V | 
                                         +------+ 
                                         | CA-2 | 
                                         +------+ 
    
                      Figure 1 - PKI Entities 
    
    


 
Arsenault, Turner                                                   10 
 
Internet-Draft                PKIX Roadmap                  July 2002 

2.3 Public Key Certificates 
    
   ITU-T X.509 (formerly CCITT X.509) or ISO|IEC/ITU 9594-8, which was 
   first published in 1988 as part of the X.500 Directory 
   recommendations, defines a standard PKC format [X.509]. The PKC 
   format in the 1988 standard is called the version 1 (v1) format. 
    
   When X.500 was revised in 1993, two more fields, 
   subjectUniqueIdentifier and issuerUniqueIdentifier were added, 
   resulting in the version 2 (v2) format. These two fields may be used 
   to support directory access control. 
    
   The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, 
   include specifications for a public key infrastructure based on X.509 
   v1 public key certificates [PEM]. The experience gained in attempts 
   to deploy [PEM] made it clear that the v1 and v2 public key 
   certificate formats are deficient in several respects. Most 
   importantly, more fields were needed to carry information which PEM 
   design and implementation experience has proven necessary. In 
   response to these new requirements, ISO|IEC, ITU, and ANSI X9 
   developed the X.509 version 3 (v3) PKC format. The v3 format extends 
   the v2 format by adding provision for additional extension fields. 
   Particular extension field types may be specified in standards or may 
   be defined and registered by any organization or community. In June 
   1996, standardization of the basic v3 format was completed [X.509]. 
    
   ISO|IEC, ITU, and ANSI X9 have also developed standard extensions for 
   use in the v3 extensions field [X.509][X9.55]. These extensions can 
   convey such data as additional subject identification information, 
   key attribute information, policy information, and certification path 
   constraints. However, the ISO/IEC/ITU and ANSI X9 standard extensions 
   are very broad in their applicability. In order to develop 
   interoperable implementations of X.509 v3 systems for Internet use, 
   it is necessary to specify a profile for use of the X.509 v3 
   extensions tailored for the Internet. It is one goal of PKIX to 
   specify a profile for Internet, electronic mail, and IPSec 
   applications, etc. Environments with additional requirements may 
   build on this profile or may replace it. 
    
    
2.4 Functions of a PKI 
    
   This section describes the major functions of a PKI. In some cases, 
   PKIs may provide extra functions. 
    
    
2.4.1 Registration 
    
   This is the process whereby a subject first makes itself known to a 
   CA (directly, or through an RA), prior to that CA issuing a PKC or 
   PKCs for that subject. Registration involves the subject providing 
   its name (e.g., common name, fully-qualified domain name, IP 
   address), and other attributes to be put in the PKC, followed by the 
 
Arsenault, Turner                                                   11 
 
Internet-Draft                PKIX Roadmap                  July 2002 

   CA (possibly with help from the RA) verifying in accordance with its 
   Certification Practice Statement (CPS) that the name and other 
   attributes are correct. 
    
    
2.4.2 Initialization 
    
   Initialization is when the subject (e.g., the user or client system) 
   gets the values needed to begin communicating with the PKI. For 
   example, initialization can involve providing the client system with 
   the public key or PKC of a CA, or generating the client system's own 
   public-private key pair. 
    
    
2.4.3 Certification 
    
   This is the process in which a CA issues a PKC for a subject's public 
   key, and returns that PKC to the subject or posts that PKC in a 
   repository. 
    
    
2.4.4 Key Pair Recovery 
    
   In some implementations, key exchange or encryption keys will be 
   required by local policy to be "backed up," or recoverable in case 
   the key is lost and access to previously-encrypted information is 
   needed. Such implementations can include those where the private key 
   exchange key is stored on a hardware token that can be lost or 
   broken, or when a private key file is protected by a password which 
   can be forgotten. Often, a company is concerned about being able to 
   read mail encrypted by or for a particular employee when that 
   employee is no longer available because she is ill or no longer works 
   for the company. 
    
   In these cases, the user's private key can be backed up by a CA or by 
   a separate key backup system. If a user or her employer needs to 
   recover these backed up key materials, the PKI must provide a system 
   that permits the recovery without providing an unacceptable risk of 
   compromise of the private key. 
    
    
2.4.5 Key Generation 
    
   Depending on the CA's policy, the private-public key pair can either 
   be generated by the user in his local environment, or generated by 
   the CA. In the latter case, the key material may be distributed to 
   the user in an encrypted file or on a physical token (e.g., a smart 
   card or PC card). 
    
    



 
Arsenault, Turner                                                   12 
 
Internet-Draft                PKIX Roadmap                  July 2002 

2.4.6 Key Update 
    
   All key pairs need to be updated regularly (i.e., replaced with a new 
   key pair) and new PKCs issued. This will happen in two cases: 
   normally, when a key has passed its maximum usable lifetime; and 
   exceptionally, when a key has been compromised and must be replaced. 
    
    
2.4.6.1 Key Expiry 
    
   In the normal case, a PKI needs to provide a facility to gracefully 
   transition from a PKC with an existing key to a new PKC with a new 
   key. This is particularly true when the key to be updated is that of 
   a CA. Users will know in advance that the key will expire on a 
   certain date; the PKI, working together with PKC-using applications, 
   should allow for appropriate keys to work before and after the 
   transition. There are a number of ways to do this; see [CMP] for an 
   example of one. 
    
    
2.4.6.2 Key Compromise 
    
   In the case of a key compromise, the transition will not be 
   "graceful" in that there will be an unplanned switch of PKCs and 
   keys; users will not have known in advance what was about to happen. 
   Still, the PKI must support the ability to declare that the previous 
   PKC is now invalid and shall not be used, and to announce the 
   validity and availability of the new PKC. 
    
   Note: compromise of a private key associated with a Root CA is 
   catastrophic for users relying on that Root CA. If a Root CA's 
   private key is compromised, that CA's PKC must be revoked and all 
   PKCs subordinate to it must also be revoked. Until such time as the 
   Root CA has been issued a new PKC and the Root CA issues PKCs to 
   users relying upon it, users relying on that Root CA are cut off from 
   the rest of the system, as there is no way to develop a valid 
   certification path back to a trusted node. 
    
   Further, users will likely have to be notified by out-of-band 
   mechanisms about the change in CA keys. If the old key is 
   compromised, any "update" message telling subordinates to switch to a 
   new key could have come from an attacker in possession of the old 
   key, and could point to a new public key for which the attacker 
   already has the private key. It is possible to have anticipated this 
   event, and "pre-placed" replacement Root CA keys with all relying 
   parties, but some secure, out-of-band mechanism will have to be used 
   to tell users to make the switch, and this will only help if the 
   replacement key has not been compromised. 
    
   Additionally, once the Root CA is brought back up with a new key, it 
   will likely be necessary to re-issue PKCs, signed with the new key, 
   to all subordinate users, since their current PKC would be signed 
   with a now-revoked key. 
 
Arsenault, Turner                                                   13 
 
Internet-Draft                PKIX Roadmap                  July 2002 

    
    
2.4.7 Cross-certification 
    
   A CA certificate is a certificate in a hierarchy that is neither a 
   self-signed certificate, nor an end-entity certificate. [2459bis] 
   does not make a difference between a CA certificate and a cross 
   certificate since it defines a cross-certificate as "a certificate 
   issued by one CA to another CA". Some people in the WG believe that 
   a cross certificate is a special kind of CA certificate. A cross 
   certificate is issued by a CA under one Top CA for another CA under 
   a different Top CA. CAs in the same hierarchy have part of their 
   names imposed by the Top CA or by the CAs under that Top CAS. When a 
   cross certificate is issued, there is no relationship between the 
   names of the CAs. 
    
   Typically, a cross-certificate is used to allow client systems or 
   end entities in one administrative domain to communicate securely