BTW, its probably smart to design a more general transparency standard and then have profiles for different use cases. But we did decide not to do that until we had other examples of transparency (I'm building one right now, as it happens, and it is not the only one I am aware of).
On 3 November 2016 at 10:31, Ben Laurie <[email protected]> wrote: > On 2 November 2016 at 14:08, Peter Bowen <[email protected]> wrote: >> >> By requiring all logs MUST accept any certificate that chains to a >> root in the log's root list, 6962bis fails to allow log operators to >> mitigate any Denial of Service attacks mounted by attempting to log >> massive numbers of certificates that are not relevant to the log >> scope. For example, many existing certification authorities issue >> both server authentication certificates and certificates for personal >> identification. For some roots, acquiring large numbers of these is >> relatively easy (see discussion of fetching millions of Taiwanese >> Citizen Digital Certificates in >> https://smartfacts.cr.yp.to/smartfacts-20130916.pdf). As written >> today, a log MUST accept these. There is no option for a log to >> require that all certificates must meet some usability criteria. > > The requirement is to reject certs that don't meet the criteria, not > to accept those that do. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
