Hi, 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.
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. Cheers, Al. On Wed, Nov 8, 2017 at 10:04 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) <[email protected]> wrote: > Hi Eran, > > > > Thanks (again) for your insight. > > > > Do you think we’d need a 6962-ter to accommodate STAR? Or could we > specify a different SCT format and processing rules for STAR-like > certificates in the framework defined by 6962-bis? > > > > Cheers > > > > On 08/11/2017, 00:54, "Eran Messeri" <[email protected]> wrote: > > > > One way for a single SCT to be valid for multiple certificates is to omit > the fields that change from the data covered by the SCT's signature. > > For short-lived certificates this would (likely) be the serial number, > notBefore and notAfter dates. > > > > This means there's no need to re-request an SCT each time a new > short-lived certificate is minted, and the SCT covers all key fields in the > certificate's TBSCertificate structure (Subject Alternative Names, key, > etc). > > The drawback is that without a serial number (1) it is not possible to > verify CAs don't violate the unique serial number requirement (effectively > reducing auditing capabilities) (2) mis-issued certificates can't be > revoked using the usual means. > > > > Note that such a mechanism cannot be implemented either using 6962 or > 6962-bis: Both documents mandate that the SCT covers all fields in the > TBSCertificate (at least). But, if the design was changed to exclude some > fields, it seems to me that this solution would otherwise be compatible > with the rest of the CT protocol. > > > > On Mon, Nov 6, 2017 at 9:09 PM, Melinda Shore <[email protected]> > wrote: > > The question of how to log short-lived certificates is something > that's been coming up more frequently recently, and it's > independent (mostly) of the issuance mechanism. I think we've > got time to discuss it during the session at IETF 100, and > it would be helpful if there's a specific proposal to use as > a starting point. Will the folks working on this be > at the meeting? > > Melinda > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
