On Tue, Sep 25, 2018 at 04:51:15PM -0400, Ryan Sleevi wrote: > On Tue, Sep 25, 2018 at 2:42 PM Stephen Kent <[email protected]> wrote: > > > This is problematic in that the assumption here is that CAs are the ones > > performing the logging. Throughout the document, the description of CAs > > performing logging ignores the ability of Subscribers and certificate > > holders to perform the logging at their discretion, up to and including > > seconds before performing the TLS handshake. As a consequence, it misses an > > entire class of attacks that can arise when an inclusion proof for an SCT > > can not be obtained to an STH, because the SCT is newer than the published > > STH. > > > > I believe this is another instance of a compelling reason to re-evaluate > > the ontology of attacks and to not attempt to classify them using a > > hierarchy. > > > > Although 6962-bis does allow any entity to log a cert, the focus of the > > doc is very much on CA-based logging, as evidenced by pre-cert logging. No > > changes made. > > > > Thanks. I'll stop my analsysis at this point, as I think it fundamentally > alters the subsequent conclusions that if we're not able to reach consensus > on this point, it does not seem that there's much value on proceeding > further. The entire analysis and threat model is undermined, in my view, to > the point that it no longer accurately reflects 6962-bis as specified, but > rather, an unspecified profile of it.
For what it's worth, I do not read 6962-bis as "very much being focused" on CA-based logging. Consider, for example, certificate subjects submitting certificates to logs, something that is done without CA involvement and can be done in response to (e.g.) Logs being distrusted or browsers increasing the required number of SCTs. It's unclear that CAs have as much incentive as subjects to be responsive to changing events in this way. -Ben _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
