* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Trans Status Pages

Public Notary Transparency (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2014-Jun-10 —  
Chairs
 
 


2019-03-27 charter

Public Notary Transparency (trans)
----------------------------------

 Charter

 Current Status: Active

 Chairs:
     Melinda Shore <melinda.shore@gmail.com>
     Paul Wouters <paul@nohats.ca>

 Security Area Directors:
     Roman Danyliw <rdd@cert.org>
     Benjamin Kaduk <kaduk@mit.edu>

 Security Area Advisor:
     Roman Danyliw <rdd@cert.org>

 Mailing Lists:
     General Discussion: trans@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/trans
     Archive:            https://mailarchive.ietf.org/arch/browse/trans/

Description of Working Group:

  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.



Goals and Milestones:
  Dec 2015 - 6962bis to IESG
  Jul 2016 - Threat analysis to working group last call
  Oct 2016 - Gossip draft to working group last call


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/trans/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -