[147159] in cryptography@c2.net mail archive
Re: [Cryptography] End to end
daemon@ATHENA.MIT.EDU (Ben Laurie)
Mon Sep 16 17:39:37 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAMm+Lwhn=JDoUoPn_SBLgOA5f6sxcRs_SFit3CrOS97wPk9EQg@mail.gmail.com>
Date: Mon, 16 Sep 2013 20:14:54 +0100
From: Ben Laurie <ben@links.org>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============4915339404643894772==
Content-Type: multipart/alternative; boundary=047d7b6d8afcf3468d04e6850464
--047d7b6d8afcf3468d04e6850464
Content-Type: text/plain; charset=ISO-8859-1
On 16 September 2013 18:49, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> To me the important thing about transparency is that it is possible for
> anyone to audit the key signing process from publicly available
> information. Doing the audit at the relying party end prior to every
> reliance seems a lower priority.
>
This is a fair point, and we could certainly add on to CT a capability to
post-check the presence of a pre-CT certificate in a log.
> In particular, there are some type of audit that I don't think it is
> feasible to do in the endpoint. The validity of a CT audit is only as good
> as your newest notary timestamp value. It is really hard to guarantee that
> the endpoint is not being spoofed by a PRISM capable adversary without
> going to techniques like quorate checking which I think are completely
> practical in a specialized tracker but impractical to do in an iPhone or
> any other device likely to spend much time turned off or otherwise
> disconnected from the network.
>
I think the important point is that even infrequently connected devices can
_eventually_ reveal the subterfuge.
--047d7b6d8afcf3468d04e6850464
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 16 September 2013 18:49, Phillip Hallam-Baker <span dir=3D"ltr"><<a h=
ref=3D"mailto:hallam@gmail.com" target=3D"_blank">hallam@gmail.com</a>><=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>To me the important thing about transpa=
rency is that it is possible for anyone to audit the key signing process fr=
om publicly available information. Doing the audit at the relying party end=
prior to every reliance seems a lower priority.=A0</div>
</blockquote><div><br></div><div>This is a fair point, and we could certain=
ly add on to CT a capability to post-check the presence of a pre-CT certifi=
cate in a log.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>In particular, there are some type of audit that I don&=
#39;t think it is feasible to do in the endpoint. The validity of a CT audi=
t is only as good as your newest notary timestamp value. It is really hard =
to guarantee that the endpoint is not being spoofed by a PRISM capable adve=
rsary without going to techniques like quorate checking which I think are c=
ompletely practical in a specialized tracker but impractical to do in an iP=
hone or any other device likely to spend much time turned off or otherwise =
disconnected from the network.</div>
</blockquote><div><br></div><div>I think the important point is that even i=
nfrequently connected devices can _eventually_ reveal the subterfuge.=A0</d=
iv></div><br><br></div></div>
--047d7b6d8afcf3468d04e6850464--
--===============4915339404643894772==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============4915339404643894772==--
