Aligning the [EV/]CT Plan with Chrome's Implementation

[Ryan Sleevi]

In the process of removing the Certly log as a trusted log, it was discovered that Chromium was not properly implementing the stated EV/CT Plan. Specifically, it was being more liberal and lax in enforcement from what was stated. This is explained in the following bug: https://bugs.chromium.org/p/chromium/issues/detail?id=605510

We are considering updating the EV/CT Plan to address the current state of the world, and to provide better clarity to both site administrators and CAs as to the expectations and valid configurations, and clarifying that this does not exclusively apply to EV certificates.

The proposed change is to actually update the plan to codify the current laxness, with a few fixes, and as such, should not negatively affect any site or user, while still accomplishing the same desired security goals.

NOTE: This is an in-progress discussion. Despite the current Chrome behaviour, it does not represent an intentional change in policy. Any CA or user which relies on the behaviour in the bug above is relying on a bug, and may break in the future. One way to fix this bug is to update the policy to match the behaviour, but another way is to align with the stated plan, and until this discussion is complete and a decision made, no guarantees will be made as to which direction this will go.

While we're still working on the best way to express this clearly and unambiguously in the policy, we wanted to propose the principles here and solicit feedback:

(Note, due to how indents are handled across mail readers, I've attempted to use line breaks to distinguish the EITHER/OR)

A certificate is CT Qualified if:

An SCT presented via the TLS extension OR embedded within a stapled OCSP response is from a log qualified at time of check.

AND

There is at least one SCT from a Google Log that is qualified at the time of check, presented via any method.

AND

There is at least one SCT from a non-Google Log that is qualified at the time of check, presented via any method.

OR:

There is at least one embedded SCT from a log qualified at the time of check.

AND

There is at least one embedded SCT from a Google Log once or currently qualified.

AND

There is at least one embedded SCT from a non-Google Log once or currently qualified.

AND

There are AT LEAST the number of embedded SCTs shown in Table 1 from logs once or currently qualified.

“Once or currently qualified” means the log was qualified or pending qualification at time of issuance, was accepted prior to the time of check, but might have been disqualified by the time of check.

“Embedded SCT” means an SCT included as an X.509v3 extension

So long as the above conditions are met, any additional SCTs that are present will not affect the status, negatively or positively.

Concretely, the following scenarios are considered to comply with the policy:

- 1 SCT from a non-Google Log, qualified at time of check, and delivered via TLS extension, and 1 SCT from a Google Log, qualified at time of check, and delivered via stapled OCSP response

- 1 SCT from a Google Log, qualified at time of check, and embedded within the certificate, and 1 SCT from a non-Google Log, qualified at time of check, and delivered via TLS extension

- 2 SCTs from Google logs, qualified at time of check, and embedded within the certificate, and 2 SCTs from non-Google Logs, once qualified but no longer qualified at the time of the TLS handshake, and embedded within the certificate

- 1 SCT from a non-Google log, qualified at time of check, and embedded within the certificate, and 2 SCTs from non-Google logs, once qualified but no longer qualified at the time of the TLS handshake, and embedded within the certificate, and 1 SCT from a Google log, qualified at time of check, and delivered via a stapled OCSP response

- 2 SCTs from, one from a Google log and one from a non-Google log, both qualified at time of check and delivered via TLS extension or OCSP response, and 2 SCTs from logs not recognized/unknown/with invalid signatures, delivered via any means

The following would not qualify

- 2 SCTs from a non-Google log qualified at time of check, delivered via TLS extension or OCSP

- 4 SCTs from a mix of Google and non-Google logs, once qualified but no longer qualified at time of check, delivered via any means

We think this policy best aligns with what is practical, efficient, and what Chromium has (effectively) been doing. Unless we've missed a serious concern, we're looking to update the policy and Chrome implementations within the week, so prompt attention is appreciated. Non-response will be taken as there being no conflicts, which we believe there shouldn't be any.

In addition to the above change, we'll be updating the plan to clarify that, while enforcement is limited to EV, the stated policies apply to all certificates that want to be "compliant" with Chromium's CT policy. This hopefully will remove some concerns CAs have raised about whether or not DV certificates will have alternative policies to be recognized within Chromium-based browsers; that hasn't been the case, nor is intended to be the case. Strictly speaking, our goal for DV is to make it less restrictive than present, but that will take time and more engineering before we accomplish that.

[Richard Salz]

I do think I understand the last paragraph.  Let me try to restate it and see if I got it right.

Chrome will continue to have one CT policy.  Enforcement is required for EV. Enforcement is not required for DV. Some kind of enforcement for DV is a goal, but we don't what it will be.

--
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/CACvaWvazkQF4WQ1McKK11xdgX0JZRJ0JUHpDLM21cP1q0U4aCg%40mail.gmail.com.

[Ryan Sleevi]

On Apr 26, 2016 7:06 AM, "Richard Salz" <rich...@gmail.com> wrote:
>
> I do think I understand the last paragraph.  Let me try to restate it and see if I got it right.
>
> Chrome will continue to have one CT policy.  Enforcement is required for EV. Enforcement is not required for DV. Some kind of enforcement for DV is a goal, but we don't what it will be.
>

Was that supposed to be "do" or "don't" in the first paragraph? And did you for a word between don't and what (perhaps "know")?

That's roughly correct, except that we do know want we want the policy to be, and our focus is on implementing aspects, such as SCT inclusion proof fetching and gossip on the client side, and improving monitoring and alerting for log operations (for CAs, monitors, and log operators needs) on the server, and seeing more robust and open logs in the ecosystem. So we are moving towards the goal, which might be simply summarized as "the same conceptual policy, but with less friction for all parties"

[Richard Salz]

When will you share the specifics of the DV policy?

[Ryan Sleevi]

On Tue, Apr 26, 2016 at 8:05 AM, Richard Salz <rich...@gmail.com> wrote:

When will you share the specifics of the DV policy?

As I've said numerous times, when we're ready to share the specifics of the DV policy.

I'm not trying to be snarky or glib; I've tried to be transparent with you in the thinking and the concerns, in explaining why we've not yet called something the "DV policy," and the steps we're taking to address these concerns as a precondition for doing so.

Alternatively, you could take it as "When the things I mentioned are in place, and are shown to be working"

I also tried to explain to you, but perhaps it wasn't clear, that conforming to the policy today is something we anticipate to be compatible with the DV policy of tomorrow; we're trying to make the DV policy _less_ restrictive compared to what "CT compliance" means today, and we have not yet identified any reason why it should be more strict than the policy as it stands. That said, because there are aspects still being deployed, we also can't guarantee that in a way that will be 100% correct - at best, 99.999% - because we don't know what "unknown-unknowns" exist.

[Richard Salz]

I did understand that the goal was to make DV less restrictive compared to EV. I did not understand that the things you listed were pre-reqs to determining and then announcing what the policy was. Thanks for the clarification (or explanation or however you want to characterize your, shall we call it, elucidation?).

[Ryan Sleevi]

On Tue, Apr 26, 2016 at 8:28 AM, Richard Salz <rich...@gmail.com> wrote:

I did understand that the goal was to make DV less restrictive compared to EV. I did not understand that the things you listed were pre-reqs to determining and then announcing what the policy was. Thanks for the clarification (or explanation or however you want to characterize your, shall we call it, elucidation?).

Perhaps I didn't respond to your question clearly; the "EV/CT Plan" is being renamed "CT Plan", because it covers DV.

That is, if you want a DV to be considered "CT compliant" in Chrome 52 (or, for that matter, any preceding version), you follow that document. We tried to make this abundantly clear when, even in the first versions, we included the policy for DV certs - that is, certs that were >= 39 months (something the CA/B Forum only disallowed in the past month).

CT Compliance is useful - for example, with Expect-CT. Any certificate that wishes to meet that "expect" part follows the plan.

The statements with prerequisites are with regards to announcing the 'mandatory' part of the plan - that is, the timing and execution. To that, we want the policy to be more permissive, and the ecosystem more robust (which itself is a necessary condition for permissiveness), and moving towards more of both, before setting forward a mandatory timeframe. However, we absolutely encourage every CA, and every site operator, to implement this plan for all certificates.

As mentioned throughout our discussions of policy changes, our goal is to make the policy more and more permissive over time. The restrictions - such as "log independence" in previous versions, and now the 1 Google/1 non-Google requirement - are purely there to bootstrap the ecosystem as it grows to a self-sustaining, self-supporting system, of robust Clients, Monitors, and Auditors.

As it happened in this incident, the Chromium code was already being more permissive, and in a way that had no negligible impact on security and ended up revealing some unnecessarily restrictive, unintended interpretations in the policy - which is what this thread is about correcting, with the hope that it makes it easier, and clearer, for everyone.

[Fabrice Gautier]

Do you have examples of scenarios that do not satisfy the currently
stated policy, but do satisfy the current actual policy or this new
proposed policy.

[Fabrice Gautier]

Also, does this remove the concept of "Log qualified at the time of
SCTs issuance" ? And just replace it by "Log that was once qualified"
?

Meaning that, for example, SCTs issued today by the Certly.io log
today would still count toward the total count of required SCTs,
whereas before, they would only have counted if they were issued
before the April 15th deadline ?

It might help understanding if there was a better term to describe the
two types of Logs. For example, you could describe the currently
qualified logs as "Active Logs" and the once qualified logs as
"Inactive Logs" or "Deactivated log"

I was also assuming that, at some point, the metadata associated to
logs list in both chromium code and the certificate-transparency.org
logs list would be include by either a "expiration date" or some kind
of "inactive" marker to distinguish both kind of log.

-- Fabrice

[Ryan Sleevi]

On Tue, Apr 26, 2016 at 1:09 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

Do you have examples of scenarios that do not satisfy the currently
stated policy, but do satisfy the current actual policy or this new
proposed policy.

Sure.

Sending an unrecognized SCT (e.g. from a log not known by the client) in a TLS extension or OCSP extension is, from  the current policy, not valid (because of the footnotes 1 and 2 indicating that because SCTs can be updated w/o modifying the certificate, they're expected to be qualifying). The code doesn't enforce this, however, nor would we want to, but that's one possible reading from the policy.

The particular thing that caused this bug to be noticed is that the diversity requirements were considering all SCTs presented; that is, it was not enforcing that, embedded within the certificate, there was at least one Google and one-non Google log. There were also issues with how it would have have handled disqualified logs that would have lead to it breaking from the policy (allowing disqualified logs' SCTs, delivered via TLS/OCSP, to be counted towards quorum for embedded certificates)

The bug covers more.

[Ryan Sleevi]

On Tue, Apr 26, 2016 at 1:24 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

Also, does this remove the concept of "Log qualified at the time of
SCTs issuance" ? And just replace it by "Log that was once qualified"
?

No. This is called "Once or currently qualified" - and the definition for what that means is provided.

 

Meaning that, for example, SCTs issued today by the Certly.io log
today would still count toward the total count of required SCTs,
whereas before, they would only have counted if they were issued
before the April 15th deadline ?

No, this doesn't change.

 

It might help understanding if there was a better term to describe the
two types of Logs. For example, you could describe the currently
qualified logs as "Active Logs" and the once qualified logs as
"Inactive Logs" or "Deactivated log"

Judging by the confusion, perhaps you missed the footnotes? Please let me know if, after re-reading the proposed changes, you still are confused.

 

I was also assuming that, at some point, the metadata associated to
logs list in both chromium code and the certificate-transparency.org
logs list would be include by either a "expiration date" or some kind
of "inactive" marker to distinguish both kind of log.

I can't speak for certificate-transparency.org, but yes, that is the plan for Chrome. The stated policy - Certly.io SCTs being rejected after April 15 - is still the plan of record. Just while implementing this check we discovered the policy impedance mismatch, discussed internally to try to put a path forward, and are now discussing publicly to see if we missed anything during our lengthy internal discussions. We presented the policy language in a very "code-friendly" form to make it clear what we mean, and what the code will say, while the exact language to update the policy will be tweaked to be more readable, assuming there's no disagreement or concerns about the principles. 

[Fabrice Gautier]

On Tue, Apr 26, 2016 at 2:01 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
>
> On Tue, Apr 26, 2016 at 1:09 PM, Fabrice Gautier <fabrice...@gmail.com>
> wrote:
>>
>> Do you have examples of scenarios that do not satisfy the currently
>> stated policy, but do satisfy the current actual policy or this new
>> proposed policy.
>
>
> Sure.
>
> Sending an unrecognized SCT (e.g. from a log not known by the client) in a
> TLS extension or OCSP extension is, from the current policy, not valid
> (because of the footnotes 1 and 2 indicating that because SCTs can be
> updated w/o modifying the certificate, they're expected to be qualifying).
> The code doesn't enforce this, however, nor would we want to, but that's one
> possible reading from the policy.

Ah, I never really read it that way. I always assumed that SCTs from
unknown logs were just ignored, wherever they are.

> The particular thing that caused this bug to be noticed is that the
> diversity requirements were considering all SCTs presented; that is, it was
> not enforcing that, embedded within the certificate, there was at least one
> Google and one-non Google log.

I guess I never read the policy document closely because I was also
assuming that the Google/Non-Google requirement was taking into
account all SCTs sources.

[Fabrice Gautier]

On Tue, Apr 26, 2016 at 2:04 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
>
> On Tue, Apr 26, 2016 at 1:24 PM, Fabrice Gautier <fabrice...@gmail.com>
> wrote:
>>
>> Also, does this remove the concept of "Log qualified at the time of
>> SCTs issuance" ? And just replace it by "Log that was once qualified"
>> ?
>
>
> No. This is called "Once or currently qualified" - and the definition for
> what that means is provided.
>
>>
>> Meaning that, for example, SCTs issued today by the Certly.io log
>> today would still count toward the total count of required SCTs,
>> whereas before, they would only have counted if they were issued
>> before the April 15th deadline ?
>
>
> No, this doesn't change.
>
>>
>>
>> It might help understanding if there was a better term to describe the
>> two types of Logs. For example, you could describe the currently
>> qualified logs as "Active Logs" and the once qualified logs as
>> "Inactive Logs" or "Deactivated log"
>
>
> Judging by the confusion, perhaps you missed the footnotes? Please let me
> know if, after re-reading the proposed changes, you still are confused.
>

Yes, I missed the definition of "once or currently qualified" and was confused.

The definition is:

<< “Once or currently qualified” means the log was qualified or
pending qualification at time of issuance, was accepted prior to the
time of check, but might have been disqualified by the time of check.
>>

Does "time of issuance" means the "NotValidBefore" time of the cert ?
It could also mean the "issuance time" of the SCT.

Also, does this language also means that Logs may have a "start date"
in addition to an "end date" ? With the start date indicating the
date where the Log status changed to "pending qualification" ? That
would for example disqualify SCTs that are added to a log before

I'm not sure what "accepted prior to the time of check" really means
here. I take it is a way to deal with Logs that were pending at some
point but never included in Chrome ?

[Ryan Sleevi]

On Tue, Apr 26, 2016 at 3:00 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

Does "time of issuance" means the "NotValidBefore" time of the cert ?
It could also mean the "issuance time" of the SCT.

In this case, neither ;)

There are a number of ways to do this, but since the act of logging a pre-certificate (in any log) is effectively the act of issuing a certificate (per RFC 6962), programatically we've defined issuance as "The earliest SCT from a Log that is Qualified at time of check, from any source".

This prevents, for example, creating a certificate with a notBefore 1 month in the past, logging to a disqualified log (and has its SCT set after its disqualification date), and expecting it to be accepted.

This also prevents, for example, a malicious log backdating its timestamp after it has been disqualified. That is, you have 1 disqualified log, setting its SCT at T=0. It was disqualified at T=5. You have 3 other SCTs, still qualified at time of check, all set at T=10. If you trust the disqualified logs' SCT, you would be led to believe this meets quorum - even though it does not, because the log was not qualified at time of issuance (it had been disqualified).

So long as there is at least one valid SCT, this system works. And if there's no valid SCT, well, then you're doomed anyways, because you're required to have at least one valid SCT.

 

Also, does this language also means that Logs may have a "start date"
in addition to an "end date" ?  With the start date indicating the
date where the Log status changed to "pending qualification" ? That
would for example disqualify SCTs that are added to a log before

Effectively, yes, although we're considering addressing that via policy in requiring that applications begin with 'an empty log'. Many of these concerns were discussed in the context of how reapplications look like. That's one possible approach, another is the start date, but yes, one can imagine several ways to address this.

If you believe this ambiguity disincentivizes using pending logs (because of uncertainty about whether and when they're officially pending) until they've been accepted, well, yes, that is in some ways the intent. The ambiguity serves to both offer flexibility as we work through the issues, but also highlight that until a log has been accepted, there's caveats and one should not necessarily rely on them in order to meet the policy obligations. That is, it might make sense to embed 5 SCTs - 4 qualified + 1 pending - rather than 3 qualified + 1 pending, in the hope that the pending will become qualified in time to meet the policy obligations.

 

I'm not sure what "accepted prior to the time of check" really means
here. I take it is a way to deal with Logs that were pending at some
point but never included in Chrome ?

Correct. We've also had logs that were pending qualification but, during the qualification period, failed to meet the requirements. I believe three times now? I've lost track.

[Fabrice Gautier]

The policy does not seem to explicitly address what happen with duplicate SCTs, or when different SCTs from the same logs are encountered. 

The older policy had the "log independence" requirements that would make sure duplicate SCTs, or SCTs from the same log would only count once against the quorums. 

What is current Chrome behavior in that regard ?

-- Fabrice

[Ryan Sleevi]

On Tue, Apr 26, 2016 at 4:32 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

The policy does not seem to explicitly address what happen with duplicate SCTs, or when different SCTs from the same logs are encountered. 

"So long as the above conditions are met, any additional SCTs that are present will not affect the status, negatively or positively."

 

The older policy had the "log independence" requirements that would make sure duplicate SCTs, or SCTs from the same log would only count once against the quorums. 

What is current Chrome behavior in that regard ?

[Fabrice Gautier]

Still, put my question in the context of this condition:

"There are AT LEAST the number of embedded SCTs shown in Table 1 from logs once or currently qualified."

If I embed 3 copies of the same SCTs in the cert, does it satisfies this condition? (I would think not)

If I embed 3 different SCTs from the same log in the cert, would it satisfies this condition? (Assuming that logs would return different SCTs for the same certs...) 

[Ryan Sleevi]

On Tue, Apr 26, 2016 at 5:22 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

Still, put my question in the context of this condition:

"There are AT LEAST the number of embedded SCTs shown in Table 1 from logs once or currently qualified."

If I embed 3 copies of the same SCTs in the cert, does it satisfies this condition? (I would think not)

No

 

If I embed 3 different SCTs from the same log in the cert, would it satisfies this condition? (Assuming that logs would return different SCTs for the same certs...)  

Ah, thank you for clarifying. It was never the intent to allow this, but it appears you've spotted another bug in the present implementation that should be fixed this week as well =) I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=607023 to track this

Is there language you might suggest on how to resolve this ambiguity, since you spotted it :)

[Fabrice Gautier]

Talk about number of logs rather than number of SCTs.

Eg: rephrase the above condition as:

"The certificate embed SCTs from AT LEAST the number logs once or currently qualified shown in Table 1."

Hum... Doesn't sound great... But something like that...

-- Fabrice

[Fabrice Gautier]

Turning this first part of the policy over and over around my head,
I'm not sure I understand the rationale for weakening the 2 SCTs from
currently valid logs.

It seems that there are two cases:

- Either you get a CA that provide a cert with embedded SCTs that it
copies policy, so you don't need to worry about the OCSP or TLS
extensions delivery mechanism,
- Or you don't have such cert (eg: you use "lets encrypt"), in which
case you need to worry about the TLS extension or OCSP delivery.

It seems that there will be not much point in people needing the
"hybrid" form that would now be allowed where you have 1 external and
1 embedded SCTs from currently valid logs.

Is that just a byproduct of the current implementation, or is there a
scenario that Chromium wanted to support ?

[Ryan Sleevi]

On Thu, Apr 28, 2016 at 12:40 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

Turning this first part of the policy over and over around my head,

I'm not sure I understand the rationale for weakening the 2 SCTs from
currently valid logs.

Wait, perhaps there's a misunderstanding. I'm not sure why you suggest it's a weakening?

 

It seems that there will be not much point in people needing the
"hybrid" form that would now be allowed where you have 1 external and
1 embedded SCTs from currently valid logs.

Is that just a byproduct of the current implementation, or is there a
scenario that Chromium wanted to support ?

It addresses several cases. Say you have a CA which improperly followed policy - and, unfortunately, there have been a number. For example, they only embedded Google SCTs. One option is for the CA to re-issue that certificate, but that may carry with it additional obligations/constraints (such as revalidation in the case of EV). Another is that the server operator might simply enable OCSP Stapling or the TLS extension to 'fix' the mistake. In such a world, it seems highly inefficient and wasteful to require that they deliver an SCT from the same log via the TLS handshake that is also delivered within the certificate.

We can think of no security risk by allowing 'pooling' of embedded SCTs with those delivered via TLS or OCSP. Nor can we identify any security or operational benefit from prohibiting 1 SCT via OCSP and 1 SCT via TLS, given that the same operational risks and concerns apply if you're delivering 2 SCTs via OCSP or 2 SCTs via TLS. So it was an intentional decision not to prohibit what is, in essence, an optimization strategy for when things get weird.

This is especially important to consider if the set of logs changes over time, or as more (non-Chromium) clients implement support for CT, and may recognize different logs - such as not including uptime requirements, or having a different view of the uptime requirement. By recognizing that there's no advantage to sending SCTs from the same log over multiple means, we're hopefully simplifying the operational deployment. 

[Fabrice Gautier]

On Thursday, April 28, 2016 at 1:36:12 PM UTC-7, Ryan Sleevi wrote:

On Thu, Apr 28, 2016 at 12:40 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

Turning this first part of the policy over and over around my head,

I'm not sure I understand the rationale for weakening the 2 SCTs from
currently valid logs.

Wait, perhaps there's a misunderstanding. I'm not sure why you suggest it's a weakening?

Not really a weakening in the security sense, I just mean that it's less restrictive. In particular, this scenario was not allowed before:

- 1 SCT from a Google Log, qualified at time of check, and embedded within the certificate, and 1 SCT from a non-Google Log, qualified at time of check, and delivered via TLS extension

 

It seems that there will be not much point in people needing the

"hybrid" form that would now be allowed where you have 1 external and
1 embedded SCTs from currently valid logs.

Is that just a byproduct of the current implementation, or is there a
scenario that Chromium wanted to support ?

It addresses several cases. Say you have a CA which improperly followed policy - and, unfortunately, there have been a number. For example, they only embedded Google SCTs. One option is for the CA to re-issue that certificate, but that may carry with it additional obligations/constraints (such as revalidation in the case of EV). Another is that the server operator might simply enable OCSP Stapling or the TLS extension to 'fix' the mistake. In such a world, it seems highly inefficient and wasteful to require that they deliver an SCT from the same log via the TLS handshake that is also delivered within the certificate.

We can think of no security risk by allowing 'pooling' of embedded SCTs with those delivered via TLS or OCSP. Nor can we identify any security or operational benefit from prohibiting 1 SCT via OCSP and 1 SCT via TLS, given that the same operational risks and concerns apply if you're delivering 2 SCTs via OCSP or 2 SCTs via TLS. So it was an intentional decision not to prohibit what is, in essence, an optimization strategy for when things get weird.

This is especially important to consider if the set of logs changes over time, or as more (non-Chromium) clients implement support for CT, and may recognize different logs - such as not including uptime requirements, or having a different view of the uptime requirement. By recognizing that there's no advantage to sending SCTs from the same log over multiple means, we're hopefully simplifying the operational deployment. 

Those are fair enough points.

[Fabrice Gautier]

Here is an interesting scenario: 

I have a certificate with 1 embedded SCT from a currently qualified Google Log, and 1 embedded SCT  from a currently qualified non Google Log.

As is, you don't satisfy the requirements (for a 24 month cert). But if I resend an SCT from one of those two logs in an extension, then I'm compliant. 

In that case you are sending the SCTs from the same log over multiple means.

But I understand that here re-sending the SCT from the same log  indicate to Chrome that this server has the ability to dynamically update its SCTs list, so that it's not necessary to require more than 2 SCTs.

[Ryan Sleevi]

On Thu, Apr 28, 2016 at 2:22 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

Here is an interesting scenario: 

I have a certificate with 1 embedded SCT from a currently qualified Google Log, and 1 embedded SCT  from a currently qualified non Google Log.

As is, you don't satisfy the requirements (for a 24 month cert). But if I resend an SCT from one of those two logs in an extension, then I'm compliant. 

Not the same SCTs (SCTs for precerts differ from SCTs for certificates, with respect to the digitally-signed struct within the SignedCertificateTimestamp, as explained in Section 3.2. of 6962)

If you just copied the data from the extension, it wouldn't work. That's because only SCTs for ASN.1Certs are validated when delivered via OCSP or TLS.

So you're sending different things, because you *logged* different things. So you have two (different types) of SCTs from the same log, and you can't argue that it's duplicate data, because they're distinct.

 

In that case you are sending the SCTs from the same log over multiple means.

But I understand that here re-sending the SCT from the same log  indicate to Chrome that this server has the ability to dynamically update its SCTs list, so that it's not necessary to require more than 2 SCTs.

Correct. 

[Peter Bowen]

On Thu, Apr 28, 2016 at 2:28 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
>
> On Thu, Apr 28, 2016 at 2:22 PM, Fabrice Gautier <fabrice...@gmail.com>
> wrote:
>>
>> Here is an interesting scenario:
>>
>> I have a certificate with 1 embedded SCT from a currently qualified Google
>> Log, and 1 embedded SCT from a currently qualified non Google Log.
>> As is, you don't satisfy the requirements (for a 24 month cert). But if I
>> resend an SCT from one of those two logs in an extension, then I'm
>> compliant.
>
>
> Not the same SCTs (SCTs for precerts differ from SCTs for certificates, with
> respect to the digitally-signed struct within the
> SignedCertificateTimestamp, as explained in Section 3.2. of 6962)
>
> If you just copied the data from the extension, it wouldn't work. That's
> because only SCTs for ASN.1Certs are validated when delivered via OCSP or
> TLS.

Is that covered in 6962 or is that a Chromium implementation detail?

Thanks,
Peter

[Ryan Sleevi]

On Thu, Apr 28, 2016 at 2:31 PM, Peter Bowen <pzb...@gmail.com> wrote:

Is that covered in 6962 or is that a Chromium implementation detail?

See https://tools.ietf.org/wg/trans/trac/ticket/10

'"entry_type" may be implicit from the context in which the SCT is presented'

Since a validating client has to recreate everything within the digitally-signed struct in order to evaluate the signature, it would argue for the current behaviour. Anyways, 6962-bis makes this clearer.

[Fabrice Gautier]

Here is another example:

I have a 24 month certificate embedding 3 SCTs, 2 from previously qualified non-Google logs, and 1 from  a previously qualified Google log. I also send 1 SCT from a currently qualified Google Log.

I believe this was valid under the previously stated policy, but not under the one just proposed.

[Ryan Sleevi]

On Thu, Apr 28, 2016 at 10:19 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

Here is another example:

I have a 24 month certificate embedding 3 SCTs, 2 from previously qualified non-Google logs, and 1 from  a previously qualified Google log. I also send 1 SCT from a currently qualified Google Log. 

I believe this was valid under the previously stated policy, but not under the one just proposed.

It was incidentally, not intentionally, valid under the previous policy, but not actually valid in the implementation. That's part of what sparked the discovery of the root bug - in implementation and policy. So there's no material change to any effect on CAs.