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" <b...@google.com> wrote: > >> On 7 January 2014 17:26, Tim Moses <tim.mo...@entrust.com> 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" <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
