Subject: [Trans] Some comments on the Web Service part

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Mar 2014 18:41:21 +0000

1) This is a specified service, shouldn't it be registered as a .well-known
service?

http://example.com/.well-known/ct/1

This means that the CT log can play nice with other services on the same
server.

(obviously have to replace ct with what we register)

2) The command should be present in the JSON request.

HTTP request lines are hard to protect with message level authentication.
Putting the command in the content means that it is covered independently.

Reason this matters is that the request line and headers tend to get
'battered' as they pass through enterprise scale web traffic management
systems. The same is true of TLS authentication that tends to get stripped
out at the front door by some sort of message router.

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

---

From: Eran Messeri <[email-masked]>
Date: Thu, 6 Mar 2014 11:29:50 +0000

On Wed, Mar 5, 2014 at 6:41 PM, Phillip Hallam-Baker <[email-masked]>wrote:

> 1) This is a specified service, shouldn't it be registered as a
> .well-known service?
>
Could you please point to the standard specifying how these well-known
services are defined?
Regardless, it seems to be independent of the commands specification that a
CT log must conform to.
The Google-managed logs have an address that conforms with the rest of the
HTTP APIs Google offers. We technically could offer
https://ct.googleapis.com/.well-known/..., if it provides strong benefit.
Since we expect few, well-known logs, I can't see the benefit in
registering it as well-known service since very few domains are expected to
offer it (i.e. there is no benefit it making it easily discoverable).

> Do you mean this as an addition or instead of specifying the command in
the request line?
Is there a specific web traffic management system that you know/expect to
cause problem?

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 6 Mar 2014 13:12:41 +0000

> Could you please point to the standard specifying how these well-known

https://tools.ietf.org/html/rfc5785

>  Regardless, it seems to be independent of the commands specification
> that a CT log must conform to.
>

It is a standards nit.

> https://ct.googleapis.com/.well-known/..., if it provides strong benefit.

The benefit here is that we try to get consistency across IETF standards.
And since this is layering over HTTP it is important to make it layer the
same way that other specs layer.

> offer it (i.e. there is no benefit it making it easily discoverable)
>

Expectations of low use is not a good reason not to conform to an
established practice.

> Is there a specific web traffic management system that you know/expect to

In addition to the HTTP request line.

Some people are going to want to be able to separate out command handlers
by command. The ADD commands cause a state change to the database, the
request commands don't. So it is worthwhile making it easy to route the
command to the right processor.

This is a very similar argument to the reason why SMTP FROM (RFC821) is not
the same as RFC822 From: