Subject: Re: [Trans] Looking for feedback on open issue

From: Ben Laurie <[email-masked]>
Date: Mon, 7 Mar 2016 13:51:10 +0000

On 29 February 2016 at 19:40, Stephen Kent <[email-masked]> wrote:
> Ben,
>
>
>
> On 2 February 2016 at 21:01, Melinda Shore <[email-masked]> wrote:
>>
>> 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."We continue
>>
>>
>> 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?
>
>
> If it needs documenting at all, then yes.
>
> 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.

My point is we seem to be getting along just fine with ad hoc
dissemination of metadata so far, and I don't think we have enough
experience of the needs of clients in general to start inventing more
formal mechanisms. I notice that plenty of the 'net seems to work just
fine without nailing down such questions: e.g. what is the mechanism
for disseminating metadata about DNS caching resolvers, as used by
almost all clients?

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2016 17:58:13 -0500

Ben,

...
> for disseminating metadata about DNS caching resolvers, as used by

Ad hoc may be working now, but if CT wants to claim that it can scale
to accommodate lots of logs and monitors, including self-monitors, then
there needs to be a description of how this will work.

Not sure I understand your comment about DNS; DHCP is usually used to
acquire the address of the nearest DNS server. DHCP was developed because we
lacked a standard way to acquire this data and the ad hoc mechanisms
didn't scale well.

Steve

---

From: Eran Messeri <[email-masked]>
Date: Mon, 14 Mar 2016 12:24:10 +0000

> there needs to be a description of how this will work.
One way to view this is that ad-hoc specification of log metadata is enough
right now, as CT scales we will need to specify a way to disseminate
metadata - so rfc6962-bis should not be blocked on specifying a protocol
for metadata dissemination.

Note that there is indeed an ad-hoc way to disseminate log metadata, in
http://www.certificate-transparency.org/known-logs, which seems to satisfy
the needs of current clients/monitors - at least I haven't heard anyone
complain about its inadequacy.

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