Subject: Re: [therightkey] WG Review: Public Notary Transparency (trans)

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Jan 2014 15:33:18 -0500

I support the creation of this WG.

I also prefer 'Transparent Public Notary'

Putting the adjective after the noun suggests that the emphasis is on
making notaries transparent rather than a new notary protocol that is
transparent.

On Fri, Jan 24, 2014 at 3:12 PM, Phillip Hallam-Baker <[email-masked]>wrote:

> I support the creation of this WG.
>
> I also prefer 'Transparent Public Notary'
>
> Putting the adjective after the noun suggests that the emphasis is on
> making notaries transparent rather than a new notary protocol that is
> transparent.
>
>
>
> On Fri, Jan 24, 2014 at 12:53 PM, The IESG <[email-masked]>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 <[email-masked]>
>>
>> Mailing list
>>   Address: [email-masked]
>>   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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/therightkey
>>
>
>
>
> --
> Website: http://hallambaker.com/
>

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