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

[Ben Laurie <[e-mail]>]

On 27 May 2014 15:32, Dmitry Belyavsky <[e-mail]> wrote:

> 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.
>    2.
>
>    Any log-server can select the list of acceptable CAs. I think that
>    “important logs” should cover all the CAs supported by major browsers.
>    3.
>
>    Any log server can select the algorithm of hash for Merkle Tree and
>    for its key signing the SCTs.
>    4.
>
>    Each browser should provide an editable way of managing logs. By
>    default it should be a reasonable subset of “important” logs.
>    5.
>
>    Each CA can be accepted by more than one log.
>    6.
>
>    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
>       7.
>
>    I think that warning is acceptable in case of an absence of SCTs, but
>    in case of cryptographic errors the error should be generated.
>
>
Google will be publishing its log inclusion policy soon, which covers some
of these points. We have already published our EV/CT plan (
https://docs.google.com/a/google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxjZXJ0aWZpY2F0ZXRyYW5zcGFyZW5jeXxneDo1ZjkwYzYwMjVhYTRmZjY3),
which covers some others.

I am not at all convinced that any of them are in scope for
standardisation, though.


>
>
> On Thu, May 22, 2014 at 10:12 PM, Stephen Kent <[e-mail]> wrote:
>
>>  Dimitry,
>>
>> Thanks for posting the list below.
>>
>> I have become very concerned that the doc we're working on describes a
>> mechanism,
>> but we seem to lack a good description of the architectural context in
>> which CT
>> is supposed to work. The intro text for the I-D is not at all adequate
>> for this.
>> Maybe the charter for this WG would have included the need to publish a
>> doc of
>> this sort if we had gone through the usual BoF process :-).
>>
>> I'd like to see a doc that addresses a number of points that are now
>> beginning to
>> be raised by several folks:
>>     - who is expected to operate logs, does every log cover all CAs, is
>> one
>> log per CA (even if operated by someone else) adequate, how are users
>> supposed to
>> select logs (what the UI like?), etc.
>>     - how are browsers expected to deal with missing SCTs, missing or
>> non-matching
>> log entries, (crypto) invalid log entries, etc. are browser actions
>> supposed to be
>> effect in real time or is this deferred activity model?
>>     - hard fail vs. warnings for CT "exceptions?"
>>     - how are browsers expected to deal with certs from CAs that are not
>> part of the Web PKI?
>>     - what are the fallback plans if some number of the Web PKI CAs elect
>> to not
>> participate?
>>     - same question for major browser vendors?
>>     - what are the plans for alg aglity, for logs?
>>
>> CT is a system, not just a handful of mechanisms. It needs to be
>> described that way.
>>
>> Although not perfect, I suggest the set of RFCs that describe the RPKI is
>> illustrative
>> of the many aspects of a global system (with PKI aspects) that need to be
>> documented.
>>
>> Steve
>>
>>
>>>
>>  Here are my ideas about "strict" behaviour of the TLS client:
>>
>>  ==============
>>  TLS clients supporting CT are supposed to have a preconfigured set of
>> logs and
>> their public keys.
>>
>>  In addition to normal validation of the certificate and its chain, they
>> should
>> validate the SCTs received during the TLS connection.
>>
>>  The client fully conforming to the specification SHOULD perform the
>> following
>> steps before establishing the connection for every certificate in the
>> chain:
>>
>>  1. If no SCTs are provided, the client SHOULD reject the connection.
>>
>>  2. The client MUST ignore all the SCTs provided by unknown logs.
>>
>>  3. TLS clients MUST reject SCTs whose timestamp is in the future.
>>
>>  4. If no SCTs has left after steps 2-3, the client SHOULD reject the
>> connection.
>>
>>  5. If any of SCTs left after steps 2-3 has invalid signature, the
>> client SHOULD reject the connection.
>>
>>  Client MAY check whether the certificate is present in the log
>> corresponding to the passed SCT.
>> If the certificate is not present in the log, the connection MUST be
>> rejected.
>>  =============
>>
>>  Can it be a starting point or you want something else?
>>
>>  --
>> SY, Dmitry Belyavsky
>>
>>
>> _______________________________________________
>> Trans mailing [e-mail]://www.ietf.org/mailman/listinfo/trans
>>
>>
>>
>> _______________________________________________
>> Trans mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/trans
>>
>>
>
>
> --
> SY, Dmitry Belyavsky
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>
>


-- 
Certificate Transparency is hiring! Let me know if you're interested.