Hi Al, On 08/11/2017, 14:59, "Al Cutter" <[email protected]> wrote: > I'm a fan of short-lived certs, but I'm not particularly keen on the > idea of not logging publicly rooted certs - the point of CT is the > discoverability of misissuance after all, and it does seem that having > an SCT which could refer to a whole set of "similar" yet unlogged > certs is not a great idea, e.g. a scenario where the key is > compromised by an entity which can coerce the CA into issuing more > "non-logged" certs to cover any period the proud new owner of the key > material would like.
A STAR certificate is not open ended. Its overall validity is bounded by the recurrent-start-date and recurrent-end-date attributes that are negotiated at the time the ACME order is made. It is my impression that both recurrent-start-date and recurrent-end-date should go in the SCT to provide semantics equivalent to the notBefore/notAfter attributes of "regular" certificates. If so, in the key compromise & CA coercion scenario that you are describing, the attacker would not be able to convince the CA to issue other short-term certificates than those which are already lined up - up to recurrent-end-date - while also confusing CT. Coercion would only result in ignoring any attempt from the user to terminate the STAR order, similarly to the CA coerced to avoid updating revocation information on key compromise with a "regular" certificate. Am I missing something? (Probably so...) > I'll point out that there does seem to be an underlying premise here > that it's simply not possible to log all these short-lived certs, have > we considered whether that's actually the case? Back of the envelope: > currently, the global issuance rate of certs is < 10 per second on > average [90d average growth of Pilot is actually < 5/s]. The > overwhelming majority of certificates come from Let's Encrypt, and > currently all have a lifetime of 90 days. If we're talking about > reducing that cert lifetime to 24h then we're looking at 90x increase, > so let's call it 1k/s. > > Even if we're assuming that every cert must be logged to every Log I > think that's achievable by the Trillian-based logs, and I'll coyly > mention that I'm aware of one other Log implementation which I'm led > to believe is more than capable of sustaining that level of > throughput. Were that not the case, it's also not hard to imagine > schemes for spreading this load around if need be (e.g. sharding by > modulo of cert hash etc., "smart" load-balancing CT proxies, etc. > etc.) > > Log growth to very large sizes can be already be addressed by schemes > such as Chrome's Temporal Log Policy which allow Operators to define > their Log life-cycle, and CAs, UAs, Monitors, and any other interested > entity to build-in support for that life-cycle ahead of time. > > There might be other concerns of scale elsewhere, but I'm not sure > that it's in the logging. Very interesting. Cheers _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
