draft-ietf-pkix-roadmap-09.txt

PKIX的RFC英文文档

   with client systems or end users in another administrative domain. 
   Use of a cross-certificate issued from CA_1 to CA_2 allows user 
   Alice, who trusts CA_1, to accept a PKC used by Bob, which was 
   issued by CA_2. Cross-certificates can also be issued from one CA to 
   another CA in the same administrative domain, if required. 
    
   Cross-certificates can be issued in only one direction, or in both 
   directions, between two CA's. That is, just because CA_1 issues a 
   cross-certificate for CA_2, CA_2 does not have to issue a cross- 
   certificate for CA_1. 
    
    
2.4.8 Revocation 
    
   When a PKC is issued, it is expected to be in use for its entire 
   validity period. However, various circumstances may cause a PKC to 
   become invalid prior to the expiration of the validity period. Such 
   circumstances include change of name, change of association between 
   subject and CA (e.g., an employee terminates employment with an 
   organization), and compromise or suspected compromise of the 
   corresponding private key. Under such circumstances, the CA needs to 
   revoke the PKC. 
    
   X.509 defines one method of PKC revocation. This method involves each 
   CA periodically issuing a signed data structure called a certificate 
   revocation list (CRL). A CRL is a list that identifies the 
   references of revoked PKCs. This list contains a date of issue and 
   is signed by a CA and made freely available in a public repository. 
   Each revoked PKC is identified in a CRL by its PKC serial number. 
   When a certificate-using system uses a PKC, that system not only 
   checks the PKC signature and validity but also acquires a suitably 
   recent CRL and checks that the PKC serial number is not on that CRL. 
   The meaning of "suitably recent" may vary with local policy, but it 
   usually means the most recently issued CRL. A CA issues a new CRL on 
   a regular periodic basis (e.g., hourly, daily, or weekly). CA's may 
 
Arsenault, Turner                                                   14 
 
Internet-Draft                PKIX Roadmap                  July 2002 

   also issue CRLs aperiodically. For example, if an important key is 
   deemed compromised, the CA may issue a new CRL to expedite 
   notification of that fact, even if the next CRL does not have to be 
   issued for some time. (A problem of aperiodic CRL issuance is that 
   end-entities may not know that a new CRL has been issued, and thus 
   may not retrieve it from a repository.) 
    
   An entry is added to the CRL as part of the next update following 
   notification of revocation. An entry may be removed from the CRL 
   after appearing on one regularly scheduled CRL issued beyond the 
   revoked PKC's validity period. Leaving the revoked PKC on the CRL for 
   this extra period allows for PKCs that are revoked prior to issuing a 
   new CRL and whose invalidity date falls before the CRL issuing time 
   to be accounted for. If the revoked PKC is not retained on the CRL 
   for this extra period then the possibility arises that a revoked PKC 
   may never appear on a CRL. 
    
   An advantage of the CRL revocation method is that CRLs may be 
   distributed by exactly the same means as PKCs themselves, namely, via 
   untrusted communications and server systems. 
    
   One limitation of the CRL revocation method, using untrusted 
   communications and servers, is that the time granularity of 
   revocation is limited to the CRL issue period. For example, if a 
   revocation is reported now, that revocation will not be reliably 
   notified to certificate-using systems until the next CRL is issued, 
   which may be up to one hour, one day, or one week depending on the 
   frequency that the CA issues CRLs. 
    
   As with the X.509 v3 PKC format, in order to facilitate interoperable 
   implementations from multiple vendors, the X.509 v2 CRL format needed 
   to be profiled for Internet use. This was done as part of the 
   Internet PKI Profile [FORMAT]. However, PKIX does not require CAs to 
   issue CRLs. On-line methods of revocation notification may be 
   applicable in some environments as an alternative to the X.509 CRL. 
   PKIX defines a few protocols that support on-line checking. [OCSP], 
   [DVCS], and [SCVP] all support on-line checking of the status of 
   PKCs. 
    
   On-line revocation checking may significantly reduce the latency 
   between a revocation report and the distribution of the information 
   to relying parties. Once the CA accepts the report as authentic and 
   valid, any query to the on-line service will correctly reflect the 
   PKC validation impacts of the revocation. However, these methods 
   impose new security requirements; the PKC validator must trust the 
   on-line validation service while the repository does not need to be 
   trusted. 
    
    
2.4.9 Certificate & Revocation Notice Distribution & Publication 
    
   As alluded to in sections 2.1 and 2.5.8 above, the PKI is responsible 
   for the distribution of PKCs and PKC revocation notices (whether in 
 
Arsenault, Turner                                                   15 
 
Internet-Draft                PKIX Roadmap                  July 2002 

   CRL form or in some other form) in the system. "Distribution" of PKCs 
   includes transmission of the PKC to its owner, and may also include 
   publication of the PKC in a repository. "Distribution" of revocation 
   notices may involve posting CRLs in a repository, transmitting them 
   to end-entities, or forwarding them to on-line responders. 
    
    
3 PMI 
    
3.1 Theory 
    
   Many systems use the PKC to perform identity based access control 
   decisions (i.e., the identity may be used to support identity-based 
   access control decisions after the client proves that it has access 
   to the private key that corresponds to the public key contained in 
   the PKC). For many systems this is sufficient, but increasingly 
   systems are beginning to find that rule-based and role-based access 
   control is required. These forms of access control decisions require 
   additional information that is normally not included in a PKC, 
   because the lifetime of the information is much shorter than the 
   lifetime of the public-private key pair. To support binding this 
   information to a PKC the Attribute Certificate (AC) was defined in 
   ANSI and later incorporated into ITU-T Recommendation X.509. The AC 
   format allows any additional information to be bound to a PKC by 
   including, in a digitally signed data structure, a reference back to 
   one specific PKC or to multiple PKCs, useful when the subject has the 
   same identity in multiple PKCs. Additionally, the AC can be 
   constructed in such a way that it is only useful at one or more 
   particular targets (e.g., web server, mail host). 
    
   Users of a PMI must be confident that the identity purporting to 
   posses an attribute has the right to possess that attribute. This 
   confidence may be obtained through the use of PKCs or it may be 
   configured in the AC-using system. If PKCs are used the party making 
   the access control decision can determine "if the AC issuer is 
   trusted to issue ACs containing this attribute." 
    
   ACs are complicated by the fact that they can point to an identity 
   which may be in more than one PKC. If the RP has multiple 
   certification chains to chose from then it has to make the 
   determination as to which certification path to trust. Regardless, 
   before the RP uses the AC it must make sure that a path from the AC 
   back to its trust point is valid. 
    
    
3.2 Architectural Model 
    
   A Privilege Management Infrastructure, or PMI, is defined as: 
    
   The set of hardware, software, people, policies and procedures needed 
   to create, manage, store, distribute, and revoke ACs. 
    
   A PMI consists of five types of components [AC]: 
 
Arsenault, Turner                                                   16 
 
Internet-Draft                PKIX Roadmap                  July 2002 

    
     - Attribute Authorities (AAs), or Attribute Certificate Issuer, 
       that issue and revoke ACs; 
      
     Note: AAs may implicitly revoke ACs by using very short validity 
     periods. 
      
     - Attribute Certificate Users that parses or processes an AC; 
      
     - Attribute Certificate Verifiers that check the validity of an AC 
       and then makes use of the result; 
      
     - Clients that request an action for which authorization checks are 
       to be made; 
      
     - Repositories that store and make available certificates and 
       Certificate Revocation Lists (CRLs). 
    
   Figure 2 is an example of the exchanges that may involve ACs. 
    
      +--------------+ 
      |              |        Server Acquisition 
      |  AC issuer   +----------------------------+ 
      |              |                            | 
      +--+-----------+                            | 
         |                                        | 
         | Client                                 | 
         | Acquisition                            | 
         |                                        | 
      +--+-----------+                         +--+------------+ 
      |              |       AC "push"         |               | 
      |   Client     +-------------------------+    Server     | 
      |              | (part of app. protocol) |               | 
      +--+-----------+                         +--+------------+ 
         |                                        | 
         | Client                                 | Server 
         | Lookup        +--------------+         | Lookup 
         |               |              |         | 
         +---------------+  Repository  +---------+ 
                         |              | 
                         +--------------+ 
    
                  Figure 2: AC Exchanges 
    
    
3.3 Attribute Certificates 
    
   ANSI X.9 first published the Attribute Certificate format. It defined 
   the standard version 1 (v1) AC format. They later created a version 2 
   (v2) AC by modifying the owner field to point to either an identity 
   or a specific PKC and including an extension mechanism. In 1997 ITU-T 
   included it in [X.509]. 
    
 
Arsenault, Turner                                                   17 
 
Internet-Draft                PKIX Roadmap                  July 2002 

   ANSI, ITU-T, and IETF have developed standard extensions and 
   attributes for use in the v2 ACs. Extensions can convey such 
   information as an audit identity that can be used to create an audit 
   trail, identity specific servers and services where the AC owner can 
   use their AC, point to a specific issuer's key, and indicate where to 
   get revocation information. The AC is generic enough to allow any 
   attribute to be conveyed in the data structure. Without limiting the 
   attributes and extensions that can be included in an AC it is very 
   difficult to develop interoperable implementations for Internet use. 
   It is the goal of PKIX to specify a profile for the Internet, 
   electronic mail, IPSec applications, etc. Environments with 
   additional requirements may build on this profile or replace it. 
    
   The [AC] profile constrains many of the options allowed in X.509. For 
   example, the AC chains, like their PKC brethren, are allowed by 
   X.509, but the AC profile recommends that they not be supported in to 
   simplify the implementation. 
    
    
4 PKIX Documents 
    
   This section identifies the five different areas in which the PKIX 
   working group has developed documents. The first area involves 
   profiles of the X.509 v3 PKC standards and the X.509 v2 CRL standards 
   for the Internet. The second area involves operational protocols, in 
   which relying parties can obtain information such as PKCs or PKC 
   status. The third area covers management protocols, in which 
   different entities in the system exchange information needed for 
   proper management of the PKI. The fourth area provides information 
   about certificate policies and certificate practice statements, 
   covering the areas of PKI security not directly addressed in the rest 
   of PKIX. The fifth area deals with providing time stamping and data 
   certification services, which can be used to build such services as 
   non-repudiation. 
    
    
4.1 Profiles 
    
   An X.509 v3 PKC is a very complex data structure. It consists of 
   basic information fields, plus a number of optional extensions. Many 
   of the fields and numerous extensions can take on a wide range of 
   options. This provides an enormous degree of flexibility, which 
   allows the X.509 v3 PKC format to be used with a wide range of 
   applications in a wide range of environments. Unfortunately, this