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" <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
