Re: [therightkey] Revised Draft Charter for Transparency WG

[Phillip Hallam-Baker <[e-mail]>]

Why limit it to public keys? Security Policy statements can be notarized in
the same manner and this has real benefits.


Trust Infrastructure Transparency  or Transparent Infrastructure for Trust

TIT either way.


On Mon, Jan 20, 2014 at 7:35 PM, Stephen Farrell
<[e-mail]>wrote;wrote:

>
> 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
> >
> >
> _______________________________________________
> therightkey mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/therightkey
>



-- 
Website: http://hallambaker.com/