draft-ietf-trans-threat-analysis-08.txt   draft-ietf-trans-threat-analysis-09.txt 
Public Notary Transparency S. Kent Public Notary Transparency S. Kent
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational August 12, 2016 Intended status: Informational September 18, 2016
Expires: February 13, 2017 Expires: March 22, 2017
Attack and Threat Model for Certificate Transparency Attack and Threat Model for Certificate Transparency
draft-ietf-trans-threat-analysis-08 draft-ietf-trans-threat-analysis-09
Abstract Abstract
This document describes an attack model and discusses threats for the This document describes an attack model and discusses threats for the
Web PKI context in which security mechanisms to detect mis-issuance Web PKI context in which security mechanisms to detect mis-issuance
of web site certificates are being developed. The model provides an of web site certificates are being developed. The model provides an
analysis of detection and remediation mechanisms for both syntactic analysis of detection and remediation mechanisms for both syntactic
and semantic mis-issuance. The model introduces an outline of and semantic mis-issuance. The model introduces an outline of
attacks to organize the discussion. The model also describes the attacks to organize the discussion. The model also describes the
roles played by the elements of the Certificate Transparency (CT) roles played by the elements of the Certificate Transparency (CT)
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 February 13, 2017. This Internet-Draft will expire on March 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 7 1.1. Conventions used in this document . . . . . . . . . . . . 7
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 9 3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 9
3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 9 3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 9
3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 9 3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 9
3.1.2. Certificate not logged . . . . . . . . . . . . . . . 11 3.1.2. Certificate not logged . . . . . . . . . . . . . . . 11
3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12 3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12
3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 12 3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 12
3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14 3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14
3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15 3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 14
3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15 3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15
3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 17 3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 16
3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 17 3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 17
3.4. Using an SCT for a revoked certificate . . . . . . . . . 18 3.4. Attacks Based on Exploiting Multiple Certificate Chains . 18
3.4.1. Revocation of the Bogus Certificate . . . . . . . . . 20 4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 20
3.4.2. Revocation of a CA Certificate . . . . . . . . . . . 21 4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 20
4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 22 4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 21
4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 22 4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23
4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 22 4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 23
4.1.2. Certificate not logged . . . . . . . . . . . . . . . 24 4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 23
4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 24 4.2.2. Certificate is not logged . . . . . . . . . . . . . . 24
4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 24 5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 25
4.2.2. Certificate is not logged . . . . . . . . . . . . . . 26 5.1. How does a Subject know which Monitor(s) to use? . . . . 25
5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 26 5.2. How does a Monitor discover new logs? . . . . . . . . . . 25
5.1. How does a Subject know which Monitor(s) to use? . . . . 26 5.3. CA response to report of a bogus or erroneous certificate 25
5.2. How does a Monitor discover new logs? . . . . . . . . . . 26 5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 26
5.3. CA response to report of a bogus or erroneous certificate 26 5.5. Remediation for a malicious CA . . . . . . . . . . . . . 26
5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 27 5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 26
5.5. Remediation for a malicious CA . . . . . . . . . . . . . 27 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Certificate transparency (CT) is a set of mechanisms designed to Certificate transparency (CT) is a set of mechanisms designed to
detect, deter, and facilitate remediation of certificate mis- detect, deter, and facilitate remediation of certificate mis-
issuance. The term certificate mis-issuance is defined here to issuance. The term certificate mis-issuance is defined here to
encompass violations of either semantic or syntactic constraints. encompass violations of either semantic or syntactic constraints.
The fundamental semantic constraint for a certificate is that it was The fundamental semantic constraint for a certificate is that it was
issued to an entity that is authorized to represent the Subject (or issued to an entity that is authorized to represent the Subject (or
Subject Alternative) named in the certificate. (It is also assumed Subject Alternative) named in the certificate. (It is also assumed
skipping to change at page 18, line 27 skipping to change at page 18, line 11
An Auditor checking for log consistency and with access to bogus An Auditor checking for log consistency and with access to bogus
SCTs, might conclude that the compromised log is acting maliciously, SCTs, might conclude that the compromised log is acting maliciously,
and is presenting a split view to its clients. In this fashion the and is presenting a split view to its clients. In this fashion the
compromised log may be shunned and forced to shut down. However, if compromised log may be shunned and forced to shut down. However, if
an attacker targets a set of TLS clients that do not have access to an attacker targets a set of TLS clients that do not have access to
the legitimate log, they may not be able to detect this the legitimate log, they may not be able to detect this
inconsistency. In this case CT would need to rely on a distributed inconsistency. In this case CT would need to rely on a distributed
gossiping audit mechanism to detect the compromise (see Section 5.6). gossiping audit mechanism to detect the compromise (see Section 5.6).
3.4. Using an SCT for a revoked certificate 3.4. Attacks Based on Exploiting Multiple Certificate Chains
In general, this class of attack is analogous to a malicious CA
creating a bogus certificate and receiving an SCT (with no log entry)
from a misbehaving log (Section 3.2.1.2). In that case the lack of a
log entry prevented detection of the bogus certificate by Monitors,
and the presence of the SCT prevented rejection by a CT-aware browser
that accepts SCTs from the compromised log. A more insidious type of
attack calls for a bogus certificate to be issued and logged, but
tries to evade remediation by relying on the fact that some several
certificate revocation depend on the certificate path under which a
certificate has been revoked.
Section 3.2 examined attacks in which a single CA might issue a bogus
certificate. There is also the potential that two or more instances
of a CA might issue a bogus certificate in a fashion designed to foil
the remediation (but not detection) safeguards envisioned by CT. For
simplicity of exposition, we refer to these CA instances as CA-1 and
CA-2.
CA-1 and CA-2 may both be malicious and might even appear to be
distinct CAs based on registration information provided to the CAs
that issue certificates to them. This type of attack requires that
these CA instances have the same name and the same public key, but
during registration they might provide different contact information,
e.g., postal and e-mail addresses, phone numbers, etc. In this case
they would appear to be distinct CAs, even though they operate as one
CA.
RFC 5280 requires that no CA issue certificates with the same Subject
name to distinct entities (Section 4.2.1.6). However, if a CA is the
victim of an attack, it might not be aware that a certificate was
issued for CA-1 or CA-2. Also, if CA-1 and CA-2 acquire certificates
from different parent CAs, there is no requirement defined in 5280
that ensures these parents would detect the use of the same name and
public key by CA-1 and CA-2. (The Security Considerations section of
RFC 5280 warns that name collisions in certificates could cause
security problems, but it does not specify a means by which they can
be detected and avoided on a global basis.)
Once certificates have been issued to CA-1 and CA-2, they can issue a Section 3.2 examined attacks in which a malicious CA issued a bogus
bogus certificate that targets a Subject (call it X). For the attack certificate and either tried to prevent the Subject from detecting
to succeed, the certificate for X must be identical, irrespective of the bogus certificate, or reported the bogus certificate as valid, to
the CA instance under which it was issued. Note that these attacks at least some relying parties, even if the Subject requested
may take place without the knowledge or assistance of trust anchors; revocation. These attacks are limited in that if the bogus
any pair of intermediate CAs can effect this attack without the certificate is not submitted to a log, then it may not be accepted by
knowledge of superior CAs (which are presumed to be benign). CT-aware browsers, and submitting the bogus certificate to a log
increases the chances that the CA's malicious behavior will be
detected.
This type of attack assumes that X is logged by CA-1 (without loss of In general, if a CA is discovered to be acting maliciously, its
generality) and thus can be detected by a Monitor tracking certificates will no longer be accepted, either because its parent
certificates issued in the name of X. It is assumed that CA-1 will will revoke its CA certificate, its CA certificate will be added to
revoke the bogus certificate when the targeted Subject is notified of browsers' blacklists, or both. However, a malicious CA may be able
that certificate's existence. CA-2 will not log the bogus to obtain an SCT for each bogus certificate that it issues and
certificate nor will it revoke the certificate. The SCT for X is continue to have those certificates accepted by relying parties even
independent of the CA instance under which it was issued. The after its malicious behavior has been detected. It can do this by
revocation of X by CA-1 may not cause X to be viewed as revoked when creating more than one path validation chain for the certificates, as
it is encountered as part of the certificate path including CA-2, shown in Figure 2.
depending on revocation mechanism employed (see 3.4.1).
It is not necessary for both CA-1 and CA-2 to be malicious. CA-1 +-----------------+ +-----------------+
could, be the victim of a compromise under which X is issued. An | CA A | | CA B |
adversary could then cause CA-2 to be created by registering it with +-----------------+ +-----------------+
an unsuspecting CA, or by compromising another, different CA. Other \ /
variations of the attack are possible, e.g., employing attacks on CAs \ /
to create subordinate CAs representing CA-1 and CA-2. The only CA certificate 1 \ / CA certificate 2
requirements are that the CAs that are attacked are authorized to \ /
issue subordinate CA certificates (pathLenConstraint of 1 or greater) +----------------+
and that any name constraints imposed on these CAs do not prohibit | malicious CA |
issuing a certificate to X. +----------------+
|
| bogus EE certificate
|
+------------------+
| targeted Subject |
+------------------+
If CA-1 was the victim of an attack, revocation of the bogus Figure 2: Multiple Certificate Chains for a Bogus Certificate
certificate, e.g., via a CRL or via OCSP, is the expected response.
Additionally, a browser vendor might add the bogus certificate to a
blacklist maintained by the vendor, e.g., if CA-1 failed to revoke it
or maybe as a precautionary measure.
If CA-1 is suspected of being malicious, e.g., because it has a In Figure 2, the malicious CA has been issued CA certificates by two
history of using bogus certificates, its certificate might be different parent CAs. The parent CAs may be two different trust
revoked. This revocation might be effected by the parent of that CA anchors, or one or both of them may be an intermediate CA (i.e., it
(which is assumed to not be complicit), or by a browser vendor using is subordinate to some trust anchor). If both parent CAs are
a blacklist. Whether the proposed attack can achieve its goal intermediate CAs, they may be subordinate to the same trust anchor or
depends on which revocation mechanism is employed, and which to different trust anchors. The malicious CA may have obtained
certificate or certificates are revoked. certificates from the two parents by applying to them for the
certificates, or by compromising the parent CAs and creating the
certificates without the knowledge of the CAs. If the malicious CA
applied for its certificates from these CAs, it may have presented
credentials that cause each parent to believe that the parent is
dealing with a different CA, despite the fact that the CA name and
public key are identical.
3.4.1. Revocation of the Bogus Certificate Because there are two certificate path validation chains, the
malicious CA could provide the chain that includes CA A when
submitting a bogus certificate to one or more logs, but an attacker
(colluding with the malicious CA) could provide the chain that
includes CA B to targeted browsers. If the CA's malicious behavior
is detected, then CA A and browser vendors may be alerted (e.g., via
the CT Monitor function) and revoke/blacklist CA certificate 1.
However, CA certificate 2 does not appear in any logs, and CA A is
unaware that CA B has issued a certificate to the malicious CA. Thus
those who detected the malicious behavior may not discover the second
chain and so may not alert CA B or browser vendors of the need to
revoke/blacklist CA certificate 2. In this case, targeted browsers
would continue to accept the bogus certificates issued by the
malicious CA, since the certificate chain they are provided is valid
and because the SCT issued for the bogus certificate it the same
irrespective of which certificate chain is presented.
If the bogus certificate (X) is revoked by CA-1, browsers should The bogus certificate will appear valid to a browser because
treat that certificate as invalid. However, a browser checking a CRL certificate revocation generally depends on the certificate path
or OCSP response might not match this revocation status data against (chain) used by a relying party when validating a certificate. This
the bogus certificate when it is encountered as under CA-2. This is is true irrespective of whether revocation is effected via use of a
because revocation status checking is performed in the context of a CRL or OCSP. Moreover, an attacker can steer a browser to specific
certification path (during path validation). The bogus certificate revocation status data via various means.
(X) has two different certification paths and thus the revocation
status data for each might be acquired and managed independently.
(RFC 5280 does not provide implementation guidance for management of
revocation data. It is known that some relying party implementations
maintain such information on a per-certificate path basis, but others
might not.)
Even if the bogus certificate contains an AIA extension pointing to The bogus certificate might contain an AIA extension pointing to an
an OCSP server the attack might still succeed. (As noted in the OCSP server controlled by the malicious CA (or the attacker). As
Section 1 above, RFC 5280 does not mandate inclusion this extension, noted in Section 3.2.1.1.1, the malicious CA could send a "good" OCSP
but its presence is required by CABF requirements.) As noted in response to a targeted browser instance, even if other parties are
Section 3.2.1.1.1, a malicious CA could send a "good" OCSP response provided with a "revoked" response. A TLS server can supply an OCSP
to a targeted browser instance, even if other parties are provided response to a browser as part of the TLS handshake [RFC6961], if
with a "revoked" response. Also note that a TLS server can supply an
OCSP response to a browser as part of the TLS handshake [RFC6961], if
requested by the browser. A TLS server posing as the entity named in requested by the browser. A TLS server posing as the entity named in
the bogus certificate could acquire a "good" OCSP response from the a the bogus certificate also could acquire a "good" OCSP response from
malicious CA (e.g., CA-B) to effect the attack. Only if the browser the malicious CA to effect the attack. Only if the browser relies
relies upon a trusted, third-party OCSP responder, one not part of upon a trusted, third-party OCSP responder, one not part of the
the collusion, would the attack fail. collusion, would these OCSP-based attacks fail.
The analysis above also applies to the use of CRLs to disseminate
certificate revocation status data. The bogus certificate could
contain a CRL distribution point extension instead of an AIA
extension. In that case a site supplying CRLs for CA-2 could supply
different CRLs to different requestors, in an attempt to hide the
revocation status of the bogus certificate from targeted browser
instances. This is analogous to a split-view attack effected by a CT
log. However, as noted in Section 3.2.1.1 and 3.2.1.1.1, no element
of CT is responsible for detecting inconsistent reporting of
certificate revocation status data. (Monitoring in the CT context
tracks log entries made by CAs or Subjects. Auditing is designed to
detect misbehavior by logs, not by CAs per se.)
If CA-1 (who logged the certificate) does not revoke it, a browser The bogus certificate could contain a CRL distribution point
vendor might enter the bogus certificate into a "blacklist". extension instead of an AIA extension. In that case a site supplying
Unfortunately, there are no IETF standards for such blacklists. Thus CRLs for the malicious CA could supply different CRLs to different
it is conceivable that the revocation status data also might be requestors, in an attempt to hide the revocation status of the bogus
managed in a path-specific fashion. If that were true, then the certificate from targeted browser instances. This is analogous to a
attack could succeed. However, if a vendor maintains revocation split-view attack effected by a CT log. However, as noted in
status data in a path-independent fashion, then the attack will fail. Section 3.2.1.1 and 3.2.1.1.1, no element of CT is responsible for
For example, if revoked certificates are identified by CA name and detecting inconsistent reporting of certificate revocation status
serial number, or a hash of the certificate, this attack would fail. data. (Monitoring in the CT context tracks log entries made by CAs
or Subjects. Auditing is designed to detect misbehavior by logs, not
by CAs per se.)
The failure of a bogus certificate (X) to be detected as revoked (by The failure of a bogus certificate to be detected as revoked (by a
a browser) is not the fault of CT. In the class of attacks described browser) is not the fault of CT. In the class of attacks described
here, CT achieves its goal of detecting the bogus certificate when here, CT achieves its goal of detecting the bogus certificate when
that certificate is logged and a Monitor observes the log entry. that certificate is logged and a Monitor observes the log entry.
Detection is intended to trigger revocation, to effect remediation, Detection is intended to trigger revocation, to effect remediation,
which is outside the scope of CT. However the SCT mechanism is the details of which are outside the scope of CT. However the SCT
intended to assure a relying party that certificate has been logged, mechanism is intended to assure a relying party that certificate has
is susceptible to being detected as bogus by a Monitor, and been logged, is susceptible to being detected as bogus by a Monitor,
presumably will be revoked if detected as such. In the context of and presumably will be revoked if detected as such. In the context
these attacks, because of the way revocation may be effected, the of these attacks, because of the way revocation may be implemented,
assurance provided by the SCT may not have the anticipated effect. the assurance provided by the SCT may not have the anticipated
effect.
3.4.2. Revocation of a CA Certificate
If CA-1 is viewed as acting maliciously, its parent might revoke that
CA's certificate. Even though CA-2 has the same name and uses the
same public key, its certificates is distinct from that of CA-A,
e.g., it was issued by a different parent and almost certainly has a
different certificate serial number. Thus revocation of the
certificate of CA-1 does not affect the certificate of CA-2. In this
case, the bogus EE certificate (X) would be treated as valid when it
appears in a certification path involving CA-2. Thus revocation the
certificate for CA-1 does not prevent this attack from succeeding.
A vendor also might choose to add the certificate of CA-1 to its This type of attack might be thwarted in several ways. For example,
blacklist, e.g., if that CA refuses to revoke the bogus certificate. if all intermediate (i.e., CA) certificates had to be logged, then CA
This also may not prevent the bogus certificate from being accepted certificate 2 might be rejected by CT-aware browsers. If a malicious
by a browser. For example, if the CA certificate blacklist entry is CA is discovered, a browser vendor might blacklist it by public key
analogous to a CRL entry (Subject name of the parent of the malicious (not by its serial number and the name of the parent CA or by a hash
CA and the serial number of the malicious CA's certificate), the of the certificate). This approach to revocation would cause CA
colluding CA's certificate would still be valid in this case. certificate 2 to be rejected as well as CA certificate 1. However
none of these mechanisms are part of the CT specification
[I-D.ietf-trans-rfc6962-bis] nor general IETF PKI standards (e.g.,
[RFC5280]).
4. Syntactic mis-issuance 4. Syntactic mis-issuance
4.1. Non-malicious Web PKI CA context 4.1. Non-malicious Web PKI CA context
This section analyzes the scenario in which the CA has no intent to This section analyzes the scenario in which the CA has no intent to
issue a syntactically incorrect certificate. As noted in Section 1, issue a syntactically incorrect certificate. As noted in Section 1,
we refer to a syntactically incorrect certificate as erroneous. we refer to a syntactically incorrect certificate as erroneous.
4.1.1. Certificate logged 4.1.1. Certificate logged
skipping to change at page 29, line 42 skipping to change at page 28, line 36
architecture addresses these attacks. architecture addresses these attacks.
7. IANA Considerations 7. IANA Considerations
None. None.
8. Acknowledgments 8. Acknowledgments
The author would like to thank David Mandelberg and Karen Seo for The author would like to thank David Mandelberg and Karen Seo for
their assistance in reviewing and preparing this document, and other their assistance in reviewing and preparing this document, and other
members of the TRANS working group for reviewing it. members of the TRANS working group for reviewing it. Much of the
text of Section 3.4 was provided by David Cooper, motivated by
observations from Daniel Kahn Gilmor.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.kent-trans-architecture] [I-D.kent-trans-architecture]
Kent, D., Mandelberg, D., and K. Seo, "Certificate Kent, S., Mandelberg, D., and K. Seo, "Certificate
Transparency (CT) System Architecture", draft-kent-trans- Transparency (CT) System Architecture", draft-kent-trans-
architecture-04 (work in progress), August 2016. architecture-04 (work in progress), August 2016.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-trans-gossip] [I-D.ietf-trans-gossip]
Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in
CT", draft-ietf-trans-gossip-03 (work in progress), July CT", draft-ietf-trans-gossip-03 (work in progress), July
2016. 2016.
[I-D.ietf-trans-rfc6962-bis] [I-D.ietf-trans-rfc6962-bis]
Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
Stradling, "Certificate Transparency", draft-ietf-trans- Stradling, "Certificate Transparency", draft-ietf-trans-
rfc6962-bis-18 (work in progress), July 2016. rfc6962-bis-19 (work in progress), August 2016.
[I-D.kent-trans-domain-validation-cert-checks] [I-D.kent-trans-domain-validation-cert-checks]
Kent, S. and R. Andrews, "Syntactic and Semantic Checks Kent, S. and R. Andrews, "Syntactic and Semantic Checks
for Domain Validation Certificates", draft-kent-trans- for Domain Validation Certificates", draft-kent-trans-
domain-validation-cert-checks-02 (work in progress), domain-validation-cert-checks-02 (work in progress),
December 2015. December 2015.
[I-D.kent-trans-extended-validation-cert-checks] [I-D.kent-trans-extended-validation-cert-checks]
Kent, S. and R. Andrews, "Syntactic and Semantic Checks Kent, S. and R. Andrews, "Syntactic and Semantic Checks
for Extended Validation Certificates", draft-kent-trans- for Extended Validation Certificates", draft-kent-trans-
 End of changes. 24 change blocks. 
186 lines changed or deleted 145 lines changed or added

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