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? TLS delegated credentials seem to do what we want, but maybe I don't understand the problem well enough. Pruning chains of expired certs has implications for misbehavior detection. Sincerely, Watson _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
