draft-ietf-pkix-proxy-03.txt

PKIX的RFC英文文档

             the PC identity with the intersection of the rights 
             granted to the identity of PI of the PC and the policy in 
             the PC. 
              
             For example, imagine that Steve is authorized to read and 
             write files A and B on a file server, and that he uses his 
             EEC to create a PC that includes the policy that it can be 
             used only to read or write files A and C. Then a trusted 
             attribute authority grants an Attribute Certificate 
             granting the PC the right to read file D. This would make 
             the rights of the PC equal to the union of the rights 
             granted to the PC identity (right to read file D) with the 
             intersection of the rights granted to Steve, the PI, 
             (right to read files A and B) with the policy in the PC 
             (can only read files A and C). This would mean the PC 
             would have the following rights: 
              
             *  Right to read file A: Steve has this right and he 
                issued the PC and his policy grants this right to the 



           
          [e-mail]                                          21 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

                PC. 
                 
             *  Right to read file D: This right is granted explicitly 
                to the PC by a trusted authority. 
                
            The PC would NOT have the following rights: 
                
             *  Right to read file B: Although Steve has this right, it 
                is excluded by his policy on the PC. 
                 
             *  Right to read file C: Although Steve's policy grants 
                this right, he does not have this right himself. 
              
             In many cases, the relying party will not have enough 
             information to evaluate the above criteria at the time 
             that the certificate path is validated.  For example, if a 
             certificate is used to authenticate a connection to some 
             server, that certificate is typically validated during 
             that authentication step, before any requests have been 
             made of the server.  In that case, the relying party MUST 
             either have some authorization mechanism in place that 
             will check the proxy policies, or reject any certificate 
             that contains proxy policies (or that has a parent 
             certificate that contains proxy policies). 
             
          4  Certificate Path Validation 
              
             The Certificate Path Validation algorithm described in 
             Section 6 of RFC 3280 [7] MUST be modified to accommodate 
             Proxy Certificates.  Changes are needed to: 
              
            1) check the generalized signing chains involving CAs, End 
               Entity Certificates, and Proxy Certificates; 
                
            2) check for proper subject names in Proxy Certificates; 
                
            3) handle the pCPathLenConstraint in the proxyCertInfo 
               extension; 
                
            4) check the key usage and extended key usage extensions; 
                
            5) don't include proxy certifications in normal path length 
               constraint checking; 


           
          [e-mail]                                          22 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

             
             Changes to section 6.1.2, Initialization: 
              
                (k) The text in this sections needs to be changed to 
                reflect that proxy certifications are not included in 
                certificates checked in path length constraint checks 
                as follows: 
                 
                   max_path_length:  this integer is initialized to n, 
                   is decremented for each non-self-issued and non-
                   proxy certificate in the path, and may be reduced to 
                   the value in the path length constraint field within 
                   the basic constraints extension of a CA certificate. 
              
                (new) max_pc_path_length: this integer is initialized 
                to n, is decremented for each proxy certificate in the 
                path, and may be reduced to the value of the 
                pCPathLenConstrain field within any certificate found 
                with a proxyCertInfo extension. 
                 
                (new) working_certificate_type: This can be one of CA, 
                EEC, or PC.  A certificate type of CA is determined by 
                the basicConstraints extension or as verified out-of-
                band.  A certificate type of PC is determined by the 
                proxyCertInfo extension.  Otherwise, the certificate 
                type is EEC. 
                 
                (new) working_issuer_certificate_type: This can be one 
                of EEC or PC to indicate the type of certificate that 
                acted as the Proxy Issuer for a PC. 
                 
                (new) valid_pc_key_usage & pc_key_usage_criticality: 
                These are used to verify that the key usage of a PC is 
                a subset of the key usage of the certificate that 
                signed that PC, and that the criticality of this 
                extension never diminishes.  These variables are not 
                initialized or used until the first EEC or PC is 
                encountered in the path validation algorithm with this 
                extension. 
                 
                (new) valid_pc_ext_key_usage & 
                pc_ext_key_usage_criticality: These are used to verify 
                that the extended key usage OIDs of a PC is a subset of 


           
          [e-mail]                                          23 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

                the extended key usage OIDs of the certificate that 
                signed that PC, and that the criticality of this 
                extension never diminishes.  These variables are not 
                initialized or used until the first EEC or PC is 
                encountered in the path validation algorithm with this 
                extension.  
                 
                (new) working_issuer_signature_algorithm & 
                working_issuer_signature_value:  These are used to 
                verify that, if certificate N+1 is a Proxy Certificate, 
                then certificate N is the certificate that issued that 
                proxy.  These variables are not used until the first 
                EEC or PC is encountered in the path validation 
                algorithm with the proxyCertInfo extension. 
              
              
             Changes to section 6.1.3, Basic Certificate Processing: 
           
                (a)(new) The certificate type is CA and the 
                working_certificate_type is CA, or the certificate type 
                is EEC and the working_certificate_type is CA, or the 
                certificate type is PC and the working_certificate_type 
                is EEC or PC. 
                 
                (b) & (c) This step checks the Name Constraints defined 
                by the CA.  However, these checks should be skipped if 
                the certificate type is PC. 
                 
                (new) If certificate type is PC, the subject name MUST 
                be checked to make sure it is a valid subject name to 
                have been issued by its Proxy Issuer. The subject name 
                MUST be the working_issuer_name with the addition of a 
                single CN component with any value 
                 
                (new) If certificate type is PC, and valid_pc_key_usage 
                has been initialized, then verify that: 
                 
                   (1) all bits that are asserted in the keyUsage 
                   extension of the certificate are also asserted in 
                   the valid_pc_key_usage; 
                    
                   (2) if pc_key_usage_criticality is true, then the 
                   keyUsage extension is critical  


           
          [e-mail]                                          24 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

                 
                (new) If certificate type is PC, and 
                valid_pc_ext_key_usage has been initialized, then 
                verify that: 
                 
                   (1) all OIDs that are in the extKeyUsage extension 
                   in the certificate are also in the 
                   valid_pc_ext_key_usage; 
                    
                   (2) if pc_ext_key_usage_criticality is true, then 
                   the extKeyUsage extension is critical. 
                    
              
             Changes to section 6.1.4, Preparation for Certificate i+1: 
              
                (k) This step verifies that the certificate is a CA 
                certificate.  However, it is not general enough to 
                support a PC.  So change this step to simply assign the 
                certificate type to the working_certificate_type.  The 
                necessary CA, EEC, and PC signing constraints check has 
                been added to the Basic Certificate Processing section 
                above. 
                 
                (l) This step needs to be modified to discount PCs when 
                evaluating conformance to max_path_length as follows: 
                 
                   If the certificate was not self-issued and the 
                   certificate type is not PC, verify that       
                   max_path_length is greater than zero and decrement 
                   max_path_length by 1. 
                 
                (n) Since keyCertSign is currently defined to be 
                equivalent to being a CA, this check needs to be 
                changed to accommodate PCs, as follows: If certificate 
                type is CA, and a key usage extension is present and 
                marked critical, verify that the keyCertSign bit is 
                set. 
                 
                (new) If certificate type is EEC or PC, and the key 
                usage extension is present, then set valid_pc_key_usage 
                to keyUsage, and set pc_key_usage_criticality to the 
                keyUsage criticality. 
                 


           
          [e-mail]                                          25 

          X.509 Proxy Certificate Profile                   October 2002 
                                                      Expires April 2003  
           

                (new) If certificate type is EEC or PC, and the 
                extended key usage extension is present, then set 
                valid_pc_ext_key_usage to extKeyUsage, and set 
                pc_ext_key_usage_criticality to the extKeyUsage 
                criticality. 
                 
                (new) Assign the certificate signatureAlgorithm to 
                working_issuer_signature_algorithm, and assign the 
                certificate signatureValue to 
                working_issuer_signature_value. 
                 
                (new) If certificate type is PC, verify that 
                max_pc_path_length is greater than zero and decrement 
                max_pc_path_length by 1. 
                 
             At this point we have no plans for a PI (that is, an EEC 
             or PC) to revoke the PCs that it has issued.  If this 
             feature is needed in the future, the CRL Distribution 
             Point extension can be used in the PI certificates to 
             locate a CRL. 
              
          5  Commentary 
              
             This section provides non-normative commentary on Proxy 
             Certificates. 
              
          5.1 Relationship to Attribute Certificates 
              
             An Attribute Certificate [4] can be used to grant to one 
             identity, the holder, some attribute such as a