On 12 November 2017 at 01: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? > The problem is revocation (or the lack of it). We actually know how to solve transparency for revocation, and what's more Trillian provides the necessary infrastructure, so I'm not entirely sure why we'd want to make the job of checking for misissued certs 100x more expensive rather than just making revocation work properly (which presumably could use the same underlying mechanism to determine revocation status). > 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 >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
