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

[Ben Laurie <[e-mail]>]

On 27 May 2014 15:47, <[e-mail]> wrote:

> Hi,
>
>
>
> I have some other questions
>
> -          What if a CA can´t belong or it´s not accepted in any log
> server?
>
I would assume that in the very worst case CAs could agree with each other
to log in each other's servers. But I strongly suspect this is not going to
be a problem.

> -          What if you need 3 logs for an EV and only get 2 for whatever
> reasons?
>
Then you had better get a third.


> -          Who´s managing that procedure to accept log servers? Google?
>
For Chrome: yes, Google will.

> Are they going to be registered/publicly available for CAs to choose?
>
Yes.


>
>
> Regards
>
>
>
>
>
> *Iñigo Barreira*
> Responsable del Área técnica
> [e-mail]
>
> 945067705
>
>
>
> [image: Descripción: cid:image001.png@01CE3152.B4804EB0]
>
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea
> gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi
> erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o confidencial a
> la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por
> error le agradeceriamos que no hiciera uso de la informacion y que se
> pusiese en contacto con el remitente.
>
>
>
> *De:* Trans [mailto:[e-mail]] *En nombre de *Dmitry
> Belyavsky
> *Enviado el:* martes, 27 de mayo de 2014 16:33
> *Para:* Stephen Kent
> *CC:* [e-mail]
> *Asunto:* Re: [Trans] Volunteer opportunity! (was Re: DNSSEC also needs
> CT)
>
>
>
> 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
>
> a.    allow user to accept the cert without CT providing warning about
> absence of CT
>
> b.    allow user to specify absence of log for this or that domain
> (non-public suffix)
>
> c.    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.
>
> d.    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.
>
>
>
>
>
> 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 list
>
> [e-mail]
>
> https://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.