Hi Watson, On 12/11/2017, 09:40, "Watson Ladd" <[email protected]> wrote: > On Sat, Nov 11, 2017 at 3:44 AM, Bryan Ford <[email protected]> > wrote: > > On Nov 8, 2017, at 3:59 PM, 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. > > > > 100% agreed on this point. Short-term certs are good, and they all > > should - and can - be publicly logged to ensure transparency. To > > whatever extent this capacity issue is a problem in the current CT > > design, this is a problem with CT that needs to be fixed. > > What are the problems we are trying to solve with short-term certs and > can we come up with a way to solve them that doesn't have the > implications for CT of the current proposal?
Al was pointing out that maybe the 100x increase in ingestion (worst case, assuming every cert becomes a STAR cert) would not be the end of the world. And even if it were, there might be scalability strategies that might mitigate/fix it? > TLS delegated credentials seem to do what we want, but maybe I don't > understand the problem well enough. The main issue with DC is that until all the clients have upgraded their TLS stack (and even then, they must decide to opt-in DC), server side you need to maintain a LURK-box fall-back, which is neither cheap nor scalable. Sadly, the upgrade cycles of a STB or a CPE is completely different from that of modern browsers. Short-term certs from that point of view, just work out of the box. (See also the discussion on the TLS mailing list at the time the call for adoption of DC was made [1].) Cheers [1] https://www.ietf.org/mail-archive/web/tls/current/msg24098.html _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
