Re: [therightkey] Revised Draft Charter for Transparency WG

[Tim Moses <[e-mail]>]

I see. It seems unfortunate that reliance on one or more time stamps is not sufficient, but that the client also has to consult the log.

All the best. Tim.

> On Jan 7, 2014, at 12:40 PM, "Ben Laurie" <[e-mail]> wrote:
> 
>> On 7 January 2014 17:26, Tim Moses <[e-mail]> wrote:
>> Ok.  But that's at least one additional round trip, right?
> 
> It does not need to be done before accepting the certificate. CT is
> designed around responsiveness at the cost of finding out bad things
> happened a little late. But this seems like an acceptable trade-off,
> since a log still can only misbehave once (or for a short period of
> time), which makes the cost of doing so very high.
> 
>> Is it more realistic to say that the protocol fails if ALL of the CA and every timestamp relied upon is untrustworthy?
> 
> I'm not sure what you mean by this, but perhaps the above makes it irrelevant?
> 
>> 
>> All the best. Tim.
>> 
>> 
>>>> On Jan 7, 2014, at 12:07 PM, "Ben Laurie" <[e-mail]> wrote:
>>>> 
>>>> On 7 January 2014 16:37, Tim Moses <[e-mail]> wrote:
>>>> Hi Ben.  Is it explained somewhere how it would be discovered that a log had issued a time stamp for a certificate that it then did not log?
>>> 
>>> RFC 6962, Section 5.4 "Auditor".
>>> 
>>>> According to my understanding, the time stamp would only be distributed within a certificate or OCSP response, and (therefore) its existence would not necessarily be apparent to an auditor.
>>> 
>>> If no-one ever sees the certificate, then whether an SCT was issued or
>>> not is unimportant. This is why recipients of certificates need to at
>>> least audit the certificates they see.
>>> 
>>> In the RFC "auditor" is a role that may be incorporated in other
>>> things. From the RFC: "An auditor might be an integral component of a
>>> TLS client".
>>> 
>>> There may be a better way of explaining this.
>>> 
>>> Possibly something to this effect should've been added to 5.2. I've
>>> added an issue (https://code.google.com/p/certificate-transparency/issues/detail?id=25).
>>> 
>>>> Maybe I missed something.
>>>> 
>>>> All the best. Tim.
>>>> 
>>>>> On Jan 7, 2014, at 11:14 AM, "Ben Laurie" <[e-mail]> wrote:
>>>>> 
>>>>> Problem statement: many Internet protocols require a mapping between
>>>>> some kind of identifier and some kind of key, for example, HTTPS,
>>>>> SMTPS, IPSec, DNSSEC and OpenPGP.
>>>>> 
>>>>> 
>>>>> These protocols rely on either ad-hoc mappings, or on authorities
>>>>> which attest to the mappings.
>>>>> 
>>>>> 
>>>>> History shows that neither of these mechanisms is entirely
>>>>> satisfactory. Ad-hoc mappings are difficult to discover and maintain,
>>>>> and authorities make mistakes or are subverted.
>>>>> 
>>>>> 
>>>>> Cryptographically verifiable logs[1] can help to ameliorate the
>>>>> problems by making it possible to discover and rectify errors before
>>>>> they can cause harm.
>>>>> 
>>>>> 
>>>>> These logs can also assist with other interesting problems, such as
>>>>> how to assure end users that software they are running is, indeed, the
>>>>> software they intend to run.
>>>>> 
>>>>> 
>>>>> Work items: Specify a standards-track mechanism to apply verifiable
>>>>> logs to HTTP/TLS (i.e. RFC 6962-bis).
>>>>> 
>>>>> 
>>>>> Discuss mechanisms and techniques that allow cryptographically
>>>>> verifiable logs to be deployed to improve the security of protocols
>>>>> and software distribution. Where such mechanisms appear sufficiently
>>>>> useful, the WG will re-charter to add relevant new work items.
>>>>> 
>>>>> 
>>>>> [1] A cryptographically verifiable log is an append-only log of hashes
>>>>> of more-or-less anything that  is structured in such a way as to
>>>>> provide efficiently-accessible, cryptographically-supported evidence
>>>>> of correct log behaviour.
>>>>> 
>>>>> 
>>>>> For example, from RFC 6962: “The append-only property of each log is
>>>>> technically achieved using Merkle Trees, which can be used to show
>>>>> that any particular version of the log is a superset of any particular
>>>>> previous version. Likewise, Merkle Trees avoid the need to blindly
>>>>> trust logs: if a log attempts to show different things to different
>>>>> people, this can be efficiently detected by comparing tree roots and
>>>>> consistency proofs. Similarly, other misbehaviors of any log (e.g.,
>>>>> issuing signed timestamps for certificates they then don't log) can be
>>>>> efficiently detected and proved to the world at large.”
>>>>> 
>>>>> 
>>>>> See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf
>>>>> and http://www.links.org/files/RevocationTransparency.pdf for
>>>>> background.
>>>>> _______________________________________________
>>>>> therightkey mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/therightkey