Merge pull request #1 from devonobrien/devonobrien-rejection-criteria

Update log_policy.md

log_policy.md

@@ -38,6 +38,7 @@ Chromium Issue Tracker, and provide:
     for logging certificates
   * The Maximum Merge Delay (MMD) of the Log
   * All of the Accepted Root Certificates of the Log
+  * Whether the Log will reject certificate logging requests based on any of the Permissible Logging Rejection Criteria and if so, which criteria will be used as a basis for rejection by this Log.
 
 After acceptance, Google will monitor the Log, including random compliance
 testing, prior to its inclusion within Chromium. Such compliance testing will
@@ -57,7 +58,7 @@ operate the Log in accordance with this Policy. Log Operators must:
   * Have no outage that exceeds an MMD of more than 24 hours.
     Outages include, but are not limited to: network level outages, expiration
     of the Log’s SSL certificate, a failure to accept new Certificates to be
-    logged, HTTP response status codes other than 200, or responses that
+    logged (with the exception of the Permissible Logging Rejection Criteria defined below), HTTP response status codes other than 200, or responses that
     include data that does not conform to RFC 6962.
   * Conform to RFC 6962, including the implementation of all API endpoints
     defined within Section 4 of RFC 6962
@@ -87,6 +88,18 @@ of changes to these requirements. Log Operators that fail to meet these
 requirements will be in violation of the Log Inclusion Policy, which may
 result in removal of the Log from the Chromium projects.
 
+## Permissible Logging Rejection Criteria
+
+Under certain circumstances, it is permissible for a Log to reject logging requests for certain classes of certificates. A logging rejection means that the Log will not incorporate a given certificate entry into the Merkle Tree even if the certificate chains to an Accepted Root Certificate. In accordance with this policy, rejected logging requests must not be issued an SCT by the Log. 
+
+If specified within the Log's Chromium Application, a Log may reject requests to log certificates that chain up to an Accepted Root Certificate based on one or more of the following bases: 
+
+  * **Revocation Status**: If the Log determines that a certificate has been revoked by the issuing CA, it may reject the logging request. If the Log is unable to determine revocation status, it must accept the logging request and incorporate the entry into the Merkle Tree within the Log's MMD.
+  * **Certificate Expired**: If a logging request includes a certificate whose notAfter timestamp represents a point in time before the logging request is made, the Log may refuse to log the certificate entry.
+  * **Certificate Lifetime**: In order to control the growth of a Log’s size, a Log Operator may specify a certificate expiry range for that Log, which must be included in the Log’s Chromium Application in the form of two dates: [rangeBegin, rangeEnd). The certificate expiry range allows a Log to reject logging requests for certificates whose notAfter timestamp falls outside of this range, thus partitioning the set of publicly-trusted certificates that the Log will accept. In the spirit of operating Logs in the public interest, Log Operators who take advantage of this limitation are strongly encouraged to operate multiple Logs with staggered certificate expiry ranges to allow for logging of all currently valid publicly-trusted certificates. 
+
+The primary purpose of the permissible rejection criteria is to provide Log Operators with greater control over the growth and operation of a given Log instance while still performing the core functions of a trusted CT Log. Additionally, these criteria allow logs to be shielded from certain types of Denial of Service such as being spammed with the corpus of all expired certificates and being unable to respond to legitimate logging requests.
+
 ## Policy Violations
 
 The Chromium developers include Logs at their sole discretion, to further