Re: [therightkey] Revised Draft Charter for Transparency WG

[Stephen Farrell <[e-mail]>]

First and predictable comment: "Transparency WG" is too generic.

Best crappy suggestion I have is "Append-only Transparency Logs"
but to keep the trans abbreviation.

Better suggestions welcome. (Again offlist is fine since its
mostly bikeshedding about which we only care just enough to
irritate ourselves;-)

S.

On 01/14/2014 06:02 PM, Stephen Farrell wrote:
> 
> Thanks Ben, Paul.
> 
> I've kicked off the chartering process. [1]
> 
> All going smoothly (which it doesn't always;-) this
> could be a WG at IETF-89.
> 
> I've put in a placeholder BoF request so a slot is
> assigned for that when we schedule the meeting.
> (That's [2] which you can ignore unless someone
> asks why its there.)
> 
> Cheers,
> S.
> 
> [1] https://datatracker.ietf.org/doc/charter-ietf-trans/
> [2] https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Security
> 
> 
> On 01/07/2014 04:35 PM, Paul Hoffman wrote:
>> I support the formation of this WG with basically this charter. However, having footnote in a charter make it harder to read. Having URLs that are not somewhat guaranteed to be available forever (such as those run by the IETF) make the charter unstable. A proposed editorial-only cleanup:
>>
>> 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 can help to ameliorate the problems by making it possible
>> to discover and rectify errors before they can cause harm. 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 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:
>>
>> - Publish an update to RFC 6962 as a standards-track mechanism to apply verifiable logs to
>> HTTP over TLS.
>>
>> - 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.
>>
>> _______________________________________________
>> therightkey mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/therightkey
>>
>>
> _______________________________________________
> therightkey mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/therightkey
> 
>