Chromium's CT Log Policy Update: Permissible Rejection Criteria

[Devon O'Brien]

We’d like to announce an update to Chromium’s Certificate Transparency Log Policy. In an effort to address several operational concerns surrounding Log operation, we’ve defined a set of Permissible Logging Rejection Criteria that, if specified in the Log’s Chromium Application, will allow a Log Operator to reject requests to log certain classes of certificate logging requests:

1. Log Operators will be able to reject certificates that are expired at the time of the logging request, which substantially reduces the corpus of existing certificates that can be used to bog down a Log. Once logging of certificates at issuance becomes ubiquitous, all recently-expired certificates will eventually exist in some trusted log within the CT ecosystem.

2. If able to determine that a certificate is revoked at time of the certificate logging request, a Log Operator will be able to reject this request. As with Criterion 1, revoked certificates will be present in some set of trusted logs at time of issuance and therefore should not need to be logged again after revocation. Inability to determine revocation status requires that the request be accepted and logged.

3. Due to the possibility of unbounded Log size growth and the operational cost that large Merkle Trees have on a Log, many Log Operators have been looking for the ability to temporally shard a set of Logs to distribute the logging burden across multiple Logs. Log Operators can now specify a window of time for which a Log will only accept certificates whose notAfter date falls within this range. This allows Log Operators to stand up a series of logs with staggered windows with the ability to freeze individual Logs after their window expires.

These criteria were first identified (Issues 6 and 7) in the Spring 2017 Certificate Transparency Policy Days as a mechanism to ease the burden on Log Operators in the face of increasing logging volumes caused by ubiquitous logging of TLS certificates.

As always, we appreciate feedback from the CT community in both discussion on the ct-policy group as well as in the form of issues on the ct-policy github page.

[Alex Gaynor]

Hi Devon,

I'm not sure (1) makes sense. Here's a few reasons:

* Unless I'm very much mistaken, the volume of revoked certificates does not justify special treatment.

* Revoked certificates are often the _most_ important to have logged, as they potentially indicate mis-issuance. Lowering the barrier to having these in a "widely known" log is important.

* Many (most? damn near all?) RPs do not check revocation information, revoked is a poor proxy for "definitely no one will attempt to use this"

Alex

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/e78d5aac-b5b4-46cc-8e67-6553112b94c6%40chromium.org.

[Pierre Phaneuf]

Did you mean (2)? (1) is about expired certificates, not revoked
certificates, as far as I can tell?

>> email to ct-policy+...@chromium.org.

>> To post to this group, send email to ct-p...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/e78d5aac-b5b4-46cc-8e67-6553112b94c6%40chromium.org.
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to ct-policy+...@chromium.org.

> To post to this group, send email to ct-p...@chromium.org.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAGzK4uPh_8k2uNCNKRUTw0NsrvDAb5K4qfEiL76YezhwavHxmg%40mail.gmail.com.

[Alex Gaynor]

Sigh, yes. And I've even had my morning caffeine so I can't use that excuse....

Alex

>> email to ct-policy+unsubscribe@chromium.org.

>> To post to this group, send email to ct-p...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/e78d5aac-b5b4-46cc-8e67-6553112b94c6%40chromium.org.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to ct-policy+unsubscribe@chromium.org.

> To post to this group, send email to ct-p...@chromium.org.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAGzK4uPh_8k2uNCNKRUTw0NsrvDAb5K4qfEiL76YezhwavHxmg%40mail.gmail.com.

[Richard Salz]

I agree with corrected Alex, and would like to hear more about the volumes of revoked certificates impacting logs.  Even one anecdote would help.

[Peter Bowen]

How about changing the revocation rule to only check revoked CA
certificates? E.g.

Revocation Status: If the Log determines that a CA-certificate in the
chain 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.

This makes things much easier from both an implementation perspective
and a risk perspective. We know that "logging of certificates at
issuance" is a long way off and no one has suggested to require such
of CAs, so the concept that "revoked certificates will be present in
some set of trusted logs at time of issuance" is not something that is
going to happen in the forseeable future.

Thanks,
Peter

On Mon, Aug 7, 2017 at 6:11 AM, Alex Gaynor <aga...@mozilla.com> wrote:
> Hi Devon,
>

> I'm not sure (2) makes sense. Here's a few reasons:

>> email to ct-policy+...@chromium.org.

>> To post to this group, send email to ct-p...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/e78d5aac-b5b4-46cc-8e67-6553112b94c6%40chromium.org.
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to ct-policy+...@chromium.org.

> To post to this group, send email to ct-p...@chromium.org.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAGzK4uPh_8k2uNCNKRUTw0NsrvDAb5K4qfEiL76YezhwavHxmg%40mail.gmail.com.

[Jeremy Rowley]

Why not permit the log operator to exclude revoked end entity certs? It's not mandating revoked certs be excluded, but giving the permission to each log operator to exclude them. Anecdotally, people dump revoked and expired certs in our log all the time. We ended up having to throttle the number of submitted certs just to handle the certs that really shouldn't matter anymore. 

>> email to ct-policy+unsubscribe@chromium.org.

>> To post to this group, send email to ct-p...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/e78d5aac-b5b4-46cc-8e67-6553112b94c6%40chromium.org.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Certificate Transparency Policy" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to ct-policy+unsubscribe@chromium.org.

> To post to this group, send email to ct-p...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAGzK4uPh_8k2uNCNKRUTw0NsrvDAb5K4qfEiL76YezhwavHxmg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.

To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAK6vND90kzYbdcvXC3ZMOiCqWF1OYCy-5cstrz-DLkbo_7TxVQ%40mail.gmail.com.

[Devon O'Brien]

On Monday, August 7, 2017 at 6:11:05 AM UTC-7, Alex Gaynor wrote:

Hi Devon,

I'm not sure (1) makes sense. Here's a few reasons:

* Unless I'm very much mistaken, the volume of revoked certificates does not justify special treatment.

I'm unsure that criterion 2 really qualifies as special treatment. After April 2018, all newly-issued TLS certificates are required to be logged in a policy-compliant set of CT logs in order to be trusted in Chrome. Regardless of revocation status, and even if revocation status is not known, Chrome will require that there exist a sufficient number of SCTs to validate. I could see how specifying an effective notBefore date that aligns with mandatory CT logging would close that small window where issuance logging isn't enforced. Would that address your concern?

Additionally, Logs are not required to reject revoked certificate logging requests and for the foreseeable future, none of them will do so. So long as there exist a handful of trusted logs that will still accept revoked certs, shouldn't that be sufficient? Due to the complexities of implementing revocation status checking at the scale at which logs operate, I'm aware of several logs that will not implement this even given the ability to do so.

 

* Revoked certificates are often the _most_ important to have logged, as they potentially indicate mis-issuance. Lowering the barrier to having these in a "widely known" log is important.

Are you referring specifically to a mis-issuance pertaining to failure to log at issuance? For all other forms of mis-issuance, the logging at time of issuance should be sufficient if the certificate is to be considered valid to CT-enforcing clients and will achieve your goal for detection. For mis-issuance that pertains to failure to log, these certificates will not be trusted by Chrome if issued after April 2018.

 

* Many (most? damn near all?) RPs do not check revocation information, revoked is a poor proxy for "definitely no one will attempt to use this"

Returning to the notBefore alignment idea, regardless of revocation status, if Chrome is unable to obtain sufficient valid SCTs, it will refuse to validate these certificates. Since CT logging will be a necessary, but not sufficient, requirement for validating certificates, I don't see this criterion as enabling relying upon revocation for cert use, as these two requirements are orthogonal.

Alex

On Fri, Aug 4, 2017 at 6:43 PM, Devon O'Brien <asymm...@chromium.org> wrote:

We’d like to announce an update to Chromium’s Certificate Transparency Log Policy. In an effort to address several operational concerns surrounding Log operation, we’ve defined a set of Permissible Logging Rejection Criteria that, if specified in the Log’s Chromium Application, will allow a Log Operator to reject requests to log certain classes of certificate logging requests:

1. Log Operators will be able to reject certificates that are expired at the time of the logging request, which substantially reduces the corpus of existing certificates that can be used to bog down a Log. Once logging of certificates at issuance becomes ubiquitous, all recently-expired certificates will eventually exist in some trusted log within the CT ecosystem.

2. If able to determine that a certificate is revoked at time of the certificate logging request, a Log Operator will be able to reject this request. As with Criterion 1, revoked certificates will be present in some set of trusted logs at time of issuance and therefore should not need to be logged again after revocation. Inability to determine revocation status requires that the request be accepted and logged.

3. Due to the possibility of unbounded Log size growth and the operational cost that large Merkle Trees have on a Log, many Log Operators have been looking for the ability to temporally shard a set of Logs to distribute the logging burden across multiple Logs. Log Operators can now specify a window of time for which a Log will only accept certificates whose notAfter date falls within this range. This allows Log Operators to stand up a series of logs with staggered windows with the ability to freeze individual Logs after their window expires.

These criteria were first identified (Issues 6 and 7) in the Spring 2017 Certificate Transparency Policy Days as a mechanism to ease the burden on Log Operators in the face of increasing logging volumes caused by ubiquitous logging of TLS certificates.

As always, we appreciate feedback from the CT community in both discussion on the ct-policy group as well as in the form of issues on the ct-policy github page.

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.

[Ryan Sleevi]

On Mon, Aug 7, 2017 at 9:11 AM, Alex Gaynor <aga...@mozilla.com> wrote:
> Hi Devon,
>
> I'm not sure (1) makes sense. Here's a few reasons:
>
> * Unless I'm very much mistaken, the volume of revoked certificates does not
> justify special treatment.
> * Revoked certificates are often the _most_ important to have logged, as
> they potentially indicate mis-issuance. Lowering the barrier to having these
> in a "widely known" log is important.
> * Many (most? damn near all?) RPs do not check revocation information,
> revoked is a poor proxy for "definitely no one will attempt to use this"

Hi Alex,

I didn't see this addressed (except indirectly through Peter's
response), but the volume of revoked certificates absolutely justifies
special treatment - because it's potentially unbounded!

That is, just like self-signed certificates are rejected from logs
(both from a spam and abuse perspective), revoked certificates
(particularly CA certificates) are a vector of unbounded issuance and
non-standard issuance.

Consider, for example, a CA key that goes through compromise and is
revoked (whether it's a technically constrained sub-CA or not is
irrelevant). The issuing CA has, in effect, disclaimed all
responsibility for the issuance of that certificate - and anything it
issues - since they can no longer control it. The holder of that
private key could, for example, create 10 million 'evil' certs
offline, and then suddenly present them all to a log at once -
creating a load issue. Even if CT Logs distribute load fairly through
the set of trust anchors supported, it means that the issuing CA
(which has revoked this certificate) is now effectively prevented from
logging their own legitimate certificates, because their load is being
consumed by the malicious party.

I'm not sure I fully understand your concerns about wanting to ensure
revoked certificates are logged. At best, the only scenario I can see
impacted is third-party logging (e.g. logging not by the CA or the
certificate holder), but at that point, they have the certificate
anyways, and can provide it to interested parties via other means.
Alternatively, one can always use 'non-production' logs (or "archival"
logs, if you will) to allow more liberal logging, while not being as
concerned with the DoS or spam potential.

[Alex Gaynor]

On Mon, Aug 7, 2017 at 7:40 PM, Devon O'Brien <asymm...@chromium.org> wrote:

On Monday, August 7, 2017 at 6:11:05 AM UTC-7, Alex Gaynor wrote:

Hi Devon,

I'm not sure (1) makes sense. Here's a few reasons:

* Unless I'm very much mistaken, the volume of revoked certificates does not justify special treatment.

I'm unsure that criterion 2 really qualifies as special treatment. After April 2018, all newly-issued TLS certificates are required to be logged in a policy-compliant set of CT logs in order to be trusted in Chrome. Regardless of revocation status, and even if revocation status is not known, Chrome will require that there exist a sufficient number of SCTs to validate. I could see how specifying an effective notBefore date that aligns with mandatory CT logging would close that small window where issuance logging isn't enforced. Would that address your concern?

As far as I'm aware, there's no requirement for issuance logging that's been proposed. This is important because it means as long as a subscriber doesn't plan on using their cert with a Chrome browser, there's no particular reason to log it. Certs that are not logged at issuance time are an important consideration, because while, without SCTs, they will not be trusted by Chrome, misissuance or other CA failures are still very pressing with them.

 

Additionally, Logs are not required to reject revoked certificate logging requests and for the foreseeable future, none of them will do so. So long as there exist a handful of trusted logs that will still accept revoked certs, shouldn't that be sufficient? Due to the complexities of implementing revocation status checking at the scale at which logs operate, I'm aware of several logs that will not implement this even given the ability to do so.

If no one is actually going to use this, all objections are a bit academic :-)

 

 

* Revoked certificates are often the _most_ important to have logged, as they potentially indicate mis-issuance. Lowering the barrier to having these in a "widely known" log is important.

Are you referring specifically to a mis-issuance pertaining to failure to log at issuance? For all other forms of mis-issuance, the logging at time of issuance should be sufficient if the certificate is to be considered valid to CT-enforcing clients and will achieve your goal for detection. For mis-issuance that pertains to failure to log, these certificates will not be trusted by Chrome if issued after April 2018.

As I stated, there is no requirement to log at issuance time; failure to log is not misissuance at all.

 

 

* Many (most? damn near all?) RPs do not check revocation information, revoked is a poor proxy for "definitely no one will attempt to use this"

Returning to the notBefore alignment idea, regardless of revocation status, if Chrome is unable to obtain sufficient valid SCTs, it will refuse to validate these certificates. Since CT logging will be a necessary, but not sufficient, requirement for validating certificates, I don't see this criterion as enabling relying upon revocation for cert use, as these two requirements are orthogonal.

Yes, I agree they're orthagonal.

My broader point is that CT has uses beyond obtaining SCTs for trust in Chrome -- they've become their own ecosystem with tooling and monitoring which is used to track CA performance. If we make it harder to track failures, all RPs will be hurt.

Alex

 

Alex

On Fri, Aug 4, 2017 at 6:43 PM, Devon O'Brien <asymm...@chromium.org> wrote:

We’d like to announce an update to Chromium’s Certificate Transparency Log Policy. In an effort to address several operational concerns surrounding Log operation, we’ve defined a set of Permissible Logging Rejection Criteria that, if specified in the Log’s Chromium Application, will allow a Log Operator to reject requests to log certain classes of certificate logging requests:

1. Log Operators will be able to reject certificates that are expired at the time of the logging request, which substantially reduces the corpus of existing certificates that can be used to bog down a Log. Once logging of certificates at issuance becomes ubiquitous, all recently-expired certificates will eventually exist in some trusted log within the CT ecosystem.

2. If able to determine that a certificate is revoked at time of the certificate logging request, a Log Operator will be able to reject this request. As with Criterion 1, revoked certificates will be present in some set of trusted logs at time of issuance and therefore should not need to be logged again after revocation. Inability to determine revocation status requires that the request be accepted and logged.

3. Due to the possibility of unbounded Log size growth and the operational cost that large Merkle Trees have on a Log, many Log Operators have been looking for the ability to temporally shard a set of Logs to distribute the logging burden across multiple Logs. Log Operators can now specify a window of time for which a Log will only accept certificates whose notAfter date falls within this range. This allows Log Operators to stand up a series of logs with staggered windows with the ability to freeze individual Logs after their window expires.

These criteria were first identified (Issues 6 and 7) in the Spring 2017 Certificate Transparency Policy Days as a mechanism to ease the burden on Log Operators in the face of increasing logging volumes caused by ubiquitous logging of TLS certificates.

As always, we appreciate feedback from the CT community in both discussion on the ct-policy group as well as in the form of issues on the ct-policy github page.

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/e78d5aac-b5b4-46cc-8e67-6553112b94c6%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.

To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/883e1d80-8d4d-4e67-86f7-25b95e6e56aa%40chromium.org.

[Devon O'Brien]

On Thursday, August 10, 2017 at 10:40:29 AM UTC-7, Alex Gaynor wrote:

On Mon, Aug 7, 2017 at 7:40 PM, Devon O'Brien <asymm...@chromium.org> wrote:

On Monday, August 7, 2017 at 6:11:05 AM UTC-7, Alex Gaynor wrote:

Hi Devon,

I'm not sure (1) makes sense. Here's a few reasons:

* Unless I'm very much mistaken, the volume of revoked certificates does not justify special treatment.

I'm unsure that criterion 2 really qualifies as special treatment. After April 2018, all newly-issued TLS certificates are required to be logged in a policy-compliant set of CT logs in order to be trusted in Chrome. Regardless of revocation status, and even if revocation status is not known, Chrome will require that there exist a sufficient number of SCTs to validate. I could see how specifying an effective notBefore date that aligns with mandatory CT logging would close that small window where issuance logging isn't enforced. Would that address your concern?

As far as I'm aware, there's no requirement for issuance logging that's been proposed. This is important because it means as long as a subscriber doesn't plan on using their cert with a Chrome browser, there's no particular reason to log it. Certs that are not logged at issuance time are an important consideration, because while, without SCTs, they will not be trusted by Chrome, misissuance or other CA failures are still very pressing with them.

 

You're right. Let me rephrase what I was trying to say since I wandered into bad verbiage. In April 2018, in order for new TLS certificates to be trusted in Chrome, the client must receive a policy-satisfying set of SCTs. This is true regardless of revocation status, as well as whether the client is able to determine revocation status. The primary goal of this policy is to ensure that Chrome clients do not trust certificates that haven't been logged (and hopefully monitored and audited), and failure to log a certificate before it is revoked means that the certificate will not be trusted. After revocation, the certificate is clearly no longer intended to be trusted and failure to log only ensures that the certificate remains untrusted.

Just because there aren't a lot of revoked leaf certificates in existence today, there is nothing stopping any trusted CA from revoking en masse and therefore supplying a long-term corpus of certificates that can be used exactly the way expired certificates can to bog down a log.

 

Additionally, Logs are not required to reject revoked certificate logging requests and for the foreseeable future, none of them will do so. So long as there exist a handful of trusted logs that will still accept revoked certs, shouldn't that be sufficient? Due to the complexities of implementing revocation status checking at the scale at which logs operate, I'm aware of several logs that will not implement this even given the ability to do so.

If no one is actually going to use this, all objections are a bit academic :-)

I think we're discussing "not all logs" using this, not "none of the logs". If there exists at least a handful of logs that don't utilize this criterion, and there does, isn't the objection still also academic? 

 

 

 

* Revoked certificates are often the _most_ important to have logged, as they potentially indicate mis-issuance. Lowering the barrier to having these in a "widely known" log is important.

Are you referring specifically to a mis-issuance pertaining to failure to log at issuance? For all other forms of mis-issuance, the logging at time of issuance should be sufficient if the certificate is to be considered valid to CT-enforcing clients and will achieve your goal for detection. For mis-issuance that pertains to failure to log, these certificates will not be trusted by Chrome if issued after April 2018.

As I stated, there is no requirement to log at issuance time; failure to log is not misissuance at all.

 

 

* Many (most? damn near all?) RPs do not check revocation information, revoked is a poor proxy for "definitely no one will attempt to use this"

Returning to the notBefore alignment idea, regardless of revocation status, if Chrome is unable to obtain sufficient valid SCTs, it will refuse to validate these certificates. Since CT logging will be a necessary, but not sufficient, requirement for validating certificates, I don't see this criterion as enabling relying upon revocation for cert use, as these two requirements are orthogonal.

Yes, I agree they're orthogonal.

My broader point is that CT has uses beyond obtaining SCTs for trust in Chrome -- they've become their own ecosystem with tooling and monitoring which is used to track CA performance. If we make it harder to track failures, all RPs will be hurt.

I'm totally in agreement with you about the broad benefits of CT, but I'm not sure the Chrome CT Policy is necessarily the place to address uses of CT outside of Chrome client validation behavior. I think Root Store Operators have a strong vested interest in, and are positioned to act upon, requiring CAs log to CT as a means of detecting all forms of misissuance and BR non-compliance. I'd be excited to discuss adding requirements to them at the next CT Policy Days!

 

Alex

 

-Devon 

[Alex Gaynor]

On Fri, Aug 11, 2017 at 3:11 PM, Devon O'Brien <asymm...@chromium.org> wrote:

On Thursday, August 10, 2017 at 10:40:29 AM UTC-7, Alex Gaynor wrote:

On Mon, Aug 7, 2017 at 7:40 PM, Devon O'Brien <asymm...@chromium.org> wrote:

On Monday, August 7, 2017 at 6:11:05 AM UTC-7, Alex Gaynor wrote:

Hi Devon,

I'm not sure (1) makes sense. Here's a few reasons:

* Unless I'm very much mistaken, the volume of revoked certificates does not justify special treatment.

I'm unsure that criterion 2 really qualifies as special treatment. After April 2018, all newly-issued TLS certificates are required to be logged in a policy-compliant set of CT logs in order to be trusted in Chrome. Regardless of revocation status, and even if revocation status is not known, Chrome will require that there exist a sufficient number of SCTs to validate. I could see how specifying an effective notBefore date that aligns with mandatory CT logging would close that small window where issuance logging isn't enforced. Would that address your concern?

As far as I'm aware, there's no requirement for issuance logging that's been proposed. This is important because it means as long as a subscriber doesn't plan on using their cert with a Chrome browser, there's no particular reason to log it. Certs that are not logged at issuance time are an important consideration, because while, without SCTs, they will not be trusted by Chrome, misissuance or other CA failures are still very pressing with them.

 

You're right. Let me rephrase what I was trying to say since I wandered into bad verbiage. In April 2018, in order for new TLS certificates to be trusted in Chrome, the client must receive a policy-satisfying set of SCTs. This is true regardless of revocation status, as well as whether the client is able to determine revocation status. The primary goal of this policy is to ensure that Chrome clients do not trust certificates that haven't been logged (and hopefully monitored and audited), and failure to log a certificate before it is revoked means that the certificate will not be trusted. After revocation, the certificate is clearly no longer intended to be trusted and failure to log only ensures that the certificate remains untrusted.

Just because there aren't a lot of revoked leaf certificates in existence today, there is nothing stopping any trusted CA from revoking en masse and therefore supplying a long-term corpus of certificates that can be used exactly the way expired certificates can to bog down a log.

Revoked CA is a more interesting case.

For trusted CAs, there's nothing to stop them from issuing new certificates en masse! The same expired certificate filter which prevents large volumes of certs from being used in perpetuity on logs would apply to revoked (and also expired) certs would it not?

 

 

Additionally, Logs are not required to reject revoked certificate logging requests and for the foreseeable future, none of them will do so. So long as there exist a handful of trusted logs that will still accept revoked certs, shouldn't that be sufficient? Due to the complexities of implementing revocation status checking at the scale at which logs operate, I'm aware of several logs that will not implement this even given the ability to do so.

If no one is actually going to use this, all objections are a bit academic :-)

I think we're discussing "not all logs" using this, not "none of the logs". If there exists at least a handful of logs that don't utilize this criterion, and there does, isn't the objection still also academic? 

More or less, yes. If you're sure that there'll be some logs within the ecosystem still accepting revoked ones, my level of care decreases, though my position ultimately doesn't change :-)

 

 

 

 

* Revoked certificates are often the _most_ important to have logged, as they potentially indicate mis-issuance. Lowering the barrier to having these in a "widely known" log is important.

Are you referring specifically to a mis-issuance pertaining to failure to log at issuance? For all other forms of mis-issuance, the logging at time of issuance should be sufficient if the certificate is to be considered valid to CT-enforcing clients and will achieve your goal for detection. For mis-issuance that pertains to failure to log, these certificates will not be trusted by Chrome if issued after April 2018.

As I stated, there is no requirement to log at issuance time; failure to log is not misissuance at all.

 

 

* Many (most? damn near all?) RPs do not check revocation information, revoked is a poor proxy for "definitely no one will attempt to use this"

Returning to the notBefore alignment idea, regardless of revocation status, if Chrome is unable to obtain sufficient valid SCTs, it will refuse to validate these certificates. Since CT logging will be a necessary, but not sufficient, requirement for validating certificates, I don't see this criterion as enabling relying upon revocation for cert use, as these two requirements are orthogonal.

Yes, I agree they're orthogonal.

My broader point is that CT has uses beyond obtaining SCTs for trust in Chrome -- they've become their own ecosystem with tooling and monitoring which is used to track CA performance. If we make it harder to track failures, all RPs will be hurt.

I'm totally in agreement with you about the broad benefits of CT, but I'm not sure the Chrome CT Policy is necessarily the place to address uses of CT outside of Chrome client validation behavior. I think Root Store Operators have a strong vested interest in, and are positioned to act upon, requiring CAs log to CT as a means of detecting all forms of misissuance and BR non-compliance. I'd be excited to discuss adding requirements to them at the next CT Policy Days!

 

Alex

 

-Devon 

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+unsubscribe@chromium.org.
To post to this group, send email to ct-p...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/5ca42117-13ce-4cda-b3b1-408642ba102d%40chromium.org.

Alex

[Ryan Sleevi]

On Fri, Aug 11, 2017 at 4:24 PM, Alex Gaynor <aga...@mozilla.com> wrote:
> Revoked CA is a more interesting case.
>
> For trusted CAs, there's nothing to stop them from issuing new certificates
> en masse! The same expired certificate filter which prevents large volumes
> of certs from being used in perpetuity on logs would apply to revoked (and
> also expired) certs would it not?

Sure, but if they're unrevoked, then that's simply eating up their own
limits (since logs should ideally be rate-limiting based on root
CA-and-intermediate, rather than just overall). So that's an attack,
but one Logs today can mitigate without running afoul of requirements.
At the very end of the spectrum, the Log operator could (temporarily,
permanently?) remove a CA that continued to do that.

If they're revoked, however, there's no such recourse. The issuing CA
disclaimed responsibility, but now they're being penalized.