Re: [therightkey] IESG eval of charter

[Ben Laurie <[e-mail]>]

On 22 January 2014 13:17, Stephen Farrell <[e-mail]> wrote:
>
> Thanks Paul,
>
> I'll hold off on these changes for now as the IESG
> are reading this for tomorrow's telechat but we can
> look at them again after that. Be good to know if
> folks on the list like the changes though. (But
> let's not get into wordsmithing.)

I like that version.

>
> Also - I added the following in response to another
> comment:
>
> "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."
>
> That's at [1] now.
>
> Cheers,
> S.
>
> [1] https://datatracker.ietf.org/doc/charter-ietf-trans/
>
> On 01/22/2014 12:16 AM, Paul Lambert wrote:
>>
>>
>> OHiya,
>>>>
>>>> Getting a number of comments [1] from IESG folks that
>>>> the charter's not so easy to grasp for non CT-aware
>>>> folks.
>>>>
>>>> My current try at fixing that at [2]. Please suggest
>>>> any *necessary* changes by tomorrow if you can. (And
>>>> in OLD/NEW format please, just to be nice to me:-)
>>>
>>> NEW is the first three paragraphs mostly a restructure for readability.
>>
>> Ooops - new is the first 4 paragraphs ending at the ³These logs can Š²
>>
>>>
>>> Paul
>>>
>>> - - - - -
>>>
>>> Cryptographic logs provide a mechanism to publish a list of events that
>>> can be verified for correct ordering and content.  The logs are
>>> append-only and can be efficiently verified by the world at large for
>>> correct log behavior.  Certificate Transparency (CT, RFC6962) logs the
>>> issuance of X.509 certificates.  The CT log enables the detection of
>>> mis-issued certificates providing validation of correct CA operation.  The
>>> working group will produce a standards-track version of the experimental
>>> CT RFC 6962 reflecting implementation and deployment experience since that
>>> specification was completed.
>>>
>>> Many other Internet protocols besides X.509 map public keys to some kind
>>> of identifier and would benefit from a verifiable log These possible
>>> application of a cryptographic log include: SMTPS, IPSec, DNSSEC and
>>> OpenPGP.
>>>
>>> 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 be used
>>> to support these and other protocols to maintain consistent and correct
>>> mappings.  Errors or subversion of the mappings can be detected and
>>> corrected to minimize any adverse impact.
>>>
>>> A cryptographically verifiable log is an append-only log of hashes.  The
>>> hashes can represent more-or-less anything and serve as a unique identify
>>> for any information object.  The log is structured to provide efficient
>>> access and cryptographic evidence of correct log operation. The individual
>>> hashes are linked together using Merkle Trees, which can be used to show
>>> that any particular version of the log is a superset of any particular
>>> previous version. 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.
>>>
>>> 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 and
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Bear in mind that we're developing the charter text
>>>> that will go to IETF review, so this need not be the
>>>> final final thing, e.g. the final wordsmithing polish
>>>> can be done later.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>> [1] https://datatracker.ietf.org/doc/charter-ietf-trans/ballot/
>>>> [2] https://datatracker.ietf.org/doc/charter-ietf-trans/
>>>> _______________________________________________
>>>> 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