[cabfpub] Upcoming changes to Google Chrome's certificatehandling

[Ben Laurie]

On 12 November 2013 19:51, Phillip Hallam-Baker <philliph at comodo.com> wrote:
> The reason I object to the term 'fork' is that in the open source community
> forking a distribution is completely legitimate. In fact the ability to fork
> is one of the definitions of being open. I gave up on Java after Sun sued
> Microsoft for attempting to fork. Whatever the rights and wrongs of that
> case were, I was not going to invest in any system without the option to
> fork if I don't like the future direction.

But after a fork, you can't claim that it is the original
distribution. The same is true for CT logs: you can copy a log, but as
soon as your copy diverges, it is not the original.

Anyway, I'm by no means wedded to the word.

> I think there are two attacks that you are covering with 'fork'
>
> Misrepresentation: The log maintainer asserts that two incompatible values
> are the current state of the log.
>
> Impersonation: An unrelated party purports that an incompatible value is the
> current state of the log.
>
>
> Impersonation is easy to defeat, the maintainer just signs the current state
> of the log.

That is already in the protocol, and is not what I am trying to cover
with "fork".

> To prevent misrepresentation the maintainer has to be on record attesting to
> the current state of the log and that has to be done in such a way that the
> perfidy is transparent. The obvious way to do that in a single stream log is
> to require the maintainer to checkpoint their log signatures from time to
> time.

And, indeed, so is this and is what I am trying to cover with "fork".

> I can't keep bit level context on CT right now. There is too much else on my
> stack. I will however be going into it in bit level detail in the near
> future when I look to see if I can reuse any of the data formats and/or
> structures.