On 7 January 2014 18:04, Tim Moses <tim.mo...@entrust.com> wrote: > 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.
The client audits the log, which is a different thing. To make a TLS connection, the timestamps are sufficient. > > 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
