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. The SkipChain structure for cryptographically-traversable, collectively-signed blockchains, detailed in our CHAINIAC work that I just mentioned (https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/nikitin <https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/nikitin>), may be of use here. The SkipChain structure is designed to support groups of collective signers whose public keys may change quite rapidly, while ensuring that any client or validator can “catch up” with its peers’ state quickly and efficiently no matter how far behind in time they may be. For example, SkipChains were designed to support permissionless blockchains such as Bitcoin or ByzCoin (https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kogias <https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kogias>), where the the collective signing group is defined by a window of recent proof-of-work miners that may change very 10 minutes. The SkipChain structure enables new or long-offline light clients or full nodes to catch up with the state of the blockchain from any recent collectively-signed snapshot, without everyone having to store the entire blockchain history. In practice we expect some subset of validators well-provisioned with storage would still store the entire history, but that becomes optional rather than mandatory. Note that I’m definitely not suggesting that CT would want proof-of-work; just bringing this up as an example “torture test” for frequently-changing keys/certificates that the SkipChain structure is designed and already demonstrated to support efficiently. The property that SkipChains allow nodes (e.g., log servers, CAs, and/or clients) to prune their storage of rapidly-changing logs more aggressively seems like the property most likely of potential valid here. But in any case, how exactly SkipChains would best fit into CT and/or STAR is of course an open question for discussion, which I’m happy to participate in if there’s interest. Bryan
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
