On Mon, Nov 6, 2017 at 1:30 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) <[email protected]> wrote: > Hi everybody, > > > > Context > > We are working on STAR [1], an ACME extension to allow a name owner to > obtain a string of short-lived certificates that are automatically renewed > by the issuing CA. > > Using STAR, the name owner controls the lifetime of the renewal process, > which can continue for as long as initially agreed, or prematurely come to a > halt due to, e.g., a key compromise. > > STAR removes the dependency on the revocation infrastructure, while at the > same time automating (and minimizing) the interaction of the certificate > owner with her RA/CA. > > So far so good. > > > > STAR + CT > > Obviously, we’d want STAR to work well with Certificate Transparency. > > However, it looks like this might not be as easy as we want it to be because > of the increase of the ingestion rate and consequent implications on log > structure, implementation, rotation, monitoring, etc. > > What we were thinking, though – and this is where we’d need your help, since > none of us is a CT expert – is that a STAR certificate, except in the > degenerate case where users requests a very low number of renewals, can be > thought of as a single “usual” certificate that is made of a collection of > same short-lived certificates that differ only for their (sliding) validity > windows.
We also have work in TLS on short term credentials that can be issued by people with the private keys of certificates. Could this be shoehorned to solve the problems STAR solves without requiring lots of CT entries? -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
