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

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.

 - 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-secretary@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.farrell@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