Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs CT)

[Stephen Kent <[e-mail]>]

Dmitry,

My replies are inline. sorry that my mail program renumbered each of 
your bullets as I inserted my replies :-(.

> Hello Stephen,
>
> Here is my understanding of the question you asked.
> Let Ben or Rob fix me if I'm wrong.
>
> 1.
>
>     Anybody is allowed to operate log. But there should be a procedure
>     (similar to CA/Browser forum) which is determined to register log
>     as "important" (we need a better word). There should be not many
>     "important" log servers, I suppose --- otherwise we are to get the
>     same problem as we have with many CAs.
>
As you note, the notion of establishing some logs as "important" would 
borrow from the
CABF, but we're the IETF and this is intended to be an IETF standard. 
So, I think this
doc needs to address this issue in a fashion consistent with IETF 
procedures.
>
> 1.
>
>     Any log-server can select the list of acceptable CAs. I think that
>     "important logs" should cover all the CAs supported by major browsers.
>
The doc suggests this, but again, this has a CABF feel to it. IETF 
standards do not endorse
implementations and use decisions by vendors to drive standards.
>
> 1.
>
>     Any log server can select the algorithm of hash for Merkle Tree
>     and for its key signing the SCTs.
>
That's not what the doc says; it establishes two MTI algs that all 
clients must support, while log operators are allowed to pick form 
between the two. This seems a bit backwards to me, in that it imposes 
the greater burden on the larger # of implementations.
>
> 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.
>
> 1.
>
>     Each CA can be accepted by more than one log.
>
"Might be" is the more accurate characterization, based on the current 
doc. There is no requirement that any log operator accept submissions 
from a specific CA. Each log operator indicates what CAs/TAs it supports.
>
> 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.
>
> 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?

Steve