googlechrome / certificatetransparency Goto Github PK

There could be a situation where a log distrust action will have to be applied retrospectively. I.e., if it comes to light that a log has been maliciously operating over the last 6 months, I assume SCTs from such a log would have to be retrospectively rejected?

The current policy and the definition of "once qualified" doesn't seem to account for such a scenario. It allows for a SCT to be acceptable as long as the log was qualified at the time of cert issuance.

The current CT Policy background provides historic context about things that have been required to be CT Qualified, but can be easily misunderstood as being an exhaustive list of everything that is required to be CT Qualified.

The introduction should be reworded to de-emphasize EV certificates, while continuing to introduce the notion of "CT Qualified" and its context.

Currently, the number of SCTs related to the Lifetime of Certificate is defined in months. However, this leaves it ambiguous as to how to calculate it.

Several possible interpretations have been arrived at:

• Treating every month as 31 days, thus 15 months is 465 days
• Treating 15 months as the maximum legitimate period (366 days, followed by a 3 months sequence of July/Aug/Sept at 31 + 31 + 30), or 458 days
• A complex scheme of rounding, such that: (notAfter.year - notBefore.year) * 12 + (notAfter.month - notBefore.month), and then subtracting one if notAfter.day < notBefore.day.

Expressing this in days is seen as least ambiguous.

For Chrome, this is https://bugs.chromium.org/p/chromium/issues/detail?id=713362

This post by Devon O'Brien states that:

Since January 2015, Chrome has required that Extended Validation (EV) certificates be CT-compliant in order to receive EV status. In April 2018, this requirement will be extended to all newly-issued publicly-trusted certificates - DV, OV, and EV - and certificates failing to comply with this policy will not be recognized as trusted when evaluated by Chrome. Certificates issued from locally-trusted or enterprise CAs that are added by users or administrators are not subject to this requirement.

Reference: https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/wHILiYf31DE/iMFmpMEkAQAJ

That post links to the policy in this repository which mentions the CT requirement for EV, doesn't not mention the DV and OV certificates.

Reference: https://github.com/chromium/ct-policy/blob/master/ct_policy.md

Should this be updated or do I misunderstand the new requirements.

CC: @sleevi

The https://github.com/chromium/ct-policy/blob/master/README.md document says things like "Chromium requires" but CT enforcement is not enabled in Chromium by default.

We should replace "Chromium" with "Chrome" when describing product behavior.

There are several Logs pending inclusion which would restrict their set of accepted Root Certificates to a limited subset of CAs.

Does this meet the definition of "operating in the public interest?" Is there a minimum set of root certificates that must be accepted? How frequently should that change (for example, an existing CA creates a new root for inclusion - does it occur before or after inclusion)?

RFC6962 notes that "In order to avoid logs being spammed into uselessness, it is required that each chain is rooted in a known CA certificate." If a log accepts certificates that are signed with weak signature algorithms (e.g., md2WithRSAEncryption, md5WithRSAEncryption), there may be a risk that an attacker could mint fake certificates (where the hash of the TBSCertificate matches that of an existing certificate) at a rate that's fast enough to spam the log into uselessness.

This issue could be mitigated by policy, perhaps by requiring logs to...

• not accept certificates signed using certain (weak) signature algorithms (i.e., blacklist).
  or
• only accept certificates signed using certain (non-weak) signature algorithms (i.e., whitelist).
  or
• implement rate limiting for certain (weak) signature algorithms.

The policy is currently unspecified as to what TLS certificate must be used for a Log.

This creates compatibility issues for monitors and clients, as seen at https://groups.google.com/a/chromium.org/d/msg/ct-policy/0B46Z5UcbuE/nIem5EBbAAAJ .

Under the Retired heading on the log states/lifecycle page, the information for how a Retired log transitions to other log states is a direct copy-paste from the second point of the transition info for the ReadOnly log state.

RFC 6962, Section 3.1 states:

Logs MUST verify that the submitted end-entity certificate or
Precertificate has a valid signature chain leading back to a trusted
root CA certificate, using the chain of intermediate CA certificates
provided by the submitter. Logs MAY accept certificates that have
expired, are not yet valid, have been revoked, or are otherwise not
fully valid according to X.509 verification rules in order to
accommodate quirks of CA certificate-issuing software. However, logs
MUST refuse to publish certificates without a valid chain to a known
root CA.

Some clarifications would be useful:

• Can a log reject a certificate for an EKU (e.g. rejecting code-signing or clientAuth certificates) as a means of reducing the risk of PII being logged.
• How does a long a determine there is a 'valid' chain if one or more intermediates have been revoked?
• Can a log define policies, such as validity period, to appropriately scope the growth of a log?
• Can a log restrict or limit the use of name-constrained subCAs, to prevent spam/abuse?

GoogleChrome certificate transparency (docs)
https://github.com/GoogleChrome/CertificateTransparency/blob/master/log_policy.md?plain=1#L17
https://github.com/GoogleChrome/CertificateTransparency/blob/master/log_states.md?plain=1#L9 (maybe not this one?)
https://github.com/GoogleChrome/CertificateTransparency/blob/master/log_states.md?plain=1#L86

The Chromium implementation of CT is limited in support of public keys to the set of public keys it accepts for the Web PKI:

• RSA (nominally, 2048, 3072, 4096)
• ECC using NIST P-256, P-384

The Chromium implementation does not explicitly support Curve25519, although it could, and does not support other forms of EC keys.

@jsha raised this on the ct-policy mailing list , highlighting how TLS allows certificates up to 2^24 bytes (16.7 MB), while it's likely that logs may have a much smaller maximum client body size, or have implementations (e.g. MySQL) which have limits on maximum row size in some design.

Large certificates totally exist, and it should be better specified how to handle these.

https://ct.googleapis.com/pilot
https://ct.googleapis.com/aviator
....
these URLs don't exist.

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.

As part of https://groups.google.com/a/chromium.org/d/msg/ct-policy/C3egwJb8Bp4/myrWhXQtAwAJ , it was suggested that there should be additional questions related to Logs' operational policies that would offer greater transparency for the community.

While that discussions included a number of questions to be refined, in that set, a few stand-out as immediately applicable:

1. What requirements the Log operator has, if any, for including a Root
2. What fees, if any, are required for including a Root
3. What policies exist for the acceptance/rejection of certificates (such as #3 )
4. The circumstances, process, and policies for removing a Root

The CT team at Google has announced on the ct-policy list that they are running mirrors for all CT logs recognized by Chrome. It would be useful to make a copy of the mirrors list in this repo alongside the list of logs, so it is easy to find them.

Proposal and discussion: https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/zVW7lDySFk4

Potential Attack:

• Suppose one of the accepted root certs of a CT Log expires on Jan5 of a year.
• After Jan5, the CA who owned the root cert, is no longer required to keep the keys for that root certificate a secret, or protected in any way [needs citation]. So suppose on Jan6 an attacker gets hold of the keys for that now-expired root cert.
• Suppose said attacker then issues loads (for some value of loads that would be too much for a log to handle) of certificates that have a ‘Not After’ value of Jan4. These would be already-expired certificates, so are no use for server impersonation, but could be used to attack a CT Log if it accepts expired certificates…
• Suppose on Jan6 the attacker submits all of the loads of certificates to the Log. The Log could be DoS’d into oblivion, and/or filled until it reaches a size greater than the Log can handle.

Mitigation:

Recommend that CT Logs only accept certificates that have a 'Not After' value later than the time of submission to the Log.

Right now, the Inclusion Request bug is not linked in the table on the main page, only the revision in which the Log was first Qualified.

For CAs that wish to examine Logs' policies and/or reach out to the Log Operator, the Inclusion Request bug is the canonical source of truth, and so would benefit making that more prominent. Viewing the commit is an extra level of indirection that could be simplified by listing the Inclusion Request bug directly.