On 18 May 2015, at 17:08, Ben Laurie <[email protected]> wrote:
> > > On 18 May 2015 at 15:50, Stephen Farrell <[email protected]> wrote: > (All those issue tracker mails reminded me of a question > I'd meant to and had forgotten to ask...) > > At the acme BoF there was some talk of short lived certs. > The thought was that if acme succeeds then it'd be more > practical to use certs with a lifetime of a day or so. And > that might raise a question as to how that'd affect CT or if > there's an elegant way to support such. > > I don't think this is something that has to be part of the > current bis RFC necessarily but it'd probably be good to > get the collective wisdom of the list on the topic. > > So, what do we think of CT when faced with 1 day duration > certs or similar? > > CT is necessarily after the fact detection anyway. However, 1 day duration > certs would make that more painfully obvious! > > That said, if you are issuing 1 day certs, then clearly you are going to be > replacing them every day. Presumably you could issue them in advance, so they > appeared in the log before they were valid. > > The other thing to consider is the size of the log - I would want a different > log for short-duration certs, since it will grow fast, but also most of it > rapidly becomes irrelevant and can be ignored. +1; it seems to me that the sensible way to improve scalability is to segregate the high-volume, ephemeral certs from the longer-lived ones as early as possible (presumably by checking if “not valid after” is only a day or so greater than “not valid before”). As Ben implies, I think it’s also generally valid to assume that ephemeral certs would give rise to a different kind of risk from that of longer-lived certs, so the corresponding CT logs would benefit from different management/policy. Yrs., Robin > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
