PKIX Working Group Internet Draft Ed Gerck Document: draft-gerck-pkix-revocation-00.txt NMA, Inc. Expires: November 2004 May 2004 Certificate Revocation Revisited Internet X.509 Public Key Infrastructure Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract PKIX certificate revocation protocols are primarily described in RFC3280. This Document revisits limitations on determining the revocation status of a certificate. Ambiguous aspects of revocation and revocation delegation are resolved. An objective point of view is introduced as a reference that does not depend on the observer (e.g., the RP). The revocation status of a certificate issued by a conforming CA is shown to be always well-defined from a relying party's point of view -- i.e., it is unambiguous (revoked or not revoked) and ultimately determinable at any period in time. The limitations on determining the revocation status of a certificate have nothing to do with the eventual result of the determination process by a relying party. The limitations have to do with the efforts for that determination, which may require a large (actually unspecified) amount of time and work. Some practices are also suggested, allowing a relying party to determine the revocation status of a certificate with higher reliability in less time. The same considerations apply to determinations of status "change" processes, including certificateHold and removefromCRL. Gerck Expires - November 2004 [Page 1] Certificate Revocation Revisited May 2004 Conventions used in this document In this document, a relying party (RP) is a user who processes a certificate chain, and then acts in reliance on the end-entity (EE) certificate issued by a CA (the issuer CA) and any associated revocation information. "Trust" is defined in [Ger98]. The "objective point of view" is defined as a coincident view that any RP can see in a given time period when not constrained by access, amount of work and processing time. The "RP point of view" is defined as a view that a particular RP can see in a given time period, which is constrained by several factors including access, amount of work and processing time. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. Table of Contents 1. Overview.......................................................3 2. Relying Party, RP Reliance and Reliance Limitations............5 3. Revocation Revisited...........................................6 3.1 Objective Point Of View....................................7 3.2 RP Point Of View...........................................8 3.3 RP Reliance Limitations....................................9 3.4 Revocation vs. Validity....................................9 3.5 Reliance vs. Use..........................................10 3.6 When is a Certificate Revoked?............................10 3.7 Conclusion................................................10 4. Revocation Conditions and Improvements........................11 4.1 Summary of Revocation Conditions..........................11 4.2 Available Revocation of Delegation........................11 4.3 Limitations of Indirect CRLs..............................12 4.4 Limitations of Revocation Status Services.................12 4.5 Limitations of Revocation Status Processing...............13 4.6 Increasing Reliability....................................13 4.7 Can A Certificate Be Valid When Revoked?..................14 4.8 Alternative Authoritative Revocation Mechanisms...........14 4.9 Validation Services.......................................14 4.10 New Environments.........................................15 Security Considerations..........................................15 References.......................................................15 Acknowledgments..................................................16 Author's Addresses...............................................16 Full Copyright Statement.........................................16 Gerck Expires - November 2004 [Page 2] Certificate Revocation Revisited May 2004 1. Overview This Document revisits the limitations of RP reliance on the revocation status of a X.509/PKIX certificate. This Document also points out the conditions on those limitations with a view to reducing their effect in current and future implementations, allowing a relying party to determine the revocation status of a certificate with higher reliability in less time. The same considerations apply to determinations of status "change" processes, including certificateHold and removefromCRL. PKIX certificate revocation protocols are primarily described in RFC3280, involving the conditions for designating a certificate as revoked as well as the conditions that enable a user to actually determine the revocation status of a certificate. The PKIX standardization effort aimed to safely automate the process of RP reliance. This goal required the PKIX certificate path processing algorithm to eliminate any violations of those policies (i.e., vulnerabilities) that might be hard to recognize or difficult to foresee, which would interfere with the goal of specifying a wholly automated process of handling certificates. For a particular certificate, revocation can be delegated to entities other than the issuer of the certificate. Similarly, parties other than the issuer, including the delegate responsible for revocation, can perform publication of revocation information. This means that an RP verifying the certificate's revocation status (e.g., using mechanisms such as querying a repository or receiving notices delivered via a message service) will depend on the administration and management of that status by one or more authoritative entities. In addition, different RPs may or may not have access to one or more of the authoritative repositories and/or authoritative message notification services. Also, each one of the repositories and notification services may possibly have different values and different delay properties concerning communication of revocation status for the same certificate, at any given time. Therefore, the revocation status of a particular certificate may appear to be revoked, non-revoked and undefined, all at the same time, for different RPs. Similar issues have been recognized and addressed in distributed transaction coordination protocols, such as file-locking in a multi- user environment, and these techniques are also useful for the reliance problem at hand. This document revisits and resolves the ambiguities besetting certificate revocation in PKIX, answering the following questions: Gerck Expires - November 2004 [Page 3] Certificate Revocation Revisited May 2004 1. What are the conditions for a certificate's revocation status to be true? 2. Can a certificate be, at the same time, revoked and not revoked? 3. Can a revocation status service ever correctly indicate a given certificate to be revoked when its revocation conditions are false? 4. Can a revocation status service ever correctly indicate non- revocation status for a given certificate when its revocation conditions are true? 5. When is a certificate revoked? 6. What are the limitations for an RP relying on the revocation status of a certificate? 7. Can current limitations for RP reliance on revocation information be reduced? This Document also calls attention to the distinction between "revocation conditions" and "revocation status". Revocation status is a binary value (revoked or not revoked) that depends on time and the revocation conditions. The revocation conditions are the logical conditions for defining the revocation status. Revocation conditions are normally defined for the life of the certificate, when the certificate is issued; however, they may also be authoritatively redefined from time to time. For example, to better address the needs of RPs. The revocation status of a certificate is not enough to define the validity of that certificate from a particular RP's point of view. Certificate validity is a function of a number of additional parameters, including the certificate path that the RP trusts to validate the certificate, the access to revocation status information available to the RP, the local policy used by the RP, and the PKI application that motivates the RP to employ certificates. The validity of a certificate refers to conditions that are authoritatively defined locally. The distinction between "revocation" and "validation" has been somewhat blurred in the documentation and practice. The distinction is, however, necessary to preserve both the control needs for PKI, requiring centralized conditions of revocation that are authoritatively defined by the issuer CA, and those business and user needs, requiring local authoritative definition of validation. Gerck Expires - November 2004 [Page 4] Certificate Revocation Revisited May 2004 RP reliance is discussed as a technical term. The concept of RP reliance is needed in PKIX/X.509 because not every aspect of certificate management can be fully verified by an RP. For example, an RP does not rely on the CA for certificate path processing but may rely on the CA for ensuring that the CA's signing key is properly secure and not compromised. The latter cannot be verified by the RP and becomes, thus, a limitation for reliance. Another important distinction is between "reliance" and "use". PKIX defines certificate reliance by an RP in terms of its issuance and revocation conditions as determined by the issuer CA. This may include how, where and when the revocation status is provided for a certificate. However, there is no violation of PKIX if a user (otherwise known as an RP) decides to be on its own and simply "uses" the certificate and its information, ignoring one or even all the limitations for reliance defined in PKIX and by an authority. A user can also use any source it desires for the revocation status of a certificate, including none at all. Notwithstanding all the above limitations, the conclusion of this Document is that the revocation status of a certificate issued by a conforming CA is always well-defined from the issuer's, the issuer's delegates and any RP's point of view -- i.e., it is objectively unambiguous (revoked or not revoked) and ultimately determinable at any period in time by any entity. The above limitations on determining the revocation status of a certificate have nothing to do with the eventual result of the determination process. The limitations have to do with the effort an RP must expend to make that determination, which may require a large (actually unspecified) amount of time and work. Depending on the users' reliance obligations, furthermore, Human intervention may also be necessary to augment automated path processing in those situations when complete elimination of Human oversight might cause foreseeable policy violations. For example, for the purpose of a user reading a timely message subject to a legal policy requiring it to be read upon receipt, a user may override waiting for the automated path processing result. In addition, some practices are suggested for publishing and verifying revocation information, allowing an RP to verify the revocation status of a certificate with greater reliability in less time. 2. Relying Party, RP Reliance and Reliance Limitations A relying party (RP) is a user who processes a certificate chain, and then acts in reliance on the end-entity (EE) certificate issued by a CA (the issuer CA) and any associated revocation information. Gerck Expires - November 2004 [Page 5] Certificate Revocation Revisited May 2004 RP reliance is a technical term in PKIX. The concept of RP reliance is needed in PKIX/X.509 because not every aspect of certificate management can be fully verified by an RP. For example, a user verifying a certificate's revocation status (e.g., using mechanisms such as querying a repository or receiving notices delivered via a message service) will depend on the conforming administration and management of that status by one or more authoritative entities -- i.e., the user becomes a relying party to these entities. More generally, a user who depends on values provided by an entity (e.g., CA) that seem reasonable on their face value to the user but are especially hard to check by the user is an RP to that entity. What does the RP rely on? The RP relies on entities (e.g., the CA) following PKIX recommendations that the RP CANNOT verify. For example, an RP does not rely on the CA for certificate path processing (because the RP CAN verify it) but may rely on the CA for ensuring that the CA's signing key is properly secure and not compromised. The latter cannot be verified by the RP and becomes, thus, a limitation for reliance. RP reliance limitations are objectively defined in PKIX, without reference to domain policies, user security policy, jurisdiction- based rules of laws and contracts or anything else that needs to be locally defined. As a literal value, RP reliance on the revocation status of a certificate is defined by a conforming certificate path procedure leading to a bit value -- "revoked" or "not revoked". The literal bit value depends both on processes that the RP CAN verify and processes that the RP CANNOT verify. The latter defines the limitations of RP reliance. The lesser the limitations of RP reliance, the lesser the risk faced by the RP that RP reliance might be broken by factors outside RP control. The literal bit value has no associated semantics outside the scope of PKIX. In other words, RP reliance is syntactic, not semantic. Any semantic value (e.g., legal reliance, contractual obligations concerning use, public policy, etc.) MUST lie outside the scope of PKIX and is, for example, regulated by terms in the CA's CPS. 3. Revocation Revisited Certificate revocation, involving the conditions for certificate revocation as well as the actual value of the revocation status for a certificate, has been defined in the PKIX specification with the Gerck Expires - November 2004 [Page 6] Certificate Revocation Revisited May 2004 requirement that a certificate path processing could be securely mechanized in support of RP reliance. Because a particular certificate may be used by different RPs at different times, it is desirable that all RPs have the same view of the revocation status of the certificate at a given time. Otherwise, the information that the certificate is not revoked at a given time cannot be relied on by an RP, or represented to another RP, at a later time. In other words, while the PKIX notion of RP reliance defines a value that is determined subjectively (i.e., the revocation status of a certificate from the RP's point of view) at a point in time, the application PKI requires the RP to use such value as an objective representation of the revocation status when communicating with other entities at a later point in time. A clear definition of the revocation status of a certificate from an objective point of view is necessary, therefore, to eliminate the ambiguity as to what that status might be for different RPs and entities. Central to this requirement is the determination when the certificate was revoked, also expressed in terms that an RP can use in communication with other entities. 2.13.1 Objective Point Of View The "objective point of view" is defined as a coincident view that any RP can see in a given time period when not constrained by access, amount of work and processing time. This point of view is called objective because it does not depend on the observer (e.g., the RP). What matters to the objective point of view is the revocation status of a certificate, be this represented in a repository or as a status message, and whether it has been published by some means reasonably available to any RP. 3.1.1 Does the objective point of view exist for PKIX certificates? Yes. In X.509/PKIX each certificate is unique and there is only one issuer CA for a given certificate. Only the issuer CA of a certificate is authoritative for revocation conditions of the certificate. Therefore, the issuer CA can define conditions leading to an objective view (i.e., a coincident view that any RP can see in a given time period when RPs are not constrained by practical limits such as access, amount of work and processing time) of the revocation status of a certificate. 3.1.2 What are the conditions for a certificate's revocation status to be true from the objective point of view? Gerck Expires - November 2004 [Page 7] Certificate Revocation Revisited May 2004 If a certificate is listed as revoked by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension (e.g., a CRL signed by the CA, an indirect CRL signed by the CRL issuer, an OCSP status, an HTTP CRL list), OR if any other revocation condition defined by the issuer CA applies (e.g., a root certificate is compromised), the certificate is revoked. Otherwise, the certificate is not revoked. 3.1.3 Can a certificate be, at the same time, revoked and not revoked from the objective point of view? No. Because the revocation status of a certificate refers to conditions that a conforming issuer CA authoritatively and unambiguously defines for each certificate, a certificate is either revoked or not from the objective point of view. 3.1.4 Is the revocation status of a certificate ambiguous, for different RPs? No. When not limited by access, amount of work and time, any RP sees the same value for the revocation status of a certificate at any period in time. 2.23.2 RP Point Of View From a particular RP's point of view, there are several limitations on determining the revocation status of a certificate at any given period in time. Generally, the RP's point of view is limited by access, amount of work and processing time, which are locally defined and may be different for each RP. For example, if an RP does not support any of the mechanisms defined by the issuer CA to verify the revocation status, or times out during such verification, or cannot find a path to verify the authenticity of messages used in certificate status protocols, then the revocation status is undefined for that RP. According to RFC3280, this can happen even for a conforming CA and conforming RP software. For example, conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided. This fails to interoperate with conforming applications, that are NOT REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA. Furthermore, since no CA MUST offer even one of the standardized mechanisms, conforming applications may be left groping in the dark for revocation information. Also, since there may be more than one scheme used to determine the revocation status of the same certificate, the occurrence of race Gerck Expires - November 2004 [Page 8] Certificate Revocation Revisited May 2004 conditions, differently available paths (even within the same scheme), and the conditions affecting the revocation status of the parent certificates can lead to ambiguous results for different RPs. Therefore, different RPs may arrive at a different "view" of the revocation status of a EE, CA or cross certificate at a particular time. 2.33.3 RP Reliance Limitations What are the limitations for an RP relying on the revocation status of a certificate? An RP relying on the revocation status of a certificate, determined by any mechanism (i.e., whose reliance is authorized or not by the issuer CA of the certificate), is nonetheless limited by the revocation conditions defined by the issuer CA. Those conditions may change from time to time. Some mechanisms may not include direct evidence of the issuer CA's assertion of a certificate's revocation status or conditions, at a particular time. 2.43.4 Revocation vs. Validity Another important distinction concerns the processes of "revocation" and "validation". Revocation and validation should be understood as distinct technical terms -- revocation has to do with the issuer's actions (or the actions of an issuer's delegate) while validation has to do with a relying party's actions. This distinction reflects the needs of the issuer (who seeks to control RP reliance limitations in order to impose uniform conditions of revocation and hence RP reliance) and the concurrent needs of each domain of business and individual users (whose reliance obligations require them to comply with their own domain's local, and possibly conflicting to other domains', authoritative definition of certificate validity). Clearly, revocation could not be well-defined if it were defined to be, at the same time, centralized and local. Introducing the validation concept provides the richer conceptual framework that addresses the presumed antagonistic needs of the issuer and the user, in the handling of RP reliance. There are also those cases in which user communities (i.e., domains) may choose to adopt one or other validation model based on some prevailing operational rationale. The flexibility of having both a centralized control over the conditions of revocation while supporting localized validation is an important feature of X.509/PKIX. Gerck Expires - November 2004 [Page 9] Certificate Revocation Revisited May 2004 2.53.5 Reliance vs. Use Another important distinction is between "reliance" and "use". The PKIX standards define the limitations for certificate reliance by an RP in terms of a certificate user complying with the issuance and revocation conditions for a certificate. Furthermore, PKIX requires that compliance must occur through execution of the standardized certificate path processing algorithm. However, there is no act of non-compliance if an RP simply decides to act independently of the authority, with a "use" of the certificate, rather than a "reliance upon" the certificate, its revocation conditions and its revocation status. When merely "using" a certificate in this sense, the user will normally be ignoring any or all the compliance requirements defined in PKIX and/or the authority, when processing a chain of certificates and using an EE certificate issued by a CA. 2.63.6 When is a Certificate Revoked? Here we ask the critical question: When is a certificate revoked? The answer is: when the corresponding revocation status is published by means of one of those mechanisms identified by the issuer CA in a conforming certificate extension, OR when any other revocation condition defined by the issuer CA applies. It does not matter when a particular RP is able to verify that status, or what mechanisms an RP can use for such purpose. Nor does it depend on the ultimate purpose of reliance, or the actual secondary use made of reliance during private communications between the RP and others after the reliance determination has been made. The revocation status of a certificate issued by a conforming CA does not depend on an RP and is always well-defined from an RP's point of view -- i.e., it is unambiguous (revoked or not revoked) and ultimately verifiable by the RP at any period in time. 2.73.7 Conclusion From an objective point of view, valid for all RPs relying on a particular certificate, a PKIX certificate is either revoked or not revoked at any period in time. From a particular RP's point of view, the limitations on determining the revocation status of a certificate have nothing to do with the eventual result of that determination, which is always well-defined - - i.e., it is unambiguous (revoked or not revoked) and ultimately determinable by the RP at any period in time. The limitations have to do with the efforts for that determination, which may require a large (actually, unspecified) amount of time and work. Human intervention may also be necessary. Gerck Expires - November 2004 [Page 10] Certificate Revocation Revisited May 2004 The same considerations apply to determinations of status "change" processes, including certificateHold and removefromCRL . 3.4. Revocation Conditions and Improvements This section expands and points out the conditions on some of the limitations discussed in section 2, with a view to reducing their effect. Further, practices are suggested for publishing and verifying revocation information, allowing an RP to determine the revocation status of a certificate with higher reliability in less time. 3.14.1 Summary of Revocation Conditions In X.509/PKIX there is only one issuer CA for a given certificate. Only the issuer CA of a certificate is authoritative for revocation conditions of the certificate, which is assumed to be uniquely identifiable (e.g., issued with a unique serial number for that CA). One of those revocation conditions is that the certificate must be signed by the CA's private "certificate signing" key. This key must be issued formally by the issuer CA, must not be expired and must not be presently revoked. Another condition is that the issuer CA may delegate the authority for a particular certificate's revocation notices and/or status publication to another entity called the CRL issuer, identified by the CA in the CRL Distribution Point (CDP) extension of the certificate. Another condition is that the issuer CA may send the revocation notice for a particular certificate as a status service to other types of delegated status services, identified by the CA in the Authority Information Access (AIA) extension of the certificate with an OCSP access descriptor or an HTTP CRL access descriptor. The RP should also determine if any of the CA certificates along the chain from the issuer CA to an acceptable root CA is expired or has been revoked or suspended, because such expiration, revocation or suspension could have the effect of prematurely terminating the operational period of the certificate and all certificates signed by it. 3.24.2 Available Revocation of Delegation Is there a mechanism to limit the period of delegation? Yes. The issuer CA can authoritatively revoke delegation to the CRL issuer, or other types of delegated status services. Delegation is not decided, although implied, for the whole lifetime of the certificate. Delegation is also not necessarily done for all certificates issued by a CA (e.g., an indirect CRL issuer may be a partial CRL issuer, in X.509). The issuer CA could revoke any signing Gerck Expires - November 2004 [Page 11] Certificate Revocation Revisited May 2004 certificate in the chain and re-issue all certificates it desires with a different delegation specification or even no delegation. This mechanism provides the CA with ultimate control over a wayward CRL issuer or other type of delegated status service provider. 3.34.3 Limitations of Indirect CRLs If the indirect CRL is verified by an RP, is there any requirement for the RP to also verify any CRL issued by the issuer CA? Yes. Because the RP must verify the signed CRL using certificates, and in particular must recursively rely upon the certificate showing that the CRL issuer (or other party) has current delegation authority, certificate revocation status also depends on whether the issuer CA signing certificate (or any certificate in an acceptable chain to the root) is expired, revoked or suspended, OR whether any other revocation condition defined by the issuer CA applies. See (2.3), (3.1), and (3.2). 3.44.4 Limitations of Revocation Status Services 4.4.1 Can a revocation status service or a CRL publishing service indicate a certificate to be revoked when the certificate is not revoked? Yes. If a CA sends status data to an OCSP Responder including a revocation notice before creating a CRL, the certificate in question is revoked for an RP receiving the OCSP Responder's status but not for an RP accessing only the current CRL. Even along a single certificate chain, different RPs may have access to different revocation status for the CA's own certificate or any cross certificate used in the chain. Further, as demanded by chain processing rules, an expired, revoked or suspended parent certificate may or may not cause an RP to deduce that a child certificate status is revoked, independently of the current authoritative revocation status of the certificate. Similarly, by recursion, an expired certificate used when relying upon an indirect CRL can also influence whether or not a user performs the act of reliance. 4.4.2 Can a revocation status service indicate non-revocation status when the certificate is revoked? Yes. As given above. Gerck Expires - November 2004 [Page 12] Certificate Revocation Revisited May 2004 3.54.5 Limitations of Revocation Status Processing Resolution of revocation status may be difficult for the RP's software. For example: the software may need, under the local validation policy, to wait for a fresher CRL then that currently available; the software may need more time than what is available for the desired action; the software may need additional communication channels that are not available to the software at the time of checking; the validation policy might require human intervention, and so on. Using any single mechanism to verify revocation status can be seen by an RP as introducing a single point of failure, which might not be acceptable. An RP relying on the revocation status of a certificate is also subject to the RP Reliance Limitations described in section (2.3). 3.64.6 Increasing Reliability With a view to reducing the effect of the limitations discussed in this Document, an RP can verify bounds on the extent of those limitations, or at least establish bounds. An RP can also define multiple paths, to provide redundancy and diversity. The additional efforts should increase the ability of the RP to make a reliance determination of a certificate's revocation status in less time. For example: - There are various unspecified and unpublished delays between the time a CA, CRL issuer or OCSP Responder receives notice to revoke, suspend, or reinstate a certificate and the time the information status is made available through the CA's CRL, an indirect CRL, a delta CRL, an OCSP Responder, a DPV Server, or a client. Nonetheless, some of these bounds can be actually known or modeled by an RP, and be addressed in the local validation policy underpinning the decision to rely. - To prevent single access faults and race conditions, a certificate can include multiple mechanisms to specify revocation information, some of which can be redundant mechanisms, where an RP should be able to interoperate with any of those mechanisms that it trusts. Multiple mechanisms available to an issuer CA include a CDP extension with a URI DistributionPointName, an AIA extension with an OCSP access descriptor, and an AIA extension with an HTTP CRL access descriptor. An RP receiving both an OCSP Responder's status and the CA's CRL for a certificate is less susceptible to race conditions caused by CA's delays when sending status data to the Gerck Expires - November 2004 [Page 13] Certificate Revocation Revisited May 2004 OCSP Responder with a revocation notice and publishing a CRL for the certificate in question. 3.74.7 Can A Certificate Be Valid When Revoked? 4.7.1 Can a certificate be valid when its revocation status is revoked? Yes. The validity of a certificate refers to conditions that are authoritatively defined locally (see section 2.4). For example, for the purpose of an RP reading a timely message, a validation policy may consider a certificate to be valid when no revocation status can be contacted. Generalizing this behavior is an implementation flaw, however. For example, the widely used TLS/SSL security application in Internet browsers does not currently verify the revocation status of EE and CA certificates and always considers the resulting undefined revocation status as valid. 4.7.2 Can an RP rely on validity information alone? Yes. As above. 3.84.8 Alternative Authoritative Revocation Mechanisms The PKIX WG has defined a number of certificate revocation protocols. However, it may be sometimes desirable to revoke certificates using alternative schemes as well. For example, a certificate can also be authoritatively revoked when the issuer CA or the CRL issuer makes the revocation status available to an RP in a reasonable way. For example, by signed XML messages in a wireless network, by SQL over HTTPS, or in a signed SOAP response for database lookup over web services. What matters to the RP is the revocation status, in a repository or as a status message, and whether it has been published by some means acceptable by the RP under its validation policy. 3.94.9 Validation Services A CRL Issuer or an OCSP responder may perform additional processing, beyond aggregating and republishing revocation notices as revocation status services. If the operator of the service knows an RP's validation policy/criteria, they may apply those criteria when creating a validation service for that RP. In this case, the "validation service" is a policy-enhanced validation (not revocation) status service tuned to the acceptance processes of the RP, rather than only to the revocation processes of CAs and their delegates. Gerck Expires - November 2004 [Page 14] Certificate Revocation Revisited May 2004 A validation service can help reduce the limitations described in this Document, for example by implementing the multiple mechanisms discussed in section (3.6). In this case, the service provider is an agent of the RP, performing the same validation processing as the user would have performed when making a reliance determination. 3.104.10 New Environments This Document also intends to provide a framework for the development of new PKI environments, including IPSEC, Internet 2, IPv6 and routing table distribution schemes, DNS, and spam control. These new environments will also present new demands on PKI techniques, in particular on the handling of revocation information. Security Considerations Revocation lists, or CRLs, are needed to notify that an otherwise valid certificate is not valid. This, which relies on the issuer CA for centralized revocation conditions, presents several unsolved (implementation wise) and unsolvable (design wise) problems in X.509/PKIX. For example, there may be a considerable delay (no boundaries are provided within PKIX on upper limits for such delays) between a revocation notice (e.g., as submitted by the certificate's subject) and the reflection of this need in a CRL or revocation status. The available documentation is also silent about some aspects of revocation and revocation delegation. This silence may be read as implying some affirmations and denying others. This is faulty, because the meaning of the text is ambiguous for security purposes. This Document clarifies affirmations and limitations on certificate revocation that are coherent with the corpus of X.509/PKIX documents, thereby potentially improving security. The final section of this Document also points out the conditions on those limitations, with a view to reducing their effect. Using any single mechanism to verify revocation status is seen as introducing a single point of failure from the RP's software point of view. Using multiple sources of information on the revocation status of a certificate can provide diversity and redundancy, reducing the influence of race conditions and ambiguity. References [Ger98] In terms of a communication process, trust has nothing to do with feelings or emotions. Trust is qualified reliance on information, based on factors independent of that information. Trust needs multiple, independent channels to be communicated. Trust cannot be induced by self-assertions. Gerck Expires - November 2004 [Page 15] Certificate Revocation Revisited May 2004 More precisely, "Trust is that which is essential to a communication channel but cannot be transferred using that channel." See "Trust Points" by E. Gerck in "Digital Certificates: Applied Internet Security" by Jalal Feghhi, Jalil Feghhi and Peter Williams, Addison-Wesley, ISBN 0-20- 130980-7, pages 194-195, 1998. [Sha48] Shannon, C. A Mathematical Theory of Communication. Bell Syst. Tech. J., vol. 27, pp. 379-423, July 1948. http://cm.belllabs.com/cm/ms/what/shannonday/paper.html Acknowledgments The names cited do not mean endorsement of this work, which is the sole responsibility of the author. I would like to thank very useful comments by Santoshi Chokhani, Tom Gidin, Paul Hoffman, David Kemp, Steve Kent, Stefan Santesson, Peter Williams, Julien Stern and the PKIX list. I am also thankful to Peter Williams for final editing comments. Author's Addresses Questions about this Document can be directed to: Ed Gerck NMA, Inc. 1001 D Street San Rafael, CA 94901 Email: egerck@nma.com Full Copyright Statement Copyright (c) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Gerck Expires - November 2004 [Page 16] Certificate Revocation Revisited May 2004 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Gerck Expires - November 2004 [Page 17]