Ok. But that's at least one additional round trip, right? Is it more realistic to say that the protocol fails if ALL of the CA and every timestamp relied upon is untrustworthy?
All the best. Tim. > On Jan 7, 2014, at 12:07 PM, "Ben Laurie" <b...@google.com> wrote: > >> On 7 January 2014 16:37, Tim Moses <tim.mo...@entrust.com> 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" <b...@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 _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
