Is anyone relying on the log list schema?

[Eran Messeri]

I'd like to know if planned changes to the JSON schema [1] of the log list published on the CT website would break anybody's code.

Right now the schema includes, in addition to log metadata, a list of operators and the logs they operate.

This is inaccurate as in practice the information about operators is not verified in any way - all we know is whether Google operates a particular log or not.

I'd like to change the schema to that effect - only indicate whether a log is operated by Google.

Right now the only code I'm aware of that parses this schema [2] is in the CT GitHub repository. 

Feedback, particularly about potential breakages, is welcome.

[1] - http://www.certificate-transparency.org/known-logs/log_list_schema.json

[2] - https://github.com/google/certificate-transparency/blob/master/python/utilities/log_list/print_log_list.py

Eran

[Fabrice Gautier]

Sorry for the very late to reply to this, but I just noticed it and I do have code that parse the known log JSON list and would break - although I do not fetch the list automatically so the impact would not be terrible as I would noticed when I manually import a new list.

As far as having the list of operators, it seems it's fairly important to have some accuracy in who control the logs since Chrome rules for CT qualification do have a notion of "independent logs". Currently only Google operates more than one log, but if others were starting their second log, I think having the operator properly identified would be good.

I guess your point is that it would be easy for a single entity to setup several logs and pretend they are controlled by different entities ?

 

[Eran Messeri]

Correct - right now log operators are not required to authenticate in any way. The only authentication done is when they file inclusion requests on the Chromium bug tracker: Some operators use email addresses on their domain while others file using gmail.com accounts.

So the fundamental problem is that the log list contains information I cannot vouch is correct - and then the question is, why publish it at all, or how can it be made very clear that this information is not vetted.

Note the independence requirement in Chrome has been dropped in favour of Google-operated / non-Google operated distinction.

 

--
You received this message because you are subscribed to the Google Groups "certificate-transparency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to certificate-transp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Fabrice Gautier]

On Monday, January 18, 2016 at 3:03:57 AM UTC-8, Eran Messeri wrote:

On Sun, Jan 17, 2016 at 7:25 AM, Fabrice Gautier <fabrice...@gmail.com> wrote:

On Friday, October 9, 2015 at 2:29:26 AM UTC-7, Eran Messeri wrote:

I'd like to know if planned changes to the JSON schema [1] of the log list published on the CT website would break anybody's code.

Right now the schema includes, in addition to log metadata, a list of operators and the logs they operate.

This is inaccurate as in practice the information about operators is not verified in any way - all we know is whether Google operates a particular log or not.

I'd like to change the schema to that effect - only indicate whether a log is operated by Google.

Right now the only code I'm aware of that parses this schema [2] is in the CT GitHub repository. 

Feedback, particularly about potential breakages, is welcome.

[1] - http://www.certificate-transparency.org/known-logs/log_list_schema.json

[2] - https://github.com/google/certificate-transparency/blob/master/python/utilities/log_list/print_log_list.py

Eran

Sorry for the very late to reply to this, but I just noticed it and I do have code that parse the known log JSON list and would break - although I do not fetch the list automatically so the impact would not be terrible as I would noticed when I manually import a new list.

As far as having the list of operators, it seems it's fairly important to have some accuracy in who control the logs since Chrome rules for CT qualification do have a notion of "independent logs". Currently only Google operates more than one log, but if others were starting their second log, I think having the operator properly identified would be good.

I guess your point is that it would be easy for a single entity to setup several logs and pretend they are controlled by different entities ?

Correct - right now log operators are not required to authenticate in any way. The only authentication done is when they file inclusion requests on the Chromium bug tracker: Some operators use email addresses on their domain while others file using gmail.com accounts.

So the fundamental problem is that the log list contains information I cannot vouch is correct - and then the question is, why publish it at all, or how can it be made very clear that this information is not vetted.

Note the independence requirement in Chrome has been dropped in favour of Google-operated / non-Google operated distinction.

Ah, yes indeed..

This raise a couple more questions:

1) What is the rationale for distinguishing between Google vs non-Google logs for Chrome?  And what was the rationale previously for wanting to distinguish independent logs ?

2) For other TLS clients (non Google), what is the point of trying to distinguish between Google vs non-Google log in the way they decide CT qualification? I mean it would be trivial for Google to include a Google controlled log in that list and not report it as such. So in the same way Google can't vet the independence of non-Google logs, other clients can't really vet logs independence from Google.

-- Fabrice

[Eran Messeri]

On Tue, Jan 19, 2016 at 7:29 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

On Monday, January 18, 2016 at 3:03:57 AM UTC-8, Eran Messeri wrote:

On Sun, Jan 17, 2016 at 7:25 AM, Fabrice Gautier <fabrice...@gmail.com> wrote:

On Friday, October 9, 2015 at 2:29:26 AM UTC-7, Eran Messeri wrote:

I'd like to know if planned changes to the JSON schema [1] of the log list published on the CT website would break anybody's code.

Right now the schema includes, in addition to log metadata, a list of operators and the logs they operate.

This is inaccurate as in practice the information about operators is not verified in any way - all we know is whether Google operates a particular log or not.

I'd like to change the schema to that effect - only indicate whether a log is operated by Google.

Right now the only code I'm aware of that parses this schema [2] is in the CT GitHub repository. 

Feedback, particularly about potential breakages, is welcome.

[1] - http://www.certificate-transparency.org/known-logs/log_list_schema.json

[2] - https://github.com/google/certificate-transparency/blob/master/python/utilities/log_list/print_log_list.py

Eran

Sorry for the very late to reply to this, but I just noticed it and I do have code that parse the known log JSON list and would break - although I do not fetch the list automatically so the impact would not be terrible as I would noticed when I manually import a new list.

As far as having the list of operators, it seems it's fairly important to have some accuracy in who control the logs since Chrome rules for CT qualification do have a notion of "independent logs". Currently only Google operates more than one log, but if others were starting their second log, I think having the operator properly identified would be good.

I guess your point is that it would be easy for a single entity to setup several logs and pretend they are controlled by different entities ?

Correct - right now log operators are not required to authenticate in any way. The only authentication done is when they file inclusion requests on the Chromium bug tracker: Some operators use email addresses on their domain while others file using gmail.com accounts.

So the fundamental problem is that the log list contains information I cannot vouch is correct - and then the question is, why publish it at all, or how can it be made very clear that this information is not vetted.

Note the independence requirement in Chrome has been dropped in favour of Google-operated / non-Google operated distinction.

Ah, yes indeed..

This raise a couple more questions:

1) What is the rationale for distinguishing between Google vs non-Google logs for Chrome?  And what was the rationale previously for wanting to distinguish independent logs ?

 In short, that was to reduce the risk that removing  all logs of a single operator from Chrome would make certificates non compliant with the CT requirement in Chrome. You can read the full discussion on the Certificate Transparency Policy Chromium group (https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy).

2) For other TLS clients (non Google), what is the point of trying to distinguish between Google vs non-Google log in the way they decide CT qualification? I mean it would be trivial for Google to include a Google controlled log in that list and not report it as such. So in the same way Google can't vet the independence of non-Google logs, other clients can't really vet logs independence from Google.

That list is not meant to be authoritative for all TLS clients - this is the list used for TLS clients from Google, that we monitor and feel confident to include as they show compliance with the spec and high availability.

I would expect other TLS client vendors to form their own opinions on which logs are worthy of inclusion in their products.

-- Fabrice