On 24 January 2014 18:29, Paul Lambert <p...@marvell.com> wrote: > > Comments on draft Public Notary Transparency: > > - ŒTransparent Public Notary¹ would be better for a group name > and match the new charter more closely (versus original charter > was making an existing service Transparent) > > - charter is too public key focused. A Merkle Hash Tree can support > a notary-like facility for any information that can be hashed > Suggest changing paragraph two to use current examples but > add a non-public key example and down-play public keys as just an > example > > - Is ŒPublic¹ necessary in the title and as a goal? > A ŒTransparent Notary¹ could be public or private. Enterprise or > private > applications could readily benefit from notary functions. > suggest removing public from title and add a sentence in scope > describing public an private applications.
The focus on public keys is deliberate. As the second work item says, WG would re-charter for transparency of other things. This is because it turns out that whilst there's clearly a general mechanism, there's a lot of details that may change depending on what exactly is being logged. > > - word-smithing for readability would be beneficial. Especially > the introduction to better capture the groups new focus. > > Paul > > > > > > On 1/24/14, 9:53 AM, "The IESG" <iesg-secret...@ietf.org> wrote: > >>A new IETF working group has been proposed in the Security Area. The IESG >>has not made any determination yet. The following draft charter was >>submitted, and is provided for informational purposes only. Please send >>your comments to the IESG mailing list (iesg at ietf.org) by 2014-02-03. >> >>Public Notary Transparency (trans) >>------------------------------------------------ >>Current Status: Proposed WG >> >>Assigned Area Director: >> Stephen Farrell <stephen.farr...@cs.tcd.ie> >> >>Mailing list >> Address: therightkey@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/therightkey >> Archive: http://www.ietf.org/mail-archive/web/therightkey/ >> >>Charter: >> >>Mitigating web site certificate mis-issuance is the initial problem of >>interest for this working group. Certificate Transparency (CT, >>RFC6962) allows such mis-issuance to be detected in interesting and >>useful cases, for example by an auditor acting for the web site, or >>one acting to check general CA behaviour. The working group will >>produce a standards-track version of the experimental RFC 6962 >>for HTTP over TLS, reflecting implementation and deployment >>experience since that specification was completed. >> >>Many Internet protocols for example, SMTPS, IPsec, DNSSEC, >>OpenPGP and HTTPS, require a mapping between some kind of >>identifier and some kind of public key. These protocols rely >>on either ad-hoc mappings, (as in a web of trust), or on authorities >>(such as CAs) that 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 can help to ameliorate these >>problems by making it possible to discover errors quickly, so that >>other mechanisms can be applied to rectify them. 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, RFC 6962 says: "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." >> >>These logs can potentially 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. >> >>While the privacy issues related to use of RFC6962 for public >>web sites are minimal, the working group will consider privacy >>as it might impact on uses of CT e.g. within enterprises or >>for other uses of logs. >> >>Work items: >> >>- Publish an update to RFC 6962 as a standards-track mechanism to >>apply verifiable logs to HTTP over TLS. As DANE (RFC6698) provides an >>alternative keying infrastructure to that used in the current web PKI, >>the working group should consider appropriate client behavior in the >>presence of both DANE-based keying and current web PKI when >>standardising CT. >> >>- Discuss mechanisms and techniques that allow cryptographically >>verifiable logs to be deployed to improve the security of protocols >>other than HTTP over TLS, for example SMTP/TLS or software >>distribution. Where such mechanisms appear sufficiently useful, >>the WG will re-charter to add relevant new work items. Should >>no such items be chartered the WG will close when documents >>associated with the first work item are complete. >> >> >> >>Milestones: >> >>TBD >>_______________________________________________ >>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 _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
