Hello Ben,
On Tue, Jun 17, 2014 at 1:34 PM, Ben Laurie <[email protected]> wrote: > > > > On 16 June 2014 20:07, Stephen Kent <[email protected]> wrote: >> >> >> >> >> 1. >> >> Each browser should provide an editable way of managing logs. By >> default it should be a reasonable subset of “important” logs. >> >> The set of "important" logs might not include a CA that is important >> for a set of clients 9since log operators have complete discretion as to >> which CAs they accept) so it ought to be possible for a client to include a >> pointer to logs outside the default set. >> > > I agree. However, there is a security risk here: a client that includes a > log that is not audited has opened themselves up to abuse via mis-issue. > Well, now a client is able to add bad CA as trusted. I do not see extra security risks here. > > >> > >> >> 1. >> >> Browsers should >> 1. >> >> allow user to accept the cert without CT providing warning about >> absence of CT >> 2. >> >> allow user to specify absence of log for this or that domain >> (non-public suffix) >> 3. >> >> allow user to a particular log for this or that domain and return >> an error if there is no SCT for id provided by this log. >> 4. >> >> there should be a procedure of report about log misbehaviour in >> case of invalid log records >> >> These seem like reasonable suggestions, at least to begin, but none of >> them appear in the doc. >> I worry that, absent a description of minimum browser management >> interfaces for CT, we have no sense of whether users will be able to deal >> with incremental deployment. >> > > The IETF is far too slow-moving to get involved in browser UI, at least > for new/experimental features. Nor do I get much sense that we have the > necessary expertise in this WG. > I agree. But I think that it's a correct behavior of any CT-compliant client. Browsers, being interactive, can suggest an user to make a choice (yes, he will push the button "Add security exception" in 99%). Non-interactive software is to have command-line settings/config/etc. > >> >> >> 1. >> >> I think that warning is acceptable in case of an absence of SCTs, but >> in case of cryptographic errors the error should be generated. >> >> I presume you mean that if there is a crypto error, the cert should be >> rejected, a hard fail, right? >> > > For EV certificates, there will be no warning in Chromium: instead, there > will be no EV indication. > Even in case of invalid SCT? > > We have not yet decided exactly how things will work when we start > requiring CT for all certificates. > > >> >> Steve >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans >> >> > > > -- > Certificate Transparency is hiring! Let me know if you're interested. > -- SY, Dmitry Belyavsky
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
