Re: [therightkey] Revised Draft Charter for Transparency WG

[Stephen Farrell <[e-mail]>]

Collected suggestions, in order sent to me:

1. Append-only Transparency Logs (trans)
2. PUblic Notary Transparency (punt)
3. Public Key Transparency (trans)
4. Transparency for public key binding (trans)
5. warnlog
6. canarielog
7. whistle-ledger
8. detection-ledger

My order or preference would be #3, then #2, then #1 and
otherwise don't care.

If nobody objects (Do you really want to object? Is it
important really? :-) I'll let the IESG pick one of those
with that suggested ordering.

Cheers,
S.

On 01/14/2014 11:12 PM, Stephen Farrell wrote:
> 
> 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
>>
>>
> _______________________________________________
> therightkey mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/therightkey
> 
>