Subject: [Trans] I-D Action: draft-ietf-trans-rfc6962-bis-21.txt

From: [email-masked]
Date: Thu, 24 Nov 2016 04:33:57 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public Notary Transparency  of the IETF.

        Title           : Certificate Transparency
        Authors         : Ben Laurie
                          Adam Langley
                          Emilia Kasper
                          Eran Messeri
                          Rob Stradling
	Filename        : draft-ietf-trans-rfc6962-bis-21.txt
	Pages           : 50
	Date            : 2016-11-24

Abstract:
   This document describes a protocol for publicly logging the existence
   of Transport Layer Security (TLS) server certificates as they are
   issued or observed, in a manner that allows anyone to audit
   certification authority (CA) activity and notice the issuance of
   suspect certificates as well as to audit the certificate logs
   themselves.  The intent is that eventually clients would refuse to
   honor certificates that do not appear in a log, effectively forcing
   CAs to add all issued certificates to the logs.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-21

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Eran Messeri <[email-masked]>
Date: Thu, 24 Nov 2016 12:46:11 +0000

The changes from draft 20:
* Relaxation of MUST to SHOULD in section 5.1.
* Removal of the optional APIs.

Diff file attached.

On Thu, Nov 24, 2016 at 12:33 PM, <[email-masked]> wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
diff --git a/draft-ietf-trans-rfc6962-bis.md b/draft-ietf-trans-rfc6962-bis.md
index 13c89a0..570d7c6 100644
--- a/draft-ietf-trans-rfc6962-bis.md
+++ b/draft-ietf-trans-rfc6962-bis.md
@@ -1,6 +1,6 @@
 ---
 title: "Certificate Transparency"
-docname: draft-ietf-trans-rfc6962-bis-20
+docname: draft-ietf-trans-rfc6962-bis-21
 category: "std"
 
 ipr: "trust200902"
@@ -580,12 +580,16 @@ the log.
 
 Logs MUST verify that each submitted certificate or precertificate has a valid
 signature chain to an accepted trust anchor, using the chain of intermediate CA
-certificates provided by the submitter. Logs MUST accept certificates and
+certificates provided by the submitter. Logs SHOULD accept certificates and
 precertificates that are fully valid according to RFC 5280 [RFC5280]
-verification rules and are submitted with such a chain. Logs MAY accept
-certificates and precertificates that have expired, are not yet valid, have been
-revoked, or are otherwise not fully valid according to RFC 5280 verification
-rules in order to accommodate quirks of CA certificate-issuing software.
+verification rules and are submitted with such a chain (A log may decide, for
+example, to temporarily reject valid submissions to protect itself against
+denial-of-service attacks).
+
+Logs MAY accept certificates and precertificates that have expired, are not yet
+valid, have been revoked, or are otherwise not fully valid according to RFC
+5280 verification rules in order to accommodate quirks of CA
+certificate-issuing software.
 However, logs MUST reject submissions without a valid signature chain to an
 accepted trust anchor. Logs MUST also reject precertificates that do not conform
 to the requirements in {{precertificates}}.
@@ -1339,69 +1343,6 @@ Outputs:
     the maximum number of certificates in the chain, in decimal. If there is no
     limit, this is omitted.
 
-# Optional Client Messages
-
-Logs MAY implement these messages. They are not required for correct operation
-of logs or their clients, but may be convenient in some circumstances.
-
-## Get Entry Number for SCT
-
-GET https://\<log server>/ct/v2/get-entry-for-sct
-
-Inputs:
-
-: sct:
-  : A base64 encoded `TransItem` of type `x509_sct_v2` or `precert_sct_v2`
-    signed by this log.
-
-Outputs:
-
-: entry:
-  : 0-based index of the log entry corresponding to the supplied SCT.
-
-Error codes:
-
-|---------------+--------------------------------------------------------------------|
-| Error Code    | Meaning                                                            |
-|---------------+--------------------------------------------------------------------|
-| bad signature | `sct` is not signed by this log.                                   |
-| not found     | `sct` does not correspond to an entry that is currently available. |
-|---------------+--------------------------------------------------------------------|
-
-Note that any SCT signed by a log MUST have a corresponding entry in the log,
-but it may not be retrievable until the MMD has passed since the SCT was issued.
-
-## Get Entry Numbers for TBSCertificate
-
-GET https://\<log server>/ct/v2/get-entry-for-tbscertificate
-
-Inputs:
-
-: hash:
-  : A base64 encoded HASH of a `TBSCertificate` for which the log has previously
-    issued an SCT. (Note that a precertificate's TBSCertificate is reconstructed
-    from the corresponding certificate as described in
-    {{reconstructing_tbscertificate}}).
-
-Outputs:
-
-: entries:
-  : An array of 0-based indices of log entries corresponding to the supplied
-    HASH.
-
-Error codes:
-
-|------------+--------------------------------------------------------------------|
-| Error Code | Meaning                                                            |
-|------------+--------------------------------------------------------------------|
-| bad hash   | `hash` is not the right size or format.                            |
-| not found  | `sct` does not correspond to an entry that is currently available. |
-|------------+--------------------------------------------------------------------|
-
-Note that it is possible for a certificate to be logged more than once. If that
-is the case, the log MAY return more than one entry index. If the certificate is
-present in the log, then the log MUST return at least one entry index.
-
 # TLS Servers    {#tls_servers}
 
 TLS servers MUST use at least one of the three mechanisms listed below to

---

From: Paul Wouters <[email-masked]>
Date: Thu, 24 Nov 2016 14:54:23 -0500 (EST)

On Thu, 24 Nov 2016, Eran Messeri wrote:

> The changes from draft 20:* Relaxation of MUST to SHOULD in section 5.1.

Thanks Eran!

>       https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-rfc6962-bis-21

This looks good to me and seems to match what people thought the text
should be during our meeting at IETF#97. If anyone thinks the new text
in Section 5.1 is incorrect or incomplete, please let us know as soon
as possible.

Since the diff looks large due to the section renumbering, the actual
MUST -> SHOULD change is:

- Logs MUST accept certificates and precertificates that are fully
+ Logs SHOULD accept certificates and precertificates that are fully
   valid according to RFC 5280 [RFC5280] verification rules and are
   submitted with such a chain. 
+ (A log may decide, for example, to temporarily reject valid
+ submissions to protect itself against denial-of-service attacks).

Thanks,

Paul