📄 draft-ietf-pkix-proxy-03.txt
字号:
The subjectAltName extension MUST NOT be present in a Proxy Certificate. 3.6 Key Usage If the issuer certificate includes the keyUsage extension, then the Proxy Certificate MUST include a keyUsage extension, which MAY further restrict the issuer's keyUsage. If the issuer certificate does not include a keyUsage extension, then the Proxy Certificate MAY include a keyUsage extension to restrict the key usage of the Proxy Certificate. The keyUsage extension MUST be critical. If the keyUsage extension is present in a Proxy Certificate, it MUST conform to the following restrictions: . The keyCertSign bit MUST NOT be asserted. . The nonRepudiate bit MUST NOT be asserted. The following restriction applies to each of these bits: digitalSignature, keyEncipherment, tuecke@mcs.anl.gov 16 X.509 Proxy Certificate Profile October 2002 Expires April 2003 dataEncipherment, keyAgreement, cRLSign, encipherOnly, decipherOnly. If this bit in the issuer certificate is not asserted, then this bit in the Proxy Certificate MUST NOT be asserted. If this bit in the issuer certificate is asserted, or if the issuer certificate does not include a keyUsage extension, then this bit in the Proxy Certificate MAY be either asserted or not asserted. 3.7 Extended Key Usage If the issuer certificate includes the extKeyUsage extension, then: The Proxy Certificate MUST include an extKeyUsage extension. Any OID that is contained in the Proxy Certificate's extKeyUsage extension MUST be present in the issuer certificate's extKeyUsage extension. The Proxy Certificate's extKeyUsage extension MAY omit any OID that is present in the issuer certificate's extKeyUsage. If the issuer certificate's extKeyUsage extension is critical, then the Proxy Certificate's extKeyUsage MUST be critical. If the issuer certificate's extKeyUsage extension is not critical, then the Proxy Certificate's extKeyUsage MAY be critical or non-critical. If the issuer certificate does not include the extKeyUsage extension, then the Proxy Certificate MAY include an extKeyUsage extension to restrict the key usage of the Proxy Certificate. In this case, the extKeyUsage extension MAY be critical or non-critical. 3.8 Basic Constraints The cA field in the basic constraints extension MUST NOT be TRUE. tuecke@mcs.anl.gov 17 X.509 Proxy Certificate Profile October 2002 Expires April 2003 3.9 The ProxyCertInfo Extension A new extension, ProxyCertInfo, is defined in this subsection. Presence of the ProxyCertInfo extension indicates that a certificate is a Proxy Certificate and whether or not the issuer of the certificate has placed any restrictions on its use. id-ce-proxy-cert-info OBJECT IDENTIFIER ::= { id-ce ?? } ProxyCertInfo ::= SEQUENCE { version INTEGER (0..MAX), pCPathLenConstraint INTEGER (0..MAX) OPTIONAL, proxyPolicy ProxyPolicy } ProxyPolicy ::= SEQUENCE { policyLanguage OBJECT IDENTIFIER, policy OCTET STRING OPTIONAL } If a certificate is a Proxy Certificate, then the proxyCertInfo extension MUST be present, and this extension MUST be marked as critical. If a certificate is not a Proxy Certificate, then the proxyCertInfo extension MUST not be present. The ProxyCertInfo extension consists of one required and four optional fields, which are described in detail in the following subsections. 3.9.1 version The version of this specification that this PC conforms to. Currently this value MUST be 1. Future revisions of this specification MAY change this. If a proxy certificate contains a version that is unknown to a relying party the relying party MUST disregard the PC and it's chain when making authorization decisions. 3.9.2 pCPathLenConstraint tuecke@mcs.anl.gov 18 X.509 Proxy Certificate Profile October 2002 Expires April 2003 The pCPathLenConstraint field, if present, specifies the maximum depth of the path of Proxy Certificates that can be signed by this Proxy Certificate. A pCPathLenConstraint of 0 means that this certificate MUST NOT be used to sign a Proxy Certificate. If the proxyCertInfo extension is not present, or if the pCPathLenConstraint is not present, then the proxy path length is unlimited. 3.9.3 proxyPolicy The proxyPolicy field specifies a policy on the use of this certificate for the purposes of authorization. Within the proxyPolicy, the policy field is an expression of policy, and the policyLanguage field indicates the language in which the policy is expressed. The proxyPolicy field in the proxyCertInfo extension does not define a policy language to be used for proxy restrictions; rather, it places the burden on those parties using that extension to define an appropriate language, and to acquire an OID for that language (or to select an appropriate previously-defined language/OID). Because it is essential for the PI that issues a certificate with a proxyPolicy field and the relying party that interprets that field to agree on its meaning, the policy language OID must correspond to a policy language (including semantics), not just a policy grammar. The policyLanguage field has two values of special importance that MUST be understood by all parties accepting Proxy Certificates: * Impersonation as defined by the oid value (XXX TBD) indicates that this is an unrestricted proxy that inherits all rights from the issuing PI. An unrestricted proxy is a statement that the Proxy Issuer wishes to delegate all of its authority to the bearer (i.e., to anyone who has that proxy certificate and can prove possession of the associated private key). For purposes of authorization, this an unrestricted proxy effectively impersonates the issuing PI. tuecke@mcs.anl.gov 19 X.509 Proxy Certificate Profile October 2002 Expires April 2003 * Independent as defined by the oid value (XXX TDB) indicates that this is an independent proxy that inherits no rights from the issuing PI. This PC MUST be treated as an independent identity by relying parties. The only rights this PC has are those granted explicitly to it. For either of the policyLanguage values listed above, the policy field MUST NOT be present. Other values for the policyLanguage field indicates that this is a restricted proxy certification and have some other policy limiting it's ability to do impersonation. In this case the policy field MAY be present and it MUST contain information expressing the policy. If the policy field is not present the policy MUST be implicit in the value of the policyLanguage field itself. Proxy policies are used to limit the amount of authority delegated, for example to assert that the proxy certificate may be used only to make requests to a specific server, or only to authorize specific operations on specific resources. This document is agnostic to the policies that can be placed in the policy field. Proxy policies impose additional requirements on the relying party, because only the relying party is in a position to ensure that those policies are enforced. When making an authorization decision based on a proxy certificate, it is the relying party's responsibility to verify that the requested authority is compatible with all policies in the PC's certificate path. In other words, the relying party MUST verify that the following three conditions are all met: 1) If the PC includes a proxy policy, then the relying party knows how to interpret the policy and the request is allowed under that policy. 2) If the Proxy Issuer is an EEC, then the relying party's local policies authorize the request for the entity named in the EEC. tuecke@mcs.anl.gov 20 X.509 Proxy Certificate Profile October 2002 Expires April 2003 3) If the Proxy Issuer is another PC, then conditions (1), (2), and (3) are met for the Proxy Issuer. If these conditions are not met, the relying party MUST either deny authorization, or ignore the PC and the whole certificate chain including the EEC entirely when making its authorization decision (i.e., make the same decision that it would have made had the PC and it's certificate chain never been presented). Note that this verification MUST take place regardless of whether or not the PC itself contains a policy, as other PCs in the signing chain MAY contain conditions that MUST be verified. The relying party MAY impose additional restrictions as to which proxy certificates it accepts. For example, a relying party MAY choose to reject all proxy certificates, or MAY choose to accept proxy certificates only for certain operations, etc. Note that since a proxy certificate has a unique identity it MAY also have rights granted to it from other sources than it's issuer. This means that the rights granted to the bearer of a PC are the union of the rights granted to ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -