Re: [therightkey] Revised Draft Charter for Transparency WG

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?

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.

Maybe I missed something.

All the best. Tim.

> On Jan 7, 2014, at 11:14 AM, "Ben Laurie" <benl@google.com> 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
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey