draft-ietf-trans-rfc6962-bis-00.txt   draft-ietf-trans-rfc6962-bis-01.txt 
Public Notary Transparency Working Group B. Laurie Public Notary Transparency Working Group B. Laurie
Internet-Draft A. Langley Internet-Draft A. Langley
Intended status: Standards Track E. Kasper Intended status: Standards Track E. Kasper
Expires: August 23, 2014 Google Expires: October 18, 2014 Google
R. Stradling R. Stradling
Comodo Comodo
February 19, 2014 April 16, 2014
Certificate Transparency Certificate Transparency
draft-ietf-trans-rfc6962-bis-00 draft-ietf-trans-rfc6962-bis-01
Abstract Abstract
This document describes an experimental protocol for publicly logging This document describes an experimental protocol for publicly logging
the existence of Transport Layer Security (TLS) certificates as they the existence of Transport Layer Security (TLS) certificates as they
are issued or observed, in a manner that allows anyone to audit are issued or observed, in a manner that allows anyone to audit
certificate authority (CA) activity and notice the issuance of certificate authority (CA) activity and notice the issuance of
suspect certificates as well as to audit the certificate logs suspect certificates as well as to audit the certificate logs
themselves. The intent is that eventually clients would refuse to themselves. The intent is that eventually clients would refuse to
honor certificates that do not appear in a log, effectively forcing honor certificates that do not appear in a log, effectively forcing
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2014. This Internet-Draft will expire on October 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 4 1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 4
2. Cryptographic Components . . . . . . . . . . . . . . . . . . 4 2. Cryptographic Components . . . . . . . . . . . . . . . . . . 4
2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 4 2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Merkle Audit Paths . . . . . . . . . . . . . . . . . 5 2.1.1. Merkle Audit Paths . . . . . . . . . . . . . . . . . 5
2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 6 2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 6
2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 8 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 8
3. Log Format and Operation . . . . . . . . . . . . . . . . . . 9 3. Log Format and Operation . . . . . . . . . . . . . . . . . . 9
3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Structure of the Signed Certificate Timestamp . . . . . . 12 3.2. Private Domain Name Labels . . . . . . . . . . . . . . . 12
3.3. Including the Signed Certificate Timestamp in the TLS 3.2.1. Wildcard Certificates . . . . . . . . . . . . . . . . 12
Handshake . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2. Redacting Domain Name Labels in Precertificates . . . 12
3.3.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 15 3.2.3. Using a Name-Constrained Intermediate CA . . . . . . 13
3.4. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 15 3.3. Structure of the Signed Certificate Timestamp . . . . . . 13
3.5. Signed Tree Head . . . . . . . . . . . . . . . . . . . . 16 3.4. Including the Signed Certificate Timestamp in the TLS
4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 17 Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 17 3.4.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 17
4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 18 3.5. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 18 3.6. Signed Tree Head . . . . . . . . . . . . . . . . . . . . 18
4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 19
4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 19
4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 20
4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 20
4.4. Retrieve Merkle Consistency Proof between Two Signed Tree 4.4. Retrieve Merkle Consistency Proof between Two Signed Tree
Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash . . . . 19 4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash . . . . 21
4.6. Retrieve Entries from Log . . . . . . . . . . . . . . . . 20 4.6. Retrieve Entries from Log . . . . . . . . . . . . . . . . 22
4.7. Retrieve Accepted Root Certificates . . . . . . . . . . . 21 4.7. Retrieve Accepted Root Certificates . . . . . . . . . . . 23
4.8. Retrieve Entry+Merkle Audit Proof from Log . . . . . . . 21 4.8. Retrieve Entry+Merkle Audit Proof from Log . . . . . . . 23
5. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Submitters . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Submitters . . . . . . . . . . . . . . . . . . . . . . . 24
5.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4. Auditor . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.4. Auditor . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7.1. Misissued Certificates . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.2. Detection of Misissue . . . . . . . . . . . . . . . . . . 24 7.1. Misissued Certificates . . . . . . . . . . . . . . . . . 26
7.3. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 24 7.2. Detection of Misissue . . . . . . . . . . . . . . . . . . 26
8. Efficiency Considerations . . . . . . . . . . . . . . . . . . 25 7.3. Redaction of Public Domain Name Labels . . . . . . . . . 26
9. Future Changes . . . . . . . . . . . . . . . . . . . . . . . 25 7.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 8. Efficiency Considerations . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Future Changes . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28
1. Informal Introduction 1. Informal Introduction
Certificate transparency aims to mitigate the problem of misissued Certificate transparency aims to mitigate the problem of misissued
certificates by providing publicly auditable, append-only, untrusted certificates by providing publicly auditable, append-only, untrusted
logs of all issued certificates. The logs are publicly auditable so logs of all issued certificates. The logs are publicly auditable so
that it is possible for anyone to verify the correctness of each log that it is possible for anyone to verify the correctness of each log
and to monitor when new certificates are added to it. The logs do and to monitor when new certificates are added to it. The logs do
not themselves prevent misissue, but they ensure that interested not themselves prevent misissue, but they ensure that interested
parties (particularly those named in certificates) can detect such parties (particularly those named in certificates) can detect such
skipping to change at page 10, line 9 skipping to change at page 10, line 9
will be valid against the issued certificate. The Precertificate is will be valid against the issued certificate. The Precertificate is
an X.509v3 certificate for simplicity, but, since it isn't used for an X.509v3 certificate for simplicity, but, since it isn't used for
anything but logging, could equally be some other data structure. anything but logging, could equally be some other data structure.
The Precertificate is constructed from the certificate to be issued The Precertificate is constructed from the certificate to be issued
by adding a special critical poison extension (OID by adding a special critical poison extension (OID
1.3.6.1.4.1.11129.2.4.3, whose extnValue OCTET STRING contains ASN.1 1.3.6.1.4.1.11129.2.4.3, whose extnValue OCTET STRING contains ASN.1
NULL data (0x05 0x00)) to the end-entity TBSCertificate, minus the NULL data (0x05 0x00)) to the end-entity TBSCertificate, minus the
SCT extension, which is obviously unknown until after the SCT extension, which is obviously unknown until after the
Precertificate has been submitted to the log. The poison extension Precertificate has been submitted to the log. The poison extension
is to ensure that the Precertificate cannot be validated by a is to ensure that the Precertificate cannot be validated by a
standard X.509v3 client. The resulting TBSCertificate [RFC5280] is standard X.509v3 client. The Precertificate MAY redact certain
then signed with either domain name labels that will be present in the final certificate (see
Section 3.2.2). The resulting TBSCertificate [RFC5280] is then
signed with either
o a special-purpose (CA:true, Extended Key Usage: Certificate o a special-purpose (CA:true, Extended Key Usage: Certificate
Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing
Certificate. The Precertificate Signing Certificate MUST be Certificate. The Precertificate Signing Certificate MUST be
directly certified by the (root or intermediate) CA certificate directly certified by the (root or intermediate) CA certificate
that will ultimately sign the end-entity TBSCertificate yielding that will ultimately sign the end-entity TBSCertificate yielding
the end-entity certificate (note that the log may relax standard the end-entity certificate (note that the log may relax standard
validation rules to allow this, so long as the issued certificate validation rules to allow this, so long as the issued certificate
will be valid), will be valid),
skipping to change at page 12, line 5 skipping to change at page 12, line 8
"pre_certificate" is the Precertificate submitted for auditing. "pre_certificate" is the Precertificate submitted for auditing.
"precertificate_chain" is a chain of additional certificates required "precertificate_chain" is a chain of additional certificates required
to verify the Precertificate submission. The first certificate MAY to verify the Precertificate submission. The first certificate MAY
be a valid Precertificate Signing Certificate and MUST certify the be a valid Precertificate Signing Certificate and MUST certify the
first certificate. Each following certificate MUST directly certify first certificate. Each following certificate MUST directly certify
the one preceding it. The final certificate MUST be a root the one preceding it. The final certificate MUST be a root
certificate accepted by the log. certificate accepted by the log.
3.2. Structure of the Signed Certificate Timestamp 3.2. Private Domain Name Labels
Enterprises regard some DNS domain name labels within their
registered domain space as private and security sensitive. Even
though these domains are often only accessible within the
enterprise's private network, it's common for them to be secured
using publicly trusted TLS server certificates. Enterprises don't
want these private labels to appear in public logs.
3.2.1. Wildcard Certificates
A certificate containing a DNS-ID [RFC6125] of "*.example.com" could
be used to secure the domain "topsecret.example.com", without
revealing the string "topsecret" publicly.
Since TLS clients only match the wildcard character to the complete
leftmost label of the DNS domain name (see Section 6.4.3 of
[RFC6125]), this approach would not work for a DNS-ID such as
"top.secret.example.com". Also, wildcard certificates are prohibited
in some cases, such as Extended Validation Certificates
[EVSSLGuidelines].
3.2.2. Redacting Domain Name Labels in Precertificates
When creating a Precertificate, the CA MAY substitute one or more of
the complete leftmost labels in each DNS-ID with the literal string
"(PRIVATE)". For example, if a certificate contains a DNS-ID of
"top.secret.example.com", then the corresponding Precertificate could
contain "(PRIVATE).example.com" instead. Labels in a CN-ID [RFC6125]
MUST remain unredacted.
When a Precertificate contains one or more redacted labels, an
extension (OID 1.3.6.1.4.1.11129.<TBD>, whose extnValue OCTET STRING
contains an ASN.1 SEQUENCE OF INTEGERs) MUST be added to the
corresponding certificate: the first INTEGER indicates the number of
labels redacted in the Precertificate's first DNS-ID; the second
INTEGER does the same for the Precertificate's second DNS-ID; etc.
There MUST NOT be more INTEGERs than there are DNS-IDs. If there are
fewer INTEGERs than there are DNS-IDs, the shortfall is made up by
implicitly repeating the last INTEGER. Each INTEGER MUST have a
value of zero or more. The purpose of this extension is to enable
TLS clients to accurately reconstruct the Precertificate from the
certificate without having to perform any guesswork.
3.2.3. Using a Name-Constrained Intermediate CA
An intermediate CA certificate or Precertificate that contains the
Name Constraints extension (see Section 4.2.1.10 of [RFC5280]) MAY be
logged in place of end-entity certificates issued by that
intermediate CA, as long as all of the following conditions are met:
o there MUST be an extension (OID 1.3.6.1.4.1.11129.<TBD>, whose
extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)).
This extension is an explicit indication that it is acceptable to
not log certificates issued by this intermediate CA.
o permittedSubtrees MUST specify one or more dNSNames.
o excludedSubtrees MUST specify the entire IPv4 and IPv6 address
ranges.
Below is an example Name Constraints extension that meets these
conditions:
SEQUENCE {
OBJECT IDENTIFIER '2 5 29 30'
OCTET STRING, encapsulates {
SEQUENCE {
[0] {
SEQUENCE {
[1] 'example.com'
}
[1] {
SEQUENCE {
[7] 00 00 00 00 00 00 00 00
}
SEQUENCE {
[7]
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
}
}
}
}
}
}
3.3. Structure of the Signed Certificate Timestamp
enum { certificate_timestamp(0), tree_hash(1), (255) } enum { certificate_timestamp(0), tree_hash(1), (255) }
SignatureType; SignatureType;
enum { v1(0), (255) } enum { v1(0), (255) }
Version; Version;
struct { struct {
opaque key_id[32]; opaque key_id[32];
} LogID; } LogID;
skipping to change at page 13, line 42 skipping to change at page 15, line 42
"entry_type" may be implicit from the context in which the SCT is "entry_type" may be implicit from the context in which the SCT is
presented. presented.
"signed_entry" is the "leaf_certificate" (in the case of an "signed_entry" is the "leaf_certificate" (in the case of an
X509ChainEntry) or is the PreCert (in the case of a X509ChainEntry) or is the PreCert (in the case of a
PrecertChainEntry), as described above. PrecertChainEntry), as described above.
"extensions" are future extensions to this protocol version (v1). "extensions" are future extensions to this protocol version (v1).
Currently, no extensions are specified. Currently, no extensions are specified.
3.3. Including the Signed Certificate Timestamp in the TLS Handshake 3.4. Including the Signed Certificate Timestamp in the TLS Handshake
The SCT data corresponding to the end-entity certificate from at The SCT data corresponding to the end-entity certificate from at
least one log must be included in the TLS handshake, either by using least one log must be included in the TLS handshake, either by using
an X509v3 certificate extension as described below, by using a TLS an X509v3 certificate extension as described below, by using a TLS
extension (Section 7.4.1.4 of [RFC5246]) with type extension (Section 7.4.1.4 of [RFC5246]) with type
"signed_certificate_timestamp", or by using Online Certificate Status "signed_certificate_timestamp", or by using Online Certificate Status
Protocol (OCSP) Stapling (also known as the "Certificate Status Protocol (OCSP) Stapling (also known as the "Certificate Status
Request" TLS extension; see [RFC6066]), where the OCSP response Request" TLS extension; see [RFC6066]), where the OCSP response
includes an extension with OID 1.3.6.1.4.1.11129.2.4.5 (see includes an extension with OID 1.3.6.1.4.1.11129.2.4.5 (see
[RFC2560]) and body: [RFC2560]) and body:
skipping to change at page 15, line 5 skipping to change at page 17, line 5
TLS clients MUST implement all three mechanisms. Servers MUST TLS clients MUST implement all three mechanisms. Servers MUST
implement at least one of the three mechanisms. Note that existing implement at least one of the three mechanisms. Note that existing
TLS servers can generally use the certificate extension mechanism TLS servers can generally use the certificate extension mechanism
without modification. without modification.
TLS servers should send SCTs from multiple logs in case one or more TLS servers should send SCTs from multiple logs in case one or more
logs are not acceptable to the client (for example, if a log has been logs are not acceptable to the client (for example, if a log has been
struck off for misbehavior or has had a key compromise). struck off for misbehavior or has had a key compromise).
3.3.1. TLS Extension 3.4.1. TLS Extension
The SCT can be sent during the TLS handshake using a TLS extension The SCT can be sent during the TLS handshake using a TLS extension
with type "signed_certificate_timestamp". with type "signed_certificate_timestamp".
Clients that support the extension SHOULD send a ClientHello Clients that support the extension SHOULD send a ClientHello
extension with the appropriate type and empty "extension_data". extension with the appropriate type and empty "extension_data".
Servers MUST only send SCTs to clients who have indicated support for Servers MUST only send SCTs to clients who have indicated support for
the extension in the ClientHello, in which case the SCTs are sent by the extension in the ClientHello, in which case the SCTs are sent by
setting the "extension_data" to a "SignedCertificateTimestampList". setting the "extension_data" to a "SignedCertificateTimestampList".
Session resumption uses the original session information: clients Session resumption uses the original session information: clients
SHOULD include the extension type in the ClientHello, but if the SHOULD include the extension type in the ClientHello, but if the
session is resumed, the server is not expected to process it or session is resumed, the server is not expected to process it or
include the extension in the ServerHello. include the extension in the ServerHello.
3.4. Merkle Tree 3.5. Merkle Tree
The hashing algorithm for the Merkle Tree Hash is SHA-256. The hashing algorithm for the Merkle Tree Hash is SHA-256.
Structure of the Merkle Tree input: Structure of the Merkle Tree input:
enum { timestamped_entry(0), (255) } enum { timestamped_entry(0), (255) }
MerkleLeafType; MerkleLeafType;
struct { struct {
uint64 timestamp; uint64 timestamp;
skipping to change at page 16, line 20 skipping to change at page 18, line 20
"timestamp" is the timestamp of the corresponding SCT issued for this "timestamp" is the timestamp of the corresponding SCT issued for this
certificate. certificate.
"signed_entry" is the "signed_entry" of the corresponding SCT. "signed_entry" is the "signed_entry" of the corresponding SCT.
"extensions" are "extensions" of the corresponding SCT. "extensions" are "extensions" of the corresponding SCT.
The leaves of the Merkle Tree are the leaf hashes of the The leaves of the Merkle Tree are the leaf hashes of the
corresponding "MerkleTreeLeaf" structures. corresponding "MerkleTreeLeaf" structures.
3.5. Signed Tree Head 3.6. Signed Tree Head
Every time a log appends new entries to the tree, the log SHOULD sign Every time a log appends new entries to the tree, the log SHOULD sign
the corresponding tree hash and tree information (see the the corresponding tree hash and tree information (see the
corresponding Signed Tree Head client message in Section 4.3). The corresponding Signed Tree Head client message in Section 4.3). The
signature for that data is structured as follows: signature for that data is structured as follows:
digitally-signed struct { digitally-signed struct {
Version version; Version version;
SignatureType signature_type = tree_hash; SignatureType signature_type = tree_hash;
uint64 timestamp; uint64 timestamp;
skipping to change at page 19, line 37 skipping to change at page 21, line 37
GET https://<log server>/ct/v1/get-proof-by-hash GET https://<log server>/ct/v1/get-proof-by-hash
Inputs: Inputs:
hash: A base64-encoded v1 leaf hash. hash: A base64-encoded v1 leaf hash.
tree_size: The tree_size of the tree on which to base the proof, tree_size: The tree_size of the tree on which to base the proof,
in decimal. in decimal.
The "hash" must be calculated as defined in Section 3.4. The The "hash" must be calculated as defined in Section 3.5. The
"tree_size" must designate an existing v1 STH. "tree_size" must designate an existing v1 STH.
Outputs: Outputs:
leaf_index: The 0-based index of the entry corresponding to the leaf_index: The 0-based index of the entry corresponding to the
"hash" parameter. "hash" parameter.
audit_path: An array of base64-encoded Merkle Tree nodes proving audit_path: An array of base64-encoded Merkle Tree nodes proving
the inclusion of the chosen certificate. the inclusion of the chosen certificate.
skipping to change at page 24, line 45 skipping to change at page 26, line 45
operating correctly. Thus, the maximum period of time during which a operating correctly. Thus, the maximum period of time during which a
misissued certificate can be used without being available for audit misissued certificate can be used without being available for audit
is the MMD. is the MMD.
7.2. Detection of Misissue 7.2. Detection of Misissue
The logs do not themselves detect misissued certificates; they rely The logs do not themselves detect misissued certificates; they rely
instead on interested parties, such as domain owners, to monitor them instead on interested parties, such as domain owners, to monitor them
and take corrective action when a misissue is detected. and take corrective action when a misissue is detected.
7.3. Misbehaving Logs 7.3. Redaction of Public Domain Name Labels
CAs SHOULD NOT redact domain name labels in Precertificates to the
extent that domain name ownership becomes unclear (e.g.
"(PRIVATE).com" and "(PRIVATE).co.uk" would both be problematic).
Logs MUST NOT reject any Precertificate that is overly redacted but
which is otherwise considered compliant. It is expected that
monitors will treat overly redacted Precertificates as potentially
misissued. TLS clients MAY reject a certificate whose corresponding
Precertificate would be overly redacted.
7.4. Misbehaving Logs
A log can misbehave in two ways: (1) by failing to incorporate a A log can misbehave in two ways: (1) by failing to incorporate a
certificate with an SCT in the Merkle Tree within the MMD and (2) by certificate with an SCT in the Merkle Tree within the MMD and (2) by
violating its append-only property by presenting two different, violating its append-only property by presenting two different,
conflicting views of the Merkle Tree at different times and/or to conflicting views of the Merkle Tree at different times and/or to
different parties. Both forms of violation will be promptly and different parties. Both forms of violation will be promptly and
publicly detectable. publicly detectable.
Violation of the MMD contract is detected by log clients requesting a Violation of the MMD contract is detected by log clients requesting a
Merkle audit proof for each observed SCT. These checks can be Merkle audit proof for each observed SCT. These checks can be
skipping to change at page 25, line 50 skipping to change at page 28, line 14
o We may add hash and signing algorithm agility. o We may add hash and signing algorithm agility.
o We may describe some gossip protocols. o We may describe some gossip protocols.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Erwann Abelea, Robin Alden, Al The authors would like to thank Erwann Abelea, Robin Alden, Al
Cutter, Francis Dupont, Stephen Farrell, Brad Hill, Jeff Hodges, Paul Cutter, Francis Dupont, Stephen Farrell, Brad Hill, Jeff Hodges, Paul
Hoffman, Jeffrey Hutzelman, SM, Alexey Melnikov, Chris Palmer, Trevor Hoffman, Jeffrey Hutzelman, SM, Alexey Melnikov, Chris Palmer, Trevor
Perrin, Ryan Sleevi, Rob Stradling, and Carl Wallace for their Perrin, Ryan Sleevi and Carl Wallace for their valuable
valuable contributions. contributions.
11. References 11. References
11.1. Normative Reference 11.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References 11.2. Informative References
skipping to change at page 26, line 26 skipping to change at page 28, line 38
Tamper-Evident Logging", Proceedings of the 18th USENIX Tamper-Evident Logging", Proceedings of the 18th USENIX
Security Symposium, Montreal, August 2009, Security Symposium, Montreal, August 2009,
<http://static.usenix.org/event/sec09/tech/full_papers/ <http://static.usenix.org/event/sec09/tech/full_papers/
crosby.pdf>. crosby.pdf>.
[DSS] National Institute of Standards and Technology, "Digital [DSS] National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS 186-3, June 2009, Signature Standard (DSS)", FIPS 186-3, June 2009,
<http://csrc.nist.gov/publications/fips/fips186-3/ <http://csrc.nist.gov/publications/fips/fips186-3/
fips_186-3.pdf>. fips_186-3.pdf>.
[EVSSLGuidelines]
CA/Browser Forum, "Guidelines For The Issuance And
Management Of Extended Validation Certificates", 2007,
<https://cabforum.org/wp-content/uploads/
EV_Certificate_Guidelines.pdf>.
[FIPS.180-4] [FIPS.180-4]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-4, March 2012, Hash Standard", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
skipping to change at page 27, line 17 skipping to change at page 29, line 39
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011.
Authors' Addresses Authors' Addresses
Ben Laurie Ben Laurie
Google UK Ltd. Google UK Ltd.
EMail: benl@google.com EMail: benl@google.com
Adam Langley Adam Langley
Google Inc. Google Inc.
EMail: agl@google.com EMail: agl@google.com
Emilia Kasper Emilia Kasper
Google Switzerland GmbH Google Switzerland GmbH
EMail: ekasper@google.com EMail: ekasper@google.com
 End of changes. 19 change blocks. 
47 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/