Certificate Transparency (CT) System Architecture
draft-kent-trans-architecture-05

Document Type Active Internet-Draft (individual)
Last updated 2016-12-13
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Public Notary Transparency                                       S. Kent
Internet Draft                                             D. Mandelberg
Intended status: Standards Track                                  K. Seo
Expires: June 2017                                      BBN Technologies
                                                       December 13, 2016

             Certificate Transparency (CT) System Architecture
                   draft-kent-trans-architecture-05.txt

Abstract

   This document describes the architecture for Certificate Transparency
   (CT) focusing on the Web PKI context. It defines the goals of CT and
   the elements that comprise the CT system. It also describes the major
   features of these elements. Other documents, cited in the References,
   establish requirements for these CT system elements and describe
   their operation in greater detail.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on June 13, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.

Kent, et al.         Expires February 5, 2017                  [Page 1]

Internet-Draft          CT System Architecture           December 2016

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1. Introduction...................................................2
      1.1. Requirements Language.....................................5
   2. Beneficiaries of CT............................................6
   3. The Elements of the CT Architecture............................7
      3.1. Logs.....................................................10
      3.2. CT-aware Certification Authorities (CAs).................11
      3.3. Monitors.................................................12
      3.4. CT-aware Subjects (TLS web servers)......................13
      3.5. CT-aware TLS clients (web browsers)......................14
      3.6. Auditors.................................................15
   4. Security Considerations.......................................15
   5. IANA Considerations...........................................16
   6. References....................................................16
      6.1. Normative References.....................................16
      6.2. Informative References...................................17
   7. Acknowledgments...............................................17

1. Introduction

   Certificate transparency (CT) is a set of mechanisms designed to
   deter, detect, and facilitate remediation of certificate mis-issuance
   (as defined below). CT deters mis-issuance by encouraging CAs to
   publish the certificates that they issue in a set of publically-
   accessible logs. Each log uses a Merkle tree design to ensure that it
   is an append-only database, and the log entries are digitally signed
   by the log operator. Monitoring of logs detects mis-issuance.
   Remediation of mis-issuance is effected via certificate revocation.

   In the context of CT, the term mis-issuance refers to violations of
   either semantic or syntactic constraints associated with certificates
   [draft-trans-threat-analysis]. The fundamental semantic constraint
   for a (Web PKI) certificate is that it was issued to an entity that
   is authorized to represent the Subject name in the certificate. If
   any Subject Alternative Names (SANs) are present in the certificate,
   the entity also must be authorized to represent them. (It is also
   assumed that the entity requested the certificate from the CA that

Kent, et al.         Expires February 5, 2017                  [Page 2]

Internet-Draft          CT System Architecture           December 2016

   issued it.) Throughout the remainder of this document we refer to a
Show full document text