draft-ietf-pkix-proxy-03.txt

PKIX的RFC英文文档

                allowing the application of a policy to limit 
                impersonation. 
              
          2.6 Description Of Approach 
              
             This document defines an X.509 "Proxy Certificate" or "PC" 
             as a means of providing for restricted impersonation 
             within an (extended) X.509 PKI based authentication 
             system. 
              
             A Proxy Certificate is an X.509 public key certificate 
             with the following properties: 
              
             1) It is signed by either an X.509 End Entity Certificate 
                (EEC), or by another PC. This EEC or PC is referred to 
                as the Proxy Issuer (PI). 
                 
             2) It can sign only another PC.  It cannot sign an EEC. 
                 
             3) It has its own public and private key pair, distinct 
                from any other EEC or PC. 
                 
             4) It has an identity derived from the identity of the EEC 
                that signed the PC. When a PC is used for 
                authentication, in may inherit rights of the EEC that 
                signed the PC, subject to the restrictions that are 
                placed on that PC by the EEC. 
                 
             5) Although its identity is derived from the EEC's 
                identity, it is also unique. This allows this identity 
                to be used for authorization as an independent identity 
                from the identity of the issuing EEC, for example in 
                conjunction with attribute assertions as defined in 



           
          [e-mail]                                          11 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

                [4]. 
                 
             6) It contains a new X.509 extension to identify it as a 
                PC and to place policies on the use of the PC.  This 
                new extension, along with other X.509 fields and 
                extensions, are used to enable proper path validation 
                and use of the PC. 
              
             The process of creating a PC is as follows: 
              
            1) A new public and private key pair is generated. 
                
            2) That key pair is used to create a request for a Proxy 
               Certificate that conforms to the profile described in 
               this document. 
                
            3) A Proxy Certificate, signed by the private key of the 
               EEC or by another PC, is created in response to the 
               request.  During this process, the PC request is 
               verified to ensure that the requested PC is valid (e.g. 
               it is not an EEC, the PC fields are appropriately set, 
               etc). 
              
             When a PC is created as part of a delegation from entity A 
             to entity B, this process is modified by performing steps 
             #1 and #2 within entity B, then passing the PC request 
             from entity B to entity A over an authenticated, integrity 
             checked channel, then entity A performs step #3 and passes 
             the PC back to entity B. 
              
             Path validation of a PC is very similar to normal path 
             validation, with a few additional checks to ensure, for 
             example, proper PC signing constraints.   In order to make 
             the appropriate PC(s) and EEC available for path 
             validation, the authentication protocol using the PC (e.g. 
             TLS) MAY pass the entire PC and EEC chain as part of the 
             authentication protocol. 
              
          2.7 Features Of This Approach 
              
             Using Proxy Certificates to perform delegation has several 
             features that make it attractive: 
              


           
          [e-mail]                                          12 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

             *  Ease of integration 
                 
                .  Because a PC requires only a minimal change to path 
                   validation, it is very easy to incorporate support 
                   for Proxy Certificates into existing X.509 based 
                   software.  For example, SSL/TLS requires no protocol 
                   changes to support authentication using a PC.  
                   Further, an SSL/TLS implementation requires only 
                   minor changes to support PC path validation, and to 
                   retrieve the authenticated subject of the signing 
                   EEC instead of the subject of the PC for 
                   authorization purposes. 
                    
                .  Many existing authorization systems use the X.509 
                   subject name as the basis for access control. Proxy 
                   Certificates that perform impersonation can be used 
                   with such authorization systems without 
                   modification, since such a PC inherits its name and 
                   rights from the EEC that signed it and the EEC name 
                   can be used in place of the PC name for 
                   authorization decisions.  
                    
             *  Ease of use 
                 
                .  Using PC for single sign-on helps make X.509 PKI 
                   authentication easier to use, by allowing users to 
                   "login" once and then perform various operations 
                   securely. 
                    
                .  For many users, properly managing their own EEC 
                   private key is a nuisance at best, and a security 
                   risk at worst.  One option easily enabled with a PC 
                   is to manage the EEC private keys and certificates 
                   in a centrally managed repository.  When a user 
                   needs a PKI credential, the user can login to the 
                   repository using name/password, one time password, 
                   etc.  Then the repository can delegate a PC to the 
                   user with impersonation rights, but continue to 
                   protect the EEC private key in the repository. 
                    
             *  Protection of private keys 
                 



           
          [e-mail]                                          13 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

                .  By using the remote delegation approach outlined 
                   above, entity A can delegate a PC to entity B, 
                   without entity B ever seeing the private key of 
                   entity A, and without entity A ever seeing the 
                   private key of the newly delegated PC held by entity 
                   B.  In other words, private keys never need to be 
                   shared or communicated by the entities participating 
                   in a delegation of a PC. 
              
                .  When implementing single sign-on, using a PC helps 
                   protect the private key of the EEC, because it 
                   minimizes the exposure and use of that private key.  
                   For example, when an EEC private key is password 
                   protected on disk, the password and unencrypted 
                   private key need only be available during the 
                   creation of the PC.  That PC can then be used for 
                   the remainder of its valid lifetime, without 
                   requiring access to the EEC password or private key.  
                   Similarly, when the EEC private key lives on a 
                   smartcard, the smartcard need only be present in the 
                   machine during the creation of the PC. 
                     
             *  Limiting consequences of a compromised key 
                 
                .  When creating a PC, the PI can limit the validity 
                   period of the PC, the depth of the PC path that can 
                   be created by that PC, and key usage of the PC and 
                   its descendents.  Further, fine-grained policies can 
                   be carried by a PC to even further restrict the 
                   operations that can be performed using the PC. These 
                   restrictions permit the PI to limit damage that 
                   could be done by the bearer of the PC, either 
                   accidentally or maliciously. 
                    
                .  A compromised PC private key does NOT compromise the 
                   EEC private key.  This makes a short term, or an 
                   otherwise restricted PC attractive for day-to-day 
                   use, since a compromised PC does not require the 
                   user to go through the usually cumbersome and time 
                   consuming process of having the EEC with a new 
                   private key reissued by the CA. 
              



           
          [e-mail]                                          14 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

             See Section 5 below for more discussion on how Proxy 
             Certificates relate to Attribute Certificates. 
              
          3  Certificate and Certificate Extensions Profile 
              
             This section defines the usage of X.509 certificate fields 
             and extensions in Proxy Certificates, and defines one new 
             extension for Proxy Certificate Information. 
              
          3.1 Issuer 
              
             The Proxy Issuer of a Proxy Certificate MUST be either an 
             End Entity Certificate, or another Proxy Certificate.   
              
             The Proxy Issuer MUST NOT have an empty subject field. 
              
             The issuer field of a Proxy Certificate MUST contain the 
             subject field of it's Proxy Issuer. 
              
             A Proxy Certificate MUST NOT be used to sign an End Entity 
             Certificate or a CA Certificate. 
           
          3.2 Issuer Alternative Name 
              
             The issuerAltName extension MUST NOT be present in a Proxy 
             Certificate. 
              
          3.3 Serial Number 
              
             The serial number of a Proxy Certificate (PC) SHOULD be 
             unique amongst all Proxy Certificates issued by a 
             particular Proxy Issuer.  However, a Proxy Issuer MAY use 
             an approach to assigning serial numbers that merely 
             ensures a high probability of uniqueness. 
              
             For example, a Proxy Issuer MAY use a sequentially 
             assigned integer or a UUID to assign a unique serial 
             number to a PC it issues.  Or a Proxy Issuer MAY use a 
             SHA-1 hash of the PC public key to assign a serial number 
             with a high probability of uniqueness. 
              
          3.4 Subject 
              


           
          [e-mail]                                          15 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

             The subject field of a Proxy Certificate MUST be the 
             issuer field (that is the subject of the Proxy Issuer) 
             appended with a single Common Name component.  The value 
             of the Common Name SHOULD be unique amongst all Proxy 
             Certificates with the same issuer.  However, the Proxy 
             Issuer MAY use an approach to assigning Common Name values 
             that merely ensures a high probability of uniqueness. This 
             value MAY be the same value used for the serial number. 
              
             The result of this approach is that all subject names of 
             Proxy Certificates should be derived from the name of the 
             issuing EEC (it will be the first part of the subject name 
             appended with one or more CN components) and be unique. 
           
          3.5 Subject Alternative Name