Subject: [Trans] Looking for feedback on open issue

From: Melinda Shore <[email-masked]>
Date: Tue, 2 Feb 2016 12:01:33 -0900

Hi, all:

We're looking for feedback on ticket 121
(https://trac.tools.ietf.org/wg/trans/trac/ticket/121).

The issue is this (from Steve Kent):

"After Prague I agreed that log metadata can be supplied by browser 
vendors for TLS clients hat are browsers. However, max chain length, 
which was just discussed on the list (11/16-17/15), is an example of 
metadata that needs to be acquired by CAs, just like the public key for 
a log. The text in Section 9 needs to say more about how non-browser log 
clients are expected to acquire this data, or maybe it should say that 
separate docs defining requirements for each of these types of log 
clients will discuss this issue."

and where it currently stands is this (from Eran Messeri):

I agree that log metadata dissemination is a topic that should be more 
thoroughly discussed at some point. However, I do not think that 
6962-bis is the right place for it.
Steve has a very valid point about metadata not being specified in a 
machine-readable format, nor having a part of the protocol describing 
how it is disseminated.
I believe these issues should be addressed separately of 6962-bis, because:
The topic of log metadata is one level "above" what 6962-bis discusses.
The requirements for metadata dissemination are very different for each 
type of client.
Disseminating metadata reliably is a protocol in itself, which (once the 
requirements are clear) deserve its own design.
My suggestion is to punt the discussion until after 6962-bis is out. 
Presumably then there would be enough different clients implementing 
6962-bis that disseminating metadata would justify more efforts from 
this workgroup.

This needs further discussion - should this go into a separate
document?

Melinda

---

From: Ben Laurie <[email-masked]>
Date: Wed, 3 Feb 2016 14:03:11 +0000

On 2 February 2016 at 21:01, Melinda Shore <[email-masked]> wrote:

> vendors for TLS clients hat are browsers. However, max chain length, which
> was just discussed on the list (11/16-17/15), is an example of metadata
> that needs to be acquired by CAs, just like the public key for a log. The
> text in Section 9 needs to say more about how non-browser log clients are
> expected to acquire this data, or maybe it should say that separate docs
> defining requirements for each of these types of log clients will discuss
> this issue."
>
>
> thoroughly discussed at some point. However, I do not think that 6962-bis
> is the right place for it.
> machine-readable format, nor having a part of the protocol describing how
> it is disseminated.
> 6962-bis that disseminating metadata would justify more efforts from this
> workgroup.
>

If it needs documenting at all, then yes.

>
> Melinda
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Feb 2016 14:40:48 -0500

Ben,

>
>
> On 2 February 2016 at 21:01, Melinda Shore <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi, all:
>
>     "After Prague I agreed that log metadata can be supplied by
>     browser vendors for TLS clients hat are browsers. However, max
>     chain length, which was just discussed on the list (11/16-17/15),
>     is an example of metadata that needs to be acquired by CAs, just
>     like the public key for a log. The text in Section 9 needs to say
>     more about how non-browser log clients are expected to acquire
>     this data, or maybe it should say that separate docs defining
>     requirements for each of these types of log clients will discuss
>     this issue."We continue
>
>
>     I agree that log metadata dissemination is a topic that should be
>     more thoroughly discussed at some point. However, I do not think
>     that 6962-bis is the right place for it.
>     Steve has a very valid point about metadata not being specified in
>     a machine-readable format, nor having a part of the protocol
>     describing how it is disseminated.
>     The requirements for metadata dissemination are very different for
>     each type of client.
>     Disseminating metadata reliably is a protocol in itself, which
>     (once the requirements are clear) deserve its own design.
>     My suggestion is to punt the discussion until after 6962-bis is
>     out. Presumably then there would be enough different clients
>     implementing 6962-bis that disseminating metadata would justify
>     more efforts from this workgroup.
>
We continue to have dramatically different views on what needs to be 
specified in
one or more RFCs so that a standard is well-specified. This is yet 
another example
of our different views. If 6962-bis wants to be viewed as a spec for CT, 
not just for
the CT log, then this is another example of a gap in the spec.

Steve