Subject: [Trans] Gossip URL version

From: Kurt Roeckx <[email-masked]>
Date: Wed, 15 Mar 2017 20:58:39 +0100

The -04 draft currently has URLs like this in it:
https://<domain>/.well-known/ct-gossip/v1/sct-feedback

But the it's indicating that it's about rfc6962-bis, which changed
things to /v2 URLs. Is the v1 about the gossip protocol
version only, or are the URLs supposed to be v2?

Kurt

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 15 Mar 2017 21:44:46 +0100

Kurt Roeckx <[email-masked]> wrote

> version only, or are the URLs supposed to be v2?

The version number in the gossip well-known URL's indicates the version
of the gossip protocol.

The gossip protocol should work for both CT v1 and CT v2. If it doesn't,
we should fix that. If that's not possible, let's define a gossip
protocol version two.

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 15 Mar 2017 14:48:32 -0700

On Wed, 15 Mar 2017 21:44:46 +0100
Linus Nordberg <[email-masked]> wrote:

> The gossip protocol should work for both CT v1 and CT v2. If it
> doesn't, we should fix that. If that's not possible, let's define a
> gossip protocol version two.

The sth-pollination protocol defined in draft-ietf-trans-gossip-04
could work with v1 STHs, but section 8.2.4 says it contains an
array of v2 STHs:

"sths - an array of 0 or more fresh SignedTreeHeads as defined in
[RFC-6962-BIS-09] Section 3.6.1."

For this reason, I've been implementing draft-ietf-trans-gossip-00,
which uses v1 STHs and uses the URL .well-known/ct/v1/sth-pollination.

Should I be using the URL defined in -04 instead?

Incidentally, -04 is not entirely clear how STHs are represented.
RFC6962-bis no longer defines a JSON representation for STHs.  Instead
STHs are returned in JSON responses as base64-encoded SignedTreeHeads.
Does this mean that the sth-pollination protocol should use a JSON
array of strings, possibly mixed with JSON objects for v1 STHs?

Regards,
Andrew

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 15 Mar 2017 22:58:33 +0100

> which uses v1 STHs and uses the URL .well-known/ct/v1/sth-pollination.

That one also has an sth_version as one of the fields, so I assume
it works for both versions.

But if I look at other things, it's not obvious to me if it works
or not.

Kurt

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 16 Mar 2017 13:45:28 +0100

Andrew Ayer <[email-masked]> wrote

> [RFC-6962-BIS-09] Section 3.6.1."

Hmm. It seems like CT v1 has been ignored in the transition to 6962-bis.

> array of strings, possibly mixed with JSON objects for v1 STHs?

I don't know right now. Suggestions welcome! Well, I guess your question
is a suggestion. Analysis welcome, as well as proposed text of course. :)

Also, very happy to see implementation under way!

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 16 Mar 2017 08:55:03 -0700

On Thu, 16 Mar 2017 13:45:28 +0100

> Hmm. It seems like CT v1 has been ignored in the transition to

It seems very desirable to add explicit CT v1 support, as it will probably
be quite a while before CT v2 fully replaces CT v1, and there is a need
for gossip in the v1 ecosystem in the meantime.

I don't think the changes would be significant, and I'd be willing to
make a pass through the draft to add text where necessary.  However,
the gossip draft has already completed WGLC.  What kind of changes can
be made at this point?

> > RFC6962-bis no longer defines a JSON representation for STHs.
> > Instead STHs are returned in JSON responses as base64-encoded
> > SignedTreeHeads. Does this mean that the sth-pollination protocol
> > should use a JSON array of strings, possibly mixed with JSON
> > objects for v1 STHs?
> 
> I don't know right now. Suggestions welcome! Well, I guess your
> question is a suggestion. Analysis welcome, as well as proposed text
> of course. :)

Yes, you can take my question as a suggestion.  The advantage is
that it avoids creating redundant formats for STHs and allows code
reuse for parsing STHs.  The disadvantage is that mixing objects and
strings in the same array might make parsing the JSON awkward with some
libraries/languages.

> Also, very happy to see implementation under way!

I should have a report to make to trans soon :-)

Regards,
Andrew