Re: [therightkey] Comments on -> Re: WG Review: Public Notary Transparency (trans)

[Ben Laurie <[e-mail]>]

On 24 January 2014 18:29, Paul Lambert <[e-mail]> 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" <[e-mail]> 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 <[e-mail]>
>>
>>Mailing list
>>  Address: [e-mail]
>>  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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/therightkey
>
> _______________________________________________
> therightkey mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/therightkey