[ct-policy] Issue 6: Certificate Transparency Log Certificate Acceptance Proposal

[Kat Joyce]

At the CT Policy Days (and at various other times) members of the CT community expressed concern at growing Log sizes, and the uncertainty of log lifecycle management.

Having given some thought to this recently, we have come up with a proposal that might help a bit.  We wanted to present this idea to the community to get feedback, see what people think, see if there are any problems with the idea that we haven't thought of etc.  This idea is something we, the Google CT team, are considering for the 8 new Logs that we keep mentioning may be coming sometime soon.

So here it is:

----------------------------------------------------------------------------------------------------------------------------------

Certificate Transparency Log Certificate Acceptance Proposal

Problems:

• Log Size:  Currently, bringing up new logs does not help with size issues, as if the new logs have the same root set at the old logs, they could be filled with all of the same certificates, resulting in a duplicate logs, and not solving the problem of log size in any way.
  
• Log lifetime management:  Logs are getting filled with short lived certs (ahem, Let’s Encrypt :P) but then having to be kept alive for years after most of the certificates they contain expire due to the small number of long lived certs in them.
  

Idea:

When a log operator brings up a new Log, they specify:

• A list of accepted roots (as usual)
  

• (optionally) A time range: Start, End

For a certificate to be accepted by the Log:

• The certificate must be ‘valid’ X509 (as usual)

• The certificate must chain to an accepted roots (as usual)

• If a time range was specified:

• The certificate’s ‘Not After’ validity field value must:

• Be at or after ‘Start’

• Be before ‘End’

How could Log Operators use this:

Suppose the longest lived cert that a CA can/will ever issue is 3 years (I'm not sure what it actually is, so this example would need to be adjusted to accommodate whatever it really is).

Using this new idea, a log operator could then create 4 logs (to cover a rolling 3 year period), each with the same set of accepted roots, but with (Start, End) values of:

• (initial, initial+1yr)

• (initial+1yr, initial+2yrs)

• (initial+2yrs, initial+3yrs)

• (initial+3yrs, initial+4yrs)

where initial = ~when the logs are created

New certificates issued with short lifetimes (for example Let’s Encrypt certs) would initially end up in the (initial, initial+1yr) log, whereas new certificates with longer lifetimes would end up in the logs with later acceptance ranges.  Existing certificates that have not yet expired would fit into whichever log accepts their ‘Not After’ value, and expired certificates would be submitted to already existing archival logs (e.g. Google Daedalus).

As *now* progressed, and neared initial+1yr, another log would be spun up with (Start, End) = (initial+4yrs, initial+5yrs), to continue to cover any new certificates created with a 3 year lifetime. New short lived certificates would start being logged in the (initial+1yr, initial+2yrs) Log.

Once *now* passed initial+1yr, the log with (Start, End) = (initial, initial+1yr) would become archival, and not require the same level of maintenance, as all of the certificates within it would be expired.

Pros:

• Hard date at which the log is no longer active - very clear log lifetime.

• Logs sizes are limited to however many certs expire during the specified range.

• Adds an element of predictability to when certain new Logs will be introduced. Can plan spinning up Logs in advance.

Cons:

• Adds complexity to the ecosystem:

• CAs either have to know which Log to submit to/which log will accept the expiry dates of its certs, or submit to all Logs with the understanding that only some will return an SCT.

• CAs have to change which Logs they submit to as time rolls on.

• Shipping with a ‘baked in’ list of Logs that all specify the optional Start, End values means that, after the latest End value, and without any update mechanism. CT will no longer work for that product.

----------------------------------------------------------------------------------------------------------------------------------

There are probably other pros and cons, so feel free to add to the ones mentioned above.

If anyone has questions about details of this idea that aren't made clear here, please do feel free to ask for clarification!

Let us know what you think!

[Kat Joyce]

Link to the Github issue (that I forgot to include):  https://github.com/GoogleChrome/ct-policy/issues/6

[Kat Joyce]

So it's all been very quiet on this suggestion.... no one out there has *any* thoughts or questions?

If there are no objections or discussion points we may just go ahead with this idea for some of our new Logs...

[Ryan Sleevi]

I think many people involved with CT, particularly around the browser side, have been a bit preoccupied as of late with non-CT events :)

I think an important part of the Con is trying to work through what the implications of this proposal mean for the various participants. Obviously, log operators have a lot more flexibility, and I think this is a really appealing prospect for appropriately figuring out log growth and deprecation, which is good.

However, as you note, the Con is it introduces complexity - not just for CAs (which there's a natural bias to, given both precerts and OCSP affects them), but also site operators (using the TLS extension). Have you given thought as to how that information is communicated?

From a policy perspective, and I've expressed as much in private conversations with log operators, I think this would be less than ideal unless it was also accompanied by the requirement of a log accepting all certificates. That's something that's going to require a bit more active outreach to log operators to discuss, but I think that discussion affects what the bounds are for the acceptable validity periods in that range are. That is, is there a minimum? Is there a maximum?

Here's an example of what I think is unreasonable for a log operator:

(initial, initial + 1 day)

(initial + 1 day, initial + 2 day)

Hopefully obviously, rotating logs every day is not ideal. Similarly, if we couple with an 'accept from all CAs', then probably some value of '5 years' is also unreasonable. So what's the acceptable bound? Hopefully policy can guide us here. The policy on acceptability is somewhat bounded by the set of certificates accepted (which affect growth rate) and the risk, right?

To be clear, despite these concerns, I'm supportive of this as a general idea, and think it's good to get broader feedback on this =) Hopefully some gentle nudging of log operators re: https://github.com/GoogleChrome/ct-policy/issues/3 will shake this out a bit more :)

--
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/CAO%2BqTAm7ZwqcYbdt--ZKKak2xdX_2oqBnW3a%2BLb_DP3o4i54YQ%40mail.gmail.com.

[Andrew Ayer]

Hi Kat,

I think this is a good idea.

My main concern is ensuring that there are still logs in which
intermediate certificates can be logged. Although TLS end-entity
certificates are converging on shorter and shorter lifetimes,
intermediate certificates are often valid for 10 or more years.
Therefore, policy should permit (and possibly require) log operators to
also operate logs that accept only CA:TRUE certificates, without any
limits on validity period.

A side note: you mention that products with baked-in log lists may
stop working under this proposal. I would like to point out that this
is true even without this proposal, since logs can be distrusted for
violating policy. Frequent log rotation makes it very clear that baking
in log lists is a terrible idea, so I think this is a pro not a con :-)

Regards,
Andrew

On Tue, 16 May 2017 14:33:42 +0100

"'Kat Joyce' via Certificate Transparency Policy"
<ct-p...@chromium.org> wrote:

> So it's all been very quiet on this suggestion.... no one out there
> has *any* thoughts or questions?
>
> If there are no objections or discussion points we may just go ahead
> with this idea for some of our new Logs...
>
> On Sat, Apr 29, 2017 at 12:28 AM, Kat Joyce <katj...@google.com>
> wrote:
>
> > Link to the Github issue (that I forgot to include):
> > https://github.com/ GoogleChrome/ct-policy/issues/6
> >
> > On Sat, Apr 29, 2017 at 12:28 AM, Kat Joyce <katj...@google.com>
> > wrote:
> >
> >> At the CT Policy Days (and at various other times) members of the
> >> CT community expressed concern at growing Log sizes, and the
> >> uncertainty of log lifecycle management.
> >>
> >> Having given some thought to this recently, we have come up with a
> >> proposal that might help a bit. We wanted to present this idea to
> >> the community to get feedback, see what people think, see if there
> >> are any problems with the idea that we haven't thought of etc.
> >> This idea is something we, the Google CT team, are considering for
> >> the 8 new Logs that we keep mentioning may be coming sometime soon.
> >>
> >> So here it is:
> >>
> >> ------------------------------------------------------------
> >> ----------------------------------------------------------------------
> >>

> >> *Certificate Transparency Log Certificate Acceptance Proposal*
> >>
> >> *Problems:*
> >>
> >> - *Log Size*: Currently, bringing up new logs does not help

> >> with size issues, as if the new logs have the same root set at the
> >> old logs, they could be filled with all of the same certificates,
> >> resulting in a duplicate logs, and not solving the problem of log
> >> size in any way.

> >> - *Log lifetime management*: Logs are getting filled with short
> >> lived certs (ahem, Let___s Encrypt :P) but then having to be kept

> >> alive for years after most of the certificates they contain expire
> >> due to the small number of long lived certs in them.
> >>

> >> *Idea:*

> >>
> >> When a log operator brings up a new Log, they specify:
> >>
> >>
> >>

> >> - A list of accepted roots (as usual)
> >> -

> >>
> >> (optionally) A time range: Start, End
> >>
> >>
> >> For a certificate to be accepted by the Log:
> >>
> >>

> >> -
> >>
> >> The certificate must be ___valid___ X509 (as usual)
> >>
> >>
> >> -

> >>
> >> The certificate must chain to an accepted roots (as usual)

> >> -

> >>
> >> If a time range was specified:

> >> -
> >>
> >> The certificate___s ___Not After___ validity field value must:
> >> -
> >>
> >> Be at or after ___Start___
> >> - Be before ___End___
> >>
> >>
> >> *How could Log Operators use this:*

> >>
> >> Suppose the longest lived cert that a CA can/will ever issue is 3
> >> years (I'm not sure what it actually is, so this example would
> >> need to be adjusted to accommodate whatever it really is).
> >>
> >>
> >> Using this new idea, a log operator could then create 4 logs (to
> >> cover a rolling 3 year period), each with the same set of accepted
> >> roots, but with (Start, End) values of:
> >>

> >> -
> >>
> >> (initial, initial+1yr)
> >> -
> >>
> >> (initial+1yr, initial+2yrs)
> >> -
> >>
> >> (initial+2yrs, initial+3yrs)
> >> -

> >>
> >> (initial+3yrs, initial+4yrs)
> >>
> >> where initial = ~when the logs are created
> >>

> >> New certificates issued with short lifetimes (for example Let___s

> >> Encrypt certs) would initially end up in the (initial, initial
> >> +1yr) log, whereas new certificates with longer lifetimes would
> >> end up in the logs with later acceptance ranges. Existing
> >> certificates that have not yet expired would fit into whichever

> >> log accepts their ___Not After___ value, and expired certificates

> >> would be submitted to already existing archival logs (e.g. Google
> >> Daedalus).
> >>
> >> As *now* progressed, and neared initial+1yr, another log would be
> >> spun up with (Start, End) = (initial+4yrs, initial+5yrs), to
> >> continue to cover any new certificates created with a 3 year
> >> lifetime. New short lived certificates would start being logged in
> >> the (initial+1yr, initial+2yrs) Log.
> >>
> >>
> >> Once *now* passed initial+1yr, the log with (Start, End) =
> >> (initial, initial+1yr) would become archival, and not require the
> >> same level of maintenance, as all of the certificates within it
> >> would be expired.
> >>
> >>

> >> *Pros:*
> >>
> >>
> >>
> >> -

> >>
> >> Hard date at which the log is no longer active - very clear log
> >> lifetime.

> >> -

> >>
> >> Logs sizes are limited to however many certs expire during the
> >> specified range.

> >> -

> >>
> >> Adds an element of predictability to when certain new Logs will
> >> be introduced. Can plan spinning up Logs in advance.
> >>
> >>

> >> *Cons:*
> >>
> >>
> >> -

> >>
> >> Adds complexity to the ecosystem:

> >> -

> >>
> >> CAs either have to know which Log to submit to/which log will
> >> accept the expiry dates of its certs, or submit to all Logs
> >> with the understanding that only some will return an SCT.

> >> -

> >>
> >> CAs have to change which Logs they submit to as time rolls

> >> on. -
> >>
> >> Shipping with a ___baked in___ list of Logs that all specify the

> >> optional Start, End values means that, after the latest End value,
> >> and without any update mechanism. CT will no longer work for that
> >> product.
> >>
> >>
> >> ------------------------------------------------------------
> >> ----------------------------------------------------------------------
> >>
> >> There are probably other pros and cons, so feel free to add to the
> >> ones mentioned above.
> >>
> >> If anyone has questions about details of this idea that aren't
> >> made clear here, please do feel free to ask for clarification!
> >>
> >> Let us know what you think!
> >>
> >
> >
>

> --
> 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

[Kat Joyce]

On Tue, May 16, 2017 at 4:52 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

I think many people involved with CT, particularly around the browser side, have been a bit preoccupied as of late with non-CT events :)

I think an important part of the Con is trying to work through what the implications of this proposal mean for the various participants. Obviously, log operators have a lot more flexibility, and I think this is a really appealing prospect for appropriately figuring out log growth and deprecation, which is good.

However, as you note, the Con is it introduces complexity - not just for CAs (which there's a natural bias to, given both precerts and OCSP affects them), but also site operators (using the TLS extension). Have you given thought as to how that information is communicated?

If a Log Operator chooses to set an expiration acceptance period on a new Log, then when that Log is announced it would have to state its values for Start and End on the Chromium bug, in addition to all of the information it is currently required to provide.  This information could then easily be presented along with the metadata for the Log in any existing or future log lists.  I assume (please correct me if I'm wrong) that both CAs and site operators currently have to go and look up which Logs to use for their certificates (to check that such Logs accept the root their certificate chains to, for example), so this would just form part of that check.

If we were to have some requirement that anyone who uses this scheme has to run a set of Logs such that the expiry date for any newly issued certificate (that can be used right away) must be able to make it into one of their Logs, then CAs and site operators could just submit their certificate to every Log in the set, with the understanding that only one will return an SCT, and just use the SCT that is returned.  This would remove the need for CAs/site operators to do expiry date checks.  I haven't properly thought through whether having such a requirement for sets of Logs using this scheme is reasonable or not though, so please do offer opinions!

 

From a policy perspective, and I've expressed as much in private conversations with log operators, I think this would be less than ideal unless it was also accompanied by the requirement of a log accepting all certificates. That's something that's going to require a bit more active outreach to log operators to discuss, but I think that discussion affects what the bounds are for the acceptable validity periods in that range are. That is, is there a minimum? Is there a maximum? 

Here's an example of what I think is unreasonable for a log operator:

(initial, initial + 1 day)

(initial + 1 day, initial + 2 day)

Hopefully obviously, rotating logs every day is not ideal. Similarly, if we couple with an 'accept from all CAs', then probably some value of '5 years' is also unreasonable. So what's the acceptable bound? Hopefully policy can guide us here. The policy on acceptability is somewhat bounded by the set of certificates accepted (which affect growth rate) and the risk, right?

Yes, I agree, a minimum period of time for (End - Start) is needed.  I would probably suggest a minimum of 6 months or a year, at least to begin with.  If certificates become considerably more short-lived in the future, then this minimum can always be altered to reflect that.

I'm not sure about the need for a maximum.  As setting up a Log with these bounds is optional, choosing not to set the bounds at all (in the way that Logs are currently run) is similar to having an infinite bound.  If a Log chooses to have a longer period, that's their choice.  That being said, we could offer advice on what we think good choices could be, but perhaps it should be just advice rather than a hard maximum.

You might be right about having some requirement on which root certs a Log must accept in order for a Log to be allowed to specify an expiration acceptance period.  It's a tricky one though.  From our team's perspective, the majority of certificates that are coming into our open Logs are Let's Encrypt certs.  Certificates from other roots make up only a tiny proportion of the total certificates.  This can be seen by comparing Log sizes for Icarus (currenlty ~63M certs) and Skydiver (currently ~2M certs).  From the pov of this idea helping to restrict Log size, any Log not accepting Let's Encrypt roots shouldn't really need to manage their Log size.  That being said, such Logs may still want to use this idea for Log lifetime management.  But in that case, perhaps the minimum expiration acceptance period for Logs that don't accept all roots should be longer (O(years) rather than O(months)?).

All of that being said, part of the reason our team did the Icarus/Skydiver split, was so that if a Log accepting Let's Encrypt certs failed due to not being able to handle the quantity of Let's Encrypt certificates it was receiving, certificates issued by other CAs would not be affected (as their Log would still be up and running).  Being able to do splits like these for similar reasons, while also implementing expiry acceptance periods on the Logs could be useful...

[Kat Joyce]

On Tue, May 16, 2017 at 5:50 PM, Andrew Ayer <ag...@andrewayer.name> wrote:

Hi Kat,

I think this is a good idea.

My main concern is ensuring that there are still logs in which
intermediate certificates can be logged. Although TLS end-entity
certificates are converging on shorter and shorter lifetimes,
intermediate certificates are often valid for 10 or more years.
Therefore, policy should permit (and possibly require) log operators to
also operate logs that accept only CA:TRUE certificates, without any
limits on validity period.

Right, this is a good point.  I don't actually know that much about the range of certificate lifetimes that exist, and would love to be enlightened!  For example, in the example description of how this idea could be used, the maximum lifetime of a certificate I used was 3 years, and that's why 4 Logs, each with an expiration acceptance period of a year, would be needed to cover all certificates.  But  I am aware that 3 years was just a value I picked for the example, and may not be accurate.

Your idea of requiring an additional Log for intermediates sounds like it could work (assuming a CA:TRUE requirement for accepting submissions would be allowed).  But to check that that is all that is needed, and there aren't other certificates that should be logged that would still be excluded even after adding this, we really need to know:  What are the typical and maximum lifetimes of the different types of certificates that are out there?

 

A side note: you mention that products with baked-in log lists may
stop working under this proposal.  I would like to point out that this
is true even without this proposal, since logs can be distrusted for
violating policy.  Frequent log rotation makes it very clear that baking
in log lists is a terrible idea, so I think this is a pro not a con :-)

I actually agree that baking in log lists is a terrible idea, and that anything supporting CT should understand that the ecosystem is malleable, and have mechanisms in place for updating log lists whenever new Logs are turned up, disqualified, distrusted, turned down etc :)

 

> ct-policy+unsubscribe@chromium.org. To post to this group, send email

[Ryan Sleevi]

On Thu, May 25, 2017 at 7:00 AM, 'Kat Joyce' via Certificate Transparency Policy <ct-p...@chromium.org> wrote:

If a Log Operator chooses to set an expiration acceptance period on a new Log, then when that Log is announced it would have to state its values for Start and End on the Chromium bug, in addition to all of the information it is currently required to provide.  This information could then easily be presented along with the metadata for the Log in any existing or future log lists.  I assume (please correct me if I'm wrong) that both CAs and site operators currently have to go and look up which Logs to use for their certificates (to check that such Logs accept the root their certificate chains to, for example), so this would just form part of that check.

Today, it's a matter of the accepted root certificates (which itself is moderately complex to efficiently check, but we're ignoring that), and that's provided by the API endpoint.

In this future world, it's a piece of metadata not exposed by the log itself, and so sites and CAs would need to ingest this supplementary data.

 

If we were to have some requirement that anyone who uses this scheme has to run a set of Logs such that the expiry date for any newly issued certificate (that can be used right away) must be able to make it into one of their Logs, then CAs and site operators could just submit their certificate to every Log in the set, with the understanding that only one will return an SCT, and just use the SCT that is returned.  This would remove the need for CAs/site operators to do expiry date checks.  I haven't properly thought through whether having such a requirement for sets of Logs using this scheme is reasonable or not though, so please do offer opinions!

That seems like it would mean 4x the load on logs, using your example, since any given certificate would be sent to 4 different endpoints to see which would take it.

This increases the load on CAs/submitters, but more substantially, increases the load on sites.

You either end up with a scheme where:

a) You try to grab the notBefore/notAfter out of the certificate prior to signature validating

b) You validate the signature (chain), and then grab the notBefore/notAfter

Both are with tradeoffs - confusion/untrusted data in a), additional load in b), so I'm curious how you plan to reconcile?

 

Yes, I agree, a minimum period of time for (End - Start) is needed.  I would probably suggest a minimum of 6 months or a year, at least to begin with.  If certificates become considerably more short-lived in the future, then this minimum can always be altered to reflect that.

What would be the reasoning/criteria for changing that minimum?

 

I'm not sure about the need for a maximum.  As setting up a Log with these bounds is optional, choosing not to set the bounds at all (in the way that Logs are currently run) is similar to having an infinite bound.  If a Log chooses to have a longer period, that's their choice.  That being said, we could offer advice on what we think good choices could be, but perhaps it should be just advice rather than a hard maximum.

Well, if the argument is that it's good for the ecosystem - clients rotating logs, logs having fixed lifetimes, surely from an ecosystem perspective, setting a maximum of 'beyond this is bad practice' is good :)

 

You might be right about having some requirement on which root certs a Log must accept in order for a Log to be allowed to specify an expiration acceptance period.  It's a tricky one though.  From our team's perspective, the majority of certificates that are coming into our open Logs are Let's Encrypt certs.  Certificates from other roots make up only a tiny proportion of the total certificates.  This can be seen by comparing Log sizes for Icarus (currenlty ~63M certs) and Skydiver (currently ~2M certs).  From the pov of this idea helping to restrict Log size, any Log not accepting Let's Encrypt roots shouldn't really need to manage their Log size.  That being said, such Logs may still want to use this idea for Log lifetime management.  But in that case, perhaps the minimum expiration acceptance period for Logs that don't accept all roots should be longer (O(years) rather than O(months)?).

I don't think we want such logs, so that naturally suggests that all logs would need to use this idea, right? :)

 

All of that being said, part of the reason our team did the Icarus/Skydiver split, was so that if a Log accepting Let's Encrypt certs failed due to not being able to handle the quantity of Let's Encrypt certificates it was receiving, certificates issued by other CAs would not be affected (as their Log would still be up and running).  Being able to do splits like these for similar reasons, while also implementing expiry acceptance periods on the Logs could be useful...

I'm not convinced that splitting accepted roots is good for the ecosystem. Surely by relating to validity period, we still achieve the reasonable balance - since, after all, the risk of N logs failing (and that are critical) is not equivalent to the risk of a single log failing. 

[Kat Joyce]

On Thu, May 25, 2017 at 3:35 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, May 25, 2017 at 7:00 AM, 'Kat Joyce' via Certificate Transparency Policy <ct-p...@chromium.org> wrote:

If a Log Operator chooses to set an expiration acceptance period on a new Log, then when that Log is announced it would have to state its values for Start and End on the Chromium bug, in addition to all of the information it is currently required to provide.  This information could then easily be presented along with the metadata for the Log in any existing or future log lists.  I assume (please correct me if I'm wrong) that both CAs and site operators currently have to go and look up which Logs to use for their certificates (to check that such Logs accept the root their certificate chains to, for example), so this would just form part of that check.

Today, it's a matter of the accepted root certificates (which itself is moderately complex to efficiently check, but we're ignoring that), and that's provided by the API endpoint.

In this future world, it's a piece of metadata not exposed by the log itself, and so sites and CAs would need to ingest this supplementary data.

This is interesting, and has sparked a discussion of the exact steps that would have to be taken for someone to submit to a log :)

So, today, if you were a CA or a site owner and you had a (pre-)certificate that you wanted to submit to a CT Log, first, you'd need to find out the URLs for logs in existence, so you knew where to send the certificate (could you not also retrieve the expiration acceptance period metadata during this step?).  If all you knew about the Logs that exist at this point is their URLs, you could then do get-roots calls on all the Logs to find out which roots they accept, and to work out which Logs will accept your certificate.  You would then submit your certificate to these Logs, and receive SCTs back.  However, you would not be able to verify these SCTs without the public keys for the Logs, which is also metadata that isn't exposed by the Log itself.

I guess the point is, while yes, you can get the roots for a Log using an API endpoint, there are other important pieces of information about Logs that aren't provided by the logs themselves.

But yes, this would be a piece of metadata about the Log that is not exposed directly by the Log itself (and I'm not sure this is something we can do anything about).

 

 

If we were to have some requirement that anyone who uses this scheme has to run a set of Logs such that the expiry date for any newly issued certificate (that can be used right away) must be able to make it into one of their Logs, then CAs and site operators could just submit their certificate to every Log in the set, with the understanding that only one will return an SCT, and just use the SCT that is returned.  This would remove the need for CAs/site operators to do expiry date checks.  I haven't properly thought through whether having such a requirement for sets of Logs using this scheme is reasonable or not though, so please do offer opinions!

That seems like it would mean 4x the load on logs, using your example, since any given certificate would be sent to 4 different endpoints to see which would take it.

Yes, this would be additional load on the Logs.  But this could occur today anyway, if CAs/site owners decided to just submit their certificates to all the Logs that are out there, and use the first X SCTs they receive back (a technique I swear I've heard someone (can't remember who) recommend in the past).

It's also interesting to note that we've never really had a problem with high load if most of the certificates being submitted are rejected.  The load problem (like the one Aviator saw) comes when a large amount of certificates are submitted and accepted by the Log.

 

This increases the load on CAs/submitters, but more substantially, increases the load on sites.

I don't really understand how it increases the load on CAs and sites... could you explain what you mean?

 

You either end up with a scheme where:

a) You try to grab the notBefore/notAfter out of the certificate prior to signature validating

b) You validate the signature (chain), and then grab the notBefore/notAfter

Both are with tradeoffs - confusion/untrusted data in a), additional load in b), so I'm curious how you plan to reconcile?

Who is 'you' in these options?  The Logs?  Is this about what order Logs would perform the notAfter date check vs checking cert signature and chain-to-accepted-root validation?  If so, I think this is an implementation detail that is up to the Log Operators.

The additional check to check that notAfter is in the expiration acceptance period would be required, yes.  I'm not sure it matters what order the checks are done in though... The only way a certificate will be accepted is if both the notAfter value falls in the right range *and* the signature/chain validates, so for a chain to be accepted, both checks must be done, and both checks must succeed.

Talking through the tradeoffs you mention:

a)  Suppose the Log checks the notAfter value first.  As you say, until the signature is validated, this value is untrusted.  But so what?  If the notAfter value has been altered so that it *is* within the require date range, the following signature validation will fail, so the cert will be rejected.  If it has been altered so that it *isn't* in the required date range, then the certificate will be rejected, but it would have been rejected anyway, because if it has been altered in any way the signature validation will fail.

b)  As I said, the additional notAfter time comparison would be required in addition to the signature/chain validation, so yes, there would be an extra step.

 

 

Yes, I agree, a minimum period of time for (End - Start) is needed.  I would probably suggest a minimum of 6 months or a year, at least to begin with.  If certificates become considerably more short-lived in the future, then this minimum can always be altered to reflect that.

What would be the reasoning/criteria for changing that minimum?

My thinking was simply that we should set a minimum, with the hope and expectation that it is a good choice, but also with the understanding that, as with everything, we won't know if we've got it quite right until it's out there being used, and so it may be we tweak the exact value in the future if need be.

 

I'm not sure about the need for a maximum.  As setting up a Log with these bounds is optional, choosing not to set the bounds at all (in the way that Logs are currently run) is similar to having an infinite bound.  If a Log chooses to have a longer period, that's their choice.  That being said, we could offer advice on what we think good choices could be, but perhaps it should be just advice rather than a hard maximum.

Well, if the argument is that it's good for the ecosystem - clients rotating logs, logs having fixed lifetimes, surely from an ecosystem perspective, setting a maximum of 'beyond this is bad practice' is good :)

True.  Perhaps the best way to go about it then would be to set a minimum and maximum *if you choose to use this idea*, so that already existing Logs can continue just going about their business, but then any Logs that want to use this new idea would be constrained to minimum and maximum cert expiration acceptance periods.

 

 

You might be right about having some requirement on which root certs a Log must accept in order for a Log to be allowed to specify an expiration acceptance period.  It's a tricky one though.  From our team's perspective, the majority of certificates that are coming into our open Logs are Let's Encrypt certs.  Certificates from other roots make up only a tiny proportion of the total certificates.  This can be seen by comparing Log sizes for Icarus (currenlty ~63M certs) and Skydiver (currently ~2M certs).  From the pov of this idea helping to restrict Log size, any Log not accepting Let's Encrypt roots shouldn't really need to manage their Log size.  That being said, such Logs may still want to use this idea for Log lifetime management.  But in that case, perhaps the minimum expiration acceptance period for Logs that don't accept all roots should be longer (O(years) rather than O(months)?).

I don't think we want such logs, so that naturally suggests that all logs would need to use this idea, right? :) 

Hehe I like your ecosystem idealism.  So you're saying if Log Operators want to be able to manage their Log lifetimes (using this idea) they have to run open Logs?  It would make a good incentive for Log Operators to open up their Logs...

Could use some feedback from other Log Operators on whether they would want to use this idea, and if so how they would want to use it and why really.  I can only speak for the experiences and hopes for this idea that our team has.

 

 

All of that being said, part of the reason our team did the Icarus/Skydiver split, was so that if a Log accepting Let's Encrypt certs failed due to not being able to handle the quantity of Let's Encrypt certificates it was receiving, certificates issued by other CAs would not be affected (as their Log would still be up and running).  Being able to do splits like these for similar reasons, while also implementing expiry acceptance periods on the Logs could be useful...

I'm not convinced that splitting accepted roots is good for the ecosystem. Surely by relating to validity period, we still achieve the reasonable balance - since, after all, the risk of N logs failing (and that are critical) is not equivalent to the risk of a single log failing. 

Yeah, I think (although I probably need to think about it more to fully convince myself) I agree that the need to shard roots (for the purpose of managing Log size) could be removed by using this idea.

Another interesting question to put out there is what happens when a Log with a certificate expiration acceptance period (as I appear to have named it) expires, i.e. the *now* passes the End value specified by the Log?

There are a few options I can think of:

  - The Log is no longer needed, as any certificates in it are now expired, so UAs won't accept them anyway as they are expired.  So the Log can be switched off.

  - The Log becomes read only.  So certificates it contains can still be accessed, but it doesn't accept any new submissions.

  - The Log becomes fully archival.  This means the Log continues operating as it was before.  Expired certificates that are found that fall within the Log's certificate expiration acceptance period are still accepted.

Is suppose the answer to this question is probably 'it's up to the Log Operators'.  There are benefits to not just switching the Logs off though, as one of the purposes of CT is to detect misbehaviour by CAs, even if it was in the past, so keeping expired certificates accessible can be useful for that (this was brought up on the other ct-policy thread I started, and ties in there, although I haven't got around to replying to that thread yet!), but this depends on the willingness-to-help-just-for-the-good-of-the-internet of Log Operators :)

Food for thought.

[Ryan Sleevi]

On Thu, May 25, 2017 at 12:36 PM, 'Kat Joyce' via Certificate Transparency Policy <ct-p...@chromium.org> wrote:

This increases the load on CAs/submitters, but more substantially, increases the load on sites.

I don't really understand how it increases the load on CAs and sites... could you explain what you mean?

CAs/Submitters now have 4x the # of logs to send to, thus 4x the egress traffic :)

 

You either end up with a scheme where:

a) You try to grab the notBefore/notAfter out of the certificate prior to signature validating

b) You validate the signature (chain), and then grab the notBefore/notAfter

Both are with tradeoffs - confusion/untrusted data in a), additional load in b), so I'm curious how you plan to reconcile?

Who is 'you' in these options?  The Logs?  Is this about what order Logs would perform the notAfter date check vs checking cert signature and chain-to-accepted-root validation?  If so, I think this is an implementation detail that is up to the Log Operators.

Well, I was hoping we might specify best practice, if not in policy, then certainly in example.

 

The additional check to check that notAfter is in the expiration acceptance period would be required, yes.  I'm not sure it matters what order the checks are done in though... The only way a certificate will be accepted is if both the notAfter value falls in the right range *and* the signature/chain validates, so for a chain to be accepted, both checks must be done, and both checks must succeed.

Talking through the tradeoffs you mention:

a)  Suppose the Log checks the notAfter value first.  As you say, until the signature is validated, this value is untrusted.  But so what?  If the notAfter value has been altered so that it *is* within the require date range, the following signature validation will fail, so the cert will be rejected.  If it has been altered so that it *isn't* in the required date range, then the certificate will be rejected, but it would have been rejected anyway, because if it has been altered in any way the signature validation will fail.

b)  As I said, the additional notAfter time comparison would be required in addition to the signature/chain validation, so yes, there would be an extra step.

Fair points.

 

True.  Perhaps the best way to go about it then would be to set a minimum and maximum *if you choose to use this idea*, so that already existing Logs can continue just going about their business, but then any Logs that want to use this new idea would be constrained to minimum and maximum cert expiration acceptance periods.

I suppose there's a subtext I should make more clear - I'm wondering whether all (new) logs should be required to do this, modulo Andrew's remarks about sub-CAs.

 

Hehe I like your ecosystem idealism.  So you're saying if Log Operators want to be able to manage their Log lifetimes (using this idea) they have to run open Logs?  It would make a good incentive for Log Operators to open up their Logs...

I'm suggesting Log Operators, by policy, should be expected to run Open Logs. Which, effectively, necessitates an idea like this, which then goes back to figuring out what the appropriate bounds/parameters are.

 

Yeah, I think (although I probably need to think about it more to fully convince myself) I agree that the need to shard roots (for the purpose of managing Log size) could be removed by using this idea.

Another interesting question to put out there is what happens when a Log with a certificate expiration acceptance period (as I appear to have named it) expires, i.e. the *now* passes the End value specified by the Log?

There are a few options I can think of:

  - The Log is no longer needed, as any certificates in it are now expired, so UAs won't accept them anyway as they are expired.  So the Log can be switched off.

  - The Log becomes read only.  So certificates it contains can still be accessed, but it doesn't accept any new submissions.

  - The Log becomes fully archival.  This means the Log continues operating as it was before.  Expired certificates that are found that fall within the Log's certificate expiration acceptance period are still accepted.

Is suppose the answer to this question is probably 'it's up to the Log Operators'.  There are benefits to not just switching the Logs off though, as one of the purposes of CT is to detect misbehaviour by CAs, even if it was in the past, so keeping expired certificates accessible can be useful for that (this was brought up on the other ct-policy thread I started, and ties in there, although I haven't got around to replying to that thread yet!), but this depends on the willingness-to-help-just-for-the-good-of-the-internet of Log Operators :)

Yeah, I think the first option - fully removing the log from the UA - works, and the log can become read only/archival at the Log Operator's discretion. 

[Ben Laurie]

Another possibility is to allow a log operator to operate N logs, all
sharing a single submission point.

The promise is that at least one of the N logs will accept certs
issued by the specified roots.

The log operator has full discretion over which of the N logs it is
for any particular cert.

It seems to me this adds no complexity for anyone except the log
operators - CAs still get an end-point per operator to submit to
(indeed, this may reduce the number of end-points they have to deal
with) and monitors/auditors etc still get a list of logs to
monitor/audit.

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

[Pierre Phaneuf]

On Fri, May 26, 2017 at 1:44 PM, 'Ben Laurie' via Certificate
Transparency Policy <ct-p...@chromium.org> wrote:

> Another possibility is to allow a log operator to operate N logs, all
> sharing a single submission point.
>
> The promise is that at least one of the N logs will accept certs
> issued by the specified roots.
>
> The log operator has full discretion over which of the N logs it is
> for any particular cert.

That ties in a bit to different ideas that were discussed at the CT
days in February, of various ideas about "meta-logs". While I'm not
sure about the idea of meta-logs (or, rather, not sure enough to
formulate a concrete policy proposal), the of a proxy in front of
otherwise "normal" logs (each handled separately as per the Chromium
policies) has been bounced around often, here. A simple proxy could
potentially be stateless and very simple to operate (just configure
the backend logs).

If we set the idea of a proxy aside... Maybe I'm assuming a lot here,
but what I would expect a CA to do would be to submit to all the logs
in parallel, and embed the first SCTs that result in compliance with
the policy? If that's the case, there's really no more complexity for
the CA: just throw the cert at all the logs, and "see what sticks"?

[Ryan Sleevi]

On Fri, May 26, 2017 at 8:44 AM, 'Ben Laurie' via Certificate Transparency Policy <ct-p...@chromium.org> wrote:

Another possibility is to allow a log operator to operate N logs, all
sharing a single submission point.

The promise is that at least one of the N logs will accept certs
issued by the specified roots.

The log operator has full discretion over which of the N logs it is
for any particular cert.

It seems to me this adds no complexity for anyone except the log
operators - CAs still get an end-point per operator to submit to
(indeed, this may reduce the number of end-points they have to deal
with) and monitors/auditors etc still get a list of logs to
monitor/audit.

I'm not sure I would agree with that analysis of the complexity tradeoff.

For example, while you're correct a party submitting a certificate (whether a CA or server operator) may have a single 'ingestion point' to submit to, the SCT returned may contain any 1 of N signatures (since each log will need distinct keys to avoid violating the No Split Views on the STHs), and thus need to be capable of verifying any one of these signatures (versus, say, an invalid signature in the response). Similarly, as you imply, not all APIs will be consistently aggregatable - for example, getting the tree state is not (due to the distinct trees), while it may be that getting the roots is (whether because all logs share the same roots or because they can be aggregated in total).

That said, I think it's interesting to consider in conjunction with Kat's proposal, and perhaps useful to explore this space. It does seem like it's strictly an optimization/simplification for the submitter, without necessarily any reduction in work for clients, submitters, or auditor/monitors. Is that a fair conclusion?

[Pierre Phaneuf]

On Tue, May 30, 2017 at 5:00 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

> For example, while you're correct a party submitting a certificate (whether
> a CA or server operator) may have a single 'ingestion point' to submit to,
> the SCT returned may contain any 1 of N signatures (since each log will need
> distinct keys to avoid violating the No Split Views on the STHs), and thus
> need to be capable of verifying any one of these signatures (versus, say, an
> invalid signature in the response). Similarly, as you imply, not all APIs
> will be consistently aggregatable - for example, getting the tree state is
> not (due to the distinct trees), while it may be that getting the roots is
> (whether because all logs share the same roots or because they can be
> aggregated in total).

A user of such a proxy couldn't be simply a "plain" CT client, it
would have to be aware it could get SCTs from different logs, I
expect. So it seems reasonable that such a proxy wouldn't have to
provide all the API endpoints of a log, avoiding the problem of some
of them being difficult to aggregate.

Getting an SCT from a log ID that the submitter does not know about
(and so, wouldn't have the public key needed to verify the signature)
would be a problem, though.

> That said, I think it's interesting to consider in conjunction with Kat's
> proposal, and perhaps useful to explore this space. It does seem like it's
> strictly an optimization/simplification for the submitter, without
> necessarily any reduction in work for clients, submitters, or
> auditor/monitors. Is that a fair conclusion?

"Work" being things like verification of signature? Or things like
maintaining configuration files and such?

[Ryan Sleevi]

On Tue, May 30, 2017 at 12:56 PM, Pierre Phaneuf <ppha...@google.com> wrote:

On Tue, May 30, 2017 at 5:00 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

> For example, while you're correct a party submitting a certificate (whether
> a CA or server operator) may have a single 'ingestion point' to submit to,
> the SCT returned may contain any 1 of N signatures (since each log will need
> distinct keys to avoid violating the No Split Views on the STHs), and thus
> need to be capable of verifying any one of these signatures (versus, say, an
> invalid signature in the response). Similarly, as you imply, not all APIs
> will be consistently aggregatable - for example, getting the tree state is
> not (due to the distinct trees), while it may be that getting the roots is
> (whether because all logs share the same roots or because they can be
> aggregated in total).

A user of such a proxy couldn't be simply a "plain" CT client, it
would have to be aware it could get SCTs from different logs, I
expect. So it seems reasonable that such a proxy wouldn't have to
provide all the API endpoints of a log, avoiding the problem of some
of them being difficult to aggregate.

Yes, that was what I was trying to state :)

 

Getting an SCT from a log ID that the submitter does not know about
(and so, wouldn't have the public key needed to verify the signature)
would be a problem, though.

> That said, I think it's interesting to consider in conjunction with Kat's
> proposal, and perhaps useful to explore this space. It does seem like it's
> strictly an optimization/simplification for the submitter, without
> necessarily any reduction in work for clients, submitters, or
> auditor/monitors. Is that a fair conclusion?

"Work" being things like verification of signature? Or things like
maintaining configuration files and such?

Both