Opened 9 years ago

Closed 8 years ago

#9 closed defect (fixed)

Security Considerations for number and variety of SCTs

Reported by: rob.stradling@… Owned by: benl@…
Priority: minor Milestone: review
Component: rfc6962-bis Version:
Severity: - Keywords:


Google Chrome's CT/EV rollout plan requires multiple SCTs, from multiple Logs, to be presented for each certificate (in at least some scenarios).

RFC6962 is completely silent on the topic of multiple SCTs, but I think RFC6962-bis should consider such questions as...

  • Why is it useful to require multiple SCTs? How does it strengthen the system?
  • Is it (un)acceptable for an SCT and the corresponding Certificate to be signed by the same organization (i.e. A CA that also runs a Log)?
  • When multiple SCTs are required to be presented, should the TLS Client verify all of them? Or just 1 of them?

I don't think RFC6962-bis should mandate the precise number of SCTs required, or mandate how many distinct Log-operating organizations should provide SCTs for any given certificate. Chrome, and any other TLS Clients that implement CT, should be free to set their own policies on these things.

Having said that, it might be useful to add Chrome's policy on multiple SCTs to RFC6962-bis _as a suggestion_ for other TLS Clients to consider implementing.

Change History (4)

comment:1 Changed 9 years ago by benl@…

  • Owner changed from draft-ietf-trans-rfc6962-bis@… to benl@…
  • Status changed from new to assigned


comment:2 Changed 8 years ago by benl@…

  • Resolution set to needs-review
  • Status changed from assigned to closed

comment:3 Changed 8 years ago by benl@…

  • Milestone set to review
  • Resolution needs-review deleted
  • Status changed from closed to reopened

comment:4 Changed 8 years ago by melinda.shore@…

  • Resolution set to fixed
  • Status changed from reopened to closed

New text:

      <section title="Multiple SCTs">
	  TLS servers may wish to offer multiple SCTs, each from a different log.
	  <list style="symbols">
	      If a CA and a log collude, it is possible to temporarily hide misissuance from clients. Incorporating SCTs from different logs makes it more difficult to mount this attack.
	      If a log misbehaves, a consequence may be that clients cease to trust it. Since the time an SCT may be in use can be considerable (several years is common in current practice when the SCT is embedded in a certificate), servers may wish to reduce the probability of their certificates being rejected as a result by including SCTs from different logs.
	      TLS clients may have policies related to the above risks requiring servers to present multiple SCTs. For example <xref target="Chromium.Log.Policy">Chromium</xref> currently requires multiple SCTs to be presented with EV certificates in order for the EV indicator to be shown.
Note: See TracTickets for help on using tickets.