Subject: [Trans] Further comments on RFC 6962

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Mar 2014 16:58:51 -0400

Following on from my last one that went out early...

2) The transactions add-chain and add-pre-chain only differ in the type of
the data being exchanged. It would be more general to change the signature
of the request message so that it had an explicit 'data type'

3) Shouldn't it be possible for a service to manage multiple logs? I would
think this particularly important in the case of a retrieve-only log which
is serving multiple logs. But the same point can be made about the add
operation.

4) sha256_root_hash.

Really? This should be an object that has an algorithm/data pair. Encoding
the algorithm into the tag is going to make algorithm agility hard.

5) 'in decimal'

This phrase crops up repeatedly and I don't think it means what is
intended. All JSON integers are encoded in base 10. Using the term 'in
decimal' is confusing as it is distinct from 'as a decimal'

Integer    42       // An integer value in base ten
Decimal   3.14    // A decimal fraction

6) The tree_size of the first tree, in decimal.

In this context, tree_length would probably be easier to see the context.

7) https://<log server>/ct/v1/get-sth-consistency does not specify if the
first and second tree_size identifiers are ordered or not.

It is likely to result in problems if servers assume first > second or
first < second. Either an order should be specified or there should be an
explicit statement that it does not matter.

8) 0-based index

Not clear to me from the reference section if this is a byte count or an
object count. It should not be necessary to hunt through the spec to find
out which.

-- 
Website: http://hallambaker.com/

---

From: Rob Stradling <[email-masked]>
Date: Tue, 11 Mar 2014 12:34:35 +0000

> Following on from my last one that went out early...
<snip>
> 3) Shouldn't it be possible for a service to manage multiple logs? I
> would think this particularly important in the case of a retrieve-only
> log which is serving multiple logs. But the same point can be made about
> the add operation.

https://<log server>/ct/v1/add-chain

Phill, are you assuming that "<log server>" can't have a "/" in it?  If 
so, that's an invalid assumption.

The values of "<log server>" for the 2 CT Logs that Google are currently 
operating are "ct.googleapis.com/pilot" and "ct.googleapis.com/aviator".

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 11 Mar 2014 08:40:44 -0400

> operating are "ct.googleapis.com/pilot" and "ct.googleapis.com/aviator".

Problem with that approach is that it means that each log deployment
requires server admin to create the distribution point and isn't compatible
with the .well-known convention.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 11 Mar 2014 12:57:02 +0000

On 11/03/14 12:40, Phillip Hallam-Baker wrote:
<snip>
>     Phill, are you assuming that "<log server>" can't have a "/" in it?
>       If so, that's an invalid assumption.
>
>     The values of "<log server>" for the 2 CT Logs that Google are
>     currently operating are "ct.googleapis.com/pilot" and
>     "ct.googleapis.com/aviator".
>
>
> requires server admin to create the distribution point and isn't
> compatible with the .well-known convention.

https://tools.ietf.org/html/rfc5785#section-1.1 says...
   "Well-Known URIs...are designed to facilitate
    discovery of information on a site when it isn't practical to use
    other mechanisms;"

TLS Clients such as Chrome are going to embed lists of the URIs of the 
CT Logs that they trust.  "Discovery" of CT Logs is not a requirement. 
In other words, it _is_ practical to use other mechanisms.

Do you think log discovery will be needed for some other potential 
use-case(s) for public notary transparency (that this WG might one day 
be re-chartered to tackle)?

---

From: Ben Laurie <[email-masked]>
Date: Tue, 11 Mar 2014 15:46:29 +0000

Since a 6962-bis already exists
(https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/) it
would be better to comment on that. But I think all these comments
apply anyway.

> the algorithm into the tag is going to make algorithm agility hard.

I agree about the name. Not sure I agree about agility. We don't think
a log can change algorithm partway through - at least, we don't think
we want to specify how.

If you want a new algorithm, you start a new log.

> 5) 'in decimal'
>
> This phrase crops up repeatedly and I don't think it means what is intended.
> All JSON integers are encoded in base 10. Using the term 'in decimal' is
> confusing as it is distinct from 'as a decimal'
>

Fair enough, since we refer to JSON, we could just not say anything
about number encodings - presumably we should instead say "integer".

> It is likely to result in problems if servers assume first > second or first
> < second. Either an order should be specified or there should be an explicit
> statement that it does not matter.

OK.

> object count. It should not be necessary to hunt through the spec to find

I don't see how a byte count could make any sense, but OK.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 11 Mar 2014 11:52:03 -0400

> If you want a new algorithm, you start a new log.

But the digest algorithm has to be specified somewhere. Or how does the
client discover what it is?

---

From: Ben Laurie <[email-masked]>
Date: Tue, 11 Mar 2014 15:55:41 +0000

> client discover what it is?

The acceptable logs and their algorithms are built into the client -
alternatively, they can retrieve a list of log metadata (keys,
algorithms, MMDs, etc). We will be distributing such a list
corresponding to what Chrome accepts.

---

From: Eran Messeri <[email-masked]>
Date: Wed, 12 Mar 2014 15:08:26 +0000

Created ticket 11 <http://trac.tools.ietf.org/wg/trans/trac/ticket/11> to
track get-sth-consistency parameters order.