[cabfpub] Upcoming changes to Google Chrome's certificatehandling
Ben Laurie
benl at google.com
Wed Nov 13 14:12:39 UTC 2013
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.
More information about the Public
mailing list