Subject: [Trans] updated definition and attack analysis text

From: Stephen Kent <[email-masked]>
Date: Wed, 01 Oct 2014 13:50:50 -0400

Ignoring (for the moment) the suggestion to not consider syntactic 
mis-issuance,
and the topic of whether logs might perform syntax checks on certs 
submitted to them,
I have revised the attack analysis text. It at least provides a sense of 
the style
and structure one wants in such text, and which is missing from 6962-bis.

I've expanded the definitions of mis-issuance based on the message exchanges
Ben and I had, to more clearly describe the cases of syntactic and semantic
mis-issuance that are outside of the scope for CT, or that may be 
detectable only
if a Subject operates its own Monitor. I also added structure to group 
the attack cases,
to make for easier reading. I' ve kept the "notes" style, but these 
could be folded into
the attack case analysis if desired. (It would just introduce some 
redundancy.)

Steve

------

1. Goals and Definitions

The goal of Certificate Transparency (CT) is to detect mis-issuance of 
certificates, in the Web PKI context. It is anticipated that CT will 
help deter mis-issuance, e.g., by providing information to an affected 
Subject to facilitate revocation of a mis-issued certificate. The Web 
PKI context refers to the use of a set of Certification Authorities 
(CAs) that issue X.509 certificates to web servers to enable 
TLS-protected access by clients [cite WPKOPS?].

A certificate is characterized as mis-issued if the certificate does not 
conform to the requirements established by CA Browser Forum (CABF) 
documents for "domain validation" (DV) or "extended validation" (EV) 
certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issuance 
takes two primary forms syntactic mis-issuance and semantic mis-issuance.

1.A certificate may fail to meet the syntactic constraints imposed by 
the CABF guidelines.

a.Most syntactic constraints from [CABF-Baseline] and [CABF-EV], can be 
checked via examination of a certificate chain, without reference to 
Subject-specific or CA-specific data.

b.A few syntactic constraints require access to data specific to a CA or 
the Subject in question.

2.A certificate may fail to meet the semantic constraints imposed by the 
CABF guidelines.

a.Most semantic constraints can be verified by comparing a certificate 
against one or more reference certificates for the Subject.

b.Some semantic constraints cannot be verified by examining a 
certificate, even with reference certificate information.

Most instances of the syntactic of mis-issuance can be detected by 
examining a certificate against a set of criteria extracted from the 
CABF guidelines. Based on whether a certificate purports to be a DV or 
an EV certificate, one can examine it against almost all of the 
syntactic constraints imposed by the guidelines. Appendix A, Section A.1 
enumerates the syntactic criteria to be used in this case. These checks 
can be performed by a log before issuing an SCT, and if a (pre-) 
certificate fails these checks, it should not be issued. This behavior 
is RECOMMENDED to provide feedback to CAs, to detect potential syntactic 
mis-issuance before the certificate is issued.

A few of the syntactic constraints cannot be verified in this fashion, 
e.g., because they require knowledge of the organizational relationships 
between "root" and subordinate CAs (see Section 9.3.3 of 
[CABF-Baseline].) Appendix A, Section A.2, notes these exception and 
notes that, in general, they cannot be checked by a Monitor or log, and 
thus there is no requirement to perform these checks. (A Monitor 
operated by a Subject on its own behalf has access to at least some of 
the data required to verify conformance to this latter set of syntactic 
constraints and thus SHOULD do so.)

Detection of semantic mis-issuance as described in 2a above requires 
access to "reference" certificates associated with a specified Subject. 
(For purposes of this discussion, a reference certificate is a valid 
certificate issued to a specified Subject, consistent with the CABF 
guidelines.) The primary concern addressed by detection of semantic 
mis-issuance is that a certificate has been issued to an entity that is 
not authorized to represent the host (web server) named in the 
certificate Subject field (or subjectAltName extension).

Other forms of semantic mis-issuance (2 b above) may arise due to 
procedural or operational violations of the CABF guidelines, but these 
may not be detectable by a third party, even with access to a reference 
certificate. For example, a Web PKI CA may fail to adhere to the audit 
procedures required in Section 15 of [CABF-Baseline]. CT elements (e.g., 
Monitors) are not able to detect these forms of mis-issuance because 
they are not externally visible.

<Discuss classes of adversaries, motivations, and capabilities>

1.Criminals

2.Hacktivists

3.Nation states (intelligence organizations)

4.Other?

2. Attack Model and Mitigation Mechanisms

Certificate mis-issuance may arise in one of several ways. The ways that 
CT enables a Subject (or others) to redress mis-issuance depends on the 
context of the mis-issuance, and thus it is appropriate to examine the 
context as part of an attack model

2.1 A non-malicious Web PKI CA

If the certificate is submitted to a log prior to issuance (a 
pre-certificate), the (generally) detectable forms of syntactic 
mis-issuance (Section 1, 1.a) will be detected, and the certificate will 
not be logged. Because the CA is non-malicious, it will remedy the 
syntactic problem and re-submit the (pre-) certificate to a log again. 
Thus syntactic mis-issuance of this type will be thwarted.

2.1.1 A CA may issue the certificate to an unauthorized party (Section 
1, 2.a), as a result of an error or because it was the victim of a 
social engineering attack. In this case the CA has a record of the 
certificate and it is prepared to revoke the bogus certificate once it 
has been convinced of its error. If the CA is submitting (pre-) 
certificates for logging, there will be evidence of the mis-issuance in 
one or more logs. If a Monitor is "protecting" the targeted Subject, it 
will detect the mis-issuance, and will alert the Subject. Because the CA 
has a record of the mis-issuance, it should revoke the bogus 
certificate, after investigating, based on the information provided by 
the legitimate certificate Subject. The presence of an embedded SCT in 
the bogus certificate, or an SCT accompanying the bogus certificate does 
not contribute to the mitigation. (See Note 1 below.)

2.1.2 A non-malicious Web PKI CA may be the victim of an undetected 
attack (c.f., DigiNotar) which results in semantic mis-issuance of one 
or more certificates. In this case the CA is not aware of the 
mis-issuance and may have no record of the certificate content.

2.1.2.1 The mis-issued certificate may have been submitted to one or 
more logs prior to issuance, to acquire an embedded SCT, or 
post-issuance to acquire a standalone SCT. In either case, a Monitor 
that is protecting the targeted Subject will detect the bogus 
certificate and alert the targeted Subject. The Subject, in turn, will 
request the CA to revoke the bogus certificate. In this case, the CA 
will depend on the certificate serial number provided via the log entry, 
to effect revocation. (See Notes 1 + 2 below.) If TLS clients reject a 
certificate when no SCT is present, this might motivate the attacker to 
log the bogus certificates, which helps justify such client behavior.

2.1.2.2 The bogus certificate may not have been submitted to any logs. 
In this case, Monitors will not detect the bogus certificate. If clients 
reject a certificate that lacks (or is not accompanied by) an SCT, the 
attacker will be thwarted in this case. (See Note 3 below.)

2.2 A Malicious Web PKI CA

2.2.1 If a certificate is submitted to a log prior to issuance (a 
pre-certificate), the (generally) detectable forms of syntactic 
mis-issuance (Section 1, 1.a) will be detected, and the certificate will 
not be logged. However, because the CA is presumed to be malicious, the 
certificate may be issued anyway. Thus checking for syntactic 
mis-issuance in this case does not, per se, prevent such mis-issuance. 
However, if clients reject a certificate that lacks (or is not 
accompanied by) an SCT, this form of mis-issuance will be thwarted in 
this case.

2.2.2 Because this CA is malicious, it may choose to not submit the 
certificate to a log. This avoids detection of syntactic mis-issuance by 
a log, but it also means there is no SCT for the certificate. However, 
if clients reject a certificate that lacks (or is not accompanied by) an 
SCT, this form of mis-issuance will be thwarted in this case.

2.2.3 The CA may submit the bogus certificate to one or more logs that 
collude with this CA, and thus do not perform syntactic checks. In this 
case the syntactic mis-issuance will not be detected by logs. Unless 
Monitors (or Auditors?) also perform syntactic checks, this form of 
mis-issuance will not be thwarted in this case.

2.2.4 The malicious CA may semantically mis-issue a certificate, that is 
syntactically valid. We will refer to such a certificate as "bogus". 
Because it is syntactically valid, logs will not reject the certificate. 
This situation might result because the CA was bribed or was compelled 
to issue the bogus certificate. (A CA might be compelled to issue a 
bogus certificate by a government agency or a criminal 
organization.)This CA might be one or more tiers below a trust anchor 
(aka root CA).

2.2.4.1 A bogus certificate may not have been submitted to any logs. In 
this case, Monitors will not detect the bogus certificate. If clients 
reject a certificate that lacks (or is not accompanied by) an SCT, the 
attacker will be thwarted in this case. (See Note 3 below.)

2.2.4.2 A bogus certificate may have been submitted to one or more logs 
prior to issuance, to acquire an embedded SCT, or post-issuance, to 
acquire a standalone SCT. In either case, a Monitor protecting the 
targeted Subject will detect a bogus certificate and alert the targeted 
subject. The Subject, in turn, will request the CA to revoke the bogus 
certificate. In this case, the CA may refuse, or substantially delay, to 
revoke the bogus certificate. (It could make excuses about inadequate 
proof that the certificate is bogus, or argue that it cannot quickly 
revoke the certificate because of local, legal concerns, etc.) In this 
case, the CT mechanisms have detected mis-issuance, but the information 
logged by CT does not help remedy the problem. (See Note 4 below.)

2.2.5 A bogus certificate may have been submitted to one or more 
conspiring logs. These logs will issue SCTs, but will hide the log 
entries from some or all Monitors. Any Monitor from which the log is 
hiding data will not detect the bogus certificate, even if it is 
protecting the target Subject. If a client accepts an SCT from a 
conspiring log, then the client will not reject the bogus certificate on 
the basis of a missing SCT. In this case CT will not detect the 
semantically mis-issued certificate. Auditors are intended to detect 
logs that conspire to suppress log entries, based on XXX. [is the 
unspecified gossip protocol need here? If so, then until we have this 
protocol, CT does not provide the necessary info to detect this form of 
mis-issuance.] If Auditors detect conspiring logs, Monitors and clients 
can be alerted to conspiring logs. This would cause clients to not 
accept SCTs generated by these logs, in the future. (See Note 5 below.)

Notes:

1.If a CA submits a bogus certificate to one or more logs, but these 
logs are not watched by a Monitor that is protecting the targeted 
Subject, CT will not mitigate this type of mis-issuance attack. It is 
not clear whether every Monitor MUST offer to track every Subject that 
requests protection. Absent such a guarantee, how do Subjects know which 
set of Monitors will provide "sufficient" coverage. Of course, if a 
Subject acts as its own Monitor, this problem is solved for that Subject.

2.A CA being presented with evidence of a bogus certificate probably 
will require more than the serial number of the bogus certificate. It 
will want to verify the Issuer and Subject (subjectAltname) to ensure 
that the certificate being revoked is not one that it has knowingly 
issued legitimately. Thus a Subject should not expect immediate 
revocation of a contested certificate in all cases. (The time frame in 
which a CA will respond to a revocation request usually is described in 
the CPS for the CA.) Other certificate fields and extensions may be of 
interest for forensic purposes, but are not required to effect 
revocation nor to verify that the certificate to be revoked is bogus, 
based on [CABF-Baseline] criteria. The SCT itself, because it contains a 
timestamp from a third party, is probably valuable for forensic purposes.

3.If a TLS client is to reject a certificate that lacks an embedded SCT, 
or is not accompanied by an SCT transported via the TLS handshake, this 
behavior needs to be defined in a way that is compatible with 
incremental deployment. Issuing a warning to a (human) user is probably 
insufficient, based on experience with warnings displayed for expired 
certificates, lack of certificate revocation status information, and 
similar errors that violate RFC 5280 path validation rules.

4.A targeted Subject might request the parent or the offending CA to 
revoke the certificate of the non-cooperative CA. However, a request of 
this sort may be rejected, e.g., because of the potential for 
significant collateral damage. A browser might be configured to reject 
all certificates issued by the malicious CA, e.g., using a CA hot list 
distributed by a browser vendor. However, if the malicious CA has a 
sufficient number of legitimate clients, treating all of them as bogus 
still represents serious collateral damage. If one can configure a 
browser to reject the specific, bogus certificate identified by a 
Monitor, then the bogus certificate could be rejected in that fashion. 
Moreover, this calls for communication between Monitors and browsers, or 
between Monitors and browser vendors. Such communication is not 
specified. There are no standard ways to configure a browser to reject 
individual bogus certificates. Moreover, a malicious CA could easily 
issue new bogus certificates for the targeted Subject, which would have 
to be detected and rejected in this (as yet unspecified) fashion. Thus, 
for now, CT does not seem to provide a way to mitigate this form of 
attack, even though it provides a basis for detecting such attacks.

5.The combination of a malicious CA and one or more conspiring logs 
motivates the use of Auditors, to detect conspiring logs. If a Monitor 
protecting s Subject does not see mis-issued certificates, it cannot 
alert the Subject. If one or mlore SCTs are present in a certificate, or 
passed via the TLS handshake, a client has no way to know that the 
logged certificate is not visible to Monitors. Only if clients reject 
certificates that contains SCTs from conspiring logs will CT be able to 
deter use of such logs. Thus the means by which Auditors detect such 
logs, and inform TLS clients must be specified. Moreover, if a 
certificate (or TLS handshake) contains more than one SCT, the client 
MUST verify all of them if it is to counter the threat posed by 
conspiring logs.

Absent a "gossip" protocol that enables Auditors to verify that data 
from logs are reported in a consistent fashion to many (all?) Monitors, 
CT does not provide protection against logs that may conspire with, or 
be victims of, attackers effecting certificate mis-issuance. When a 
gossip protocol is defined and deployed, it will be necessary to 
describe how the CT system will deal with a mis-behaving or compromised 
log. For example, will there be a mechanism to alert all TLS clients to 
reject SCTs issued by such a log. Absent a description of a mitigation 
strategy to deal with mis-behaving or compromised logs, CT cannot ensure 
detection of mis-issuance.

Monitors play the critical role in detecting semantic certificate 
mis-issuance, for Subjects that have requested monitoring of their 
certificates. Thus Monitors represent another target for adversaries who 
wish to effect certificate mis-issuance. If a Monitor is compromised by, 
or conspires with, an attacker, it will fail to alert a Subject to a 
mis-issued certificate targeting that Subject. This suggests that a 
Subject SHOULD request certificate monitoring from multiple sources to 
guard against such failures. Operation of a Monitor by a Subject, on its 
own behalf, avoids dependence on third party Monitors, but the burden of 
Monitor operation may be viewed as to great for many web sites, and thus 
this mode of operation ought not be assumed to be universal when 
evaluating protection against Monitor compromise.

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 2 Oct 2014 20:28:28 +0000

Steve,

Thanks.

My primary concern with the analysis is that it does not discuss the practicality  and resources and data required for the monitoring activity.  It is quite possible that monitoring will not be done at all or will miss things or will be ineffective leaving the benefit of CT to largely as a deterrent as opposed to detection mechanism.  Threat analysis may wish to point that out with significant emphasis since 6962 does not seem to emphasize this enough.  I see CAs offering to perform monitoring service, which will not detect problems if the authorized CA or RA are compromised or have gone rogue.  In summary, the last paragraph of the analysis may wish to point out the monitors may require subjects to use secure means to provide a list of valid certificates from time to time and for monitor to check the logs for mis-issuance against this list.  6962 does not address the critical aspect of monitoring from the perspective of checking that the certificates are legitimate.

While just about everyone is against checking the certification path and certificate, but if the goal is to secure Web PKI, to improve user experience or at least protect less informed users from making bad choices when a browser barfs, I would think checking certificate, certification path, and even cipher suites including proper range for RSA public exponent are good things.

On specifics of your analysis, on Note 2, I would think the CA may wish to get the whole certificate to verify that the certificate was issued by it by verifying the signature using its own public keys.

From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2014 1:51 PM
To: [email-masked]
Subject: [Trans] updated definition and attack analysis text

Ignoring (for the moment) the suggestion to not consider syntactic mis-issuance,
and the topic of whether logs might perform syntax checks on certs submitted to them,
I have revised the attack analysis text. It at least provides a sense of the style
and structure one wants in such text, and which is missing from 6962-bis.

I've expanded the definitions of mis-issuance based on the message exchanges
Ben and I had, to more clearly describe the cases of syntactic and semantic
mis-issuance that are outside of the scope for CT, or that may be detectable only
if a Subject operates its own Monitor. I also added structure to group the attack cases,
to make for easier reading. I' ve kept the "notes" style, but these could be folded into
the attack case analysis if desired. (It would just introduce some redundancy.)

Steve

------

1. Goals and Definitions

The goal of Certificate Transparency (CT) is to detect mis-issuance of certificates, in the Web PKI context. It is anticipated that CT will help deter mis-issuance, e.g., by providing information to an affected Subject to facilitate revocation of a mis-issued certificate. The Web PKI context refers to the use of a set of Certification Authorities (CAs) that issue X.509 certificates to web servers to enable TLS-protected access by clients [cite WPKOPS?].

A certificate is characterized as mis-issued if the certificate does not conform to the requirements established by CA Browser Forum (CABF) documents for "domain validation" (DV) or "extended validation" (EV) certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issuance takes two primary forms syntactic mis-issuance and semantic mis-issuance.

1. A certificate may fail to meet the syntactic constraints imposed by the CABF guidelines.

a. Most syntactic constraints from [CABF-Baseline] and [CABF-EV], can be checked via examination of a certificate chain, without reference to Subject-specific or CA-specific data.

b. A few syntactic constraints require access to data specific to a CA or the Subject in question.

2. A certificate may fail to meet the semantic constraints imposed by the CABF guidelines.

a. Most semantic constraints can be verified by comparing a certificate against one or more reference certificates for the Subject.

b. Some semantic constraints cannot be verified by examining a certificate, even with reference certificate information.
Most instances of the syntactic of mis-issuance can be detected by examining a certificate against a set of criteria extracted from the CABF guidelines. Based on whether a certificate purports to be a DV or an EV certificate, one can examine it against almost all of the syntactic constraints imposed by the guidelines. Appendix A, Section A.1 enumerates the syntactic criteria to be used in this case. These checks can be performed by a log before issuing an SCT, and if a (pre-) certificate fails these checks, it should not be issued. This behavior is RECOMMENDED to provide feedback to CAs, to detect potential syntactic mis-issuance before the certificate is issued.

A few of the syntactic constraints cannot be verified in this fashion, e.g., because they require knowledge of the organizational relationships between "root" and subordinate CAs (see Section 9.3.3 of [CABF-Baseline].)  Appendix A, Section A.2, notes these exception and notes that, in general, they cannot be checked by a Monitor or log, and thus there is no requirement to perform these checks. (A Monitor operated by a Subject on its own behalf has access to at least some of the data required to verify conformance to this latter set of syntactic constraints and thus SHOULD do so.)

Detection of semantic mis-issuance as described in 2a above requires access to "reference" certificates associated with a specified Subject. (For purposes of this discussion, a reference certificate is a valid certificate issued to a specified Subject, consistent with the CABF guidelines.) The primary concern addressed by detection of semantic mis-issuance is that a certificate has been issued to an entity that is not authorized to represent the host (web server) named in the certificate Subject field (or subjectAltName extension).

Other forms of semantic mis-issuance (2 b above) may arise due to procedural or operational violations of the CABF guidelines, but these may not be detectable by a third party, even with access to a reference certificate. For example, a Web PKI CA may fail to adhere to the audit procedures required in Section 15 of [CABF-Baseline]. CT elements (e.g., Monitors) are not able to detect these forms of mis-issuance because they are not externally visible.

1. Criminals

2. Hacktivists

3. Nation states (intelligence organizations)

4. Other?

Certificate mis-issuance may arise in one of several ways. The ways that CT enables a Subject (or others) to redress mis-issuance depends on the context of the mis-issuance, and thus it is appropriate to examine the context as part of an attack model

If the certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. Because the CA is non-malicious, it will remedy the syntactic problem and re-submit the (pre-) certificate to a log again. Thus syntactic mis-issuance of this type will be thwarted.

2.1.1 A CA may issue the certificate to an unauthorized party (Section 1, 2.a), as a result of an error or because it was the victim of a social engineering attack. In this case the CA has a record of the certificate and it is prepared to revoke the bogus certificate once it has been convinced of its error. If the CA is submitting (pre-) certificates for logging, there will be evidence of the mis-issuance in one or more logs. If a Monitor is "protecting" the targeted Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, it should revoke the bogus certificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence of an embedded SCT in the bogus certificate, or an SCT accompanying the bogus certificate does not contribute to the mitigation. (See Note 1 below.)

2.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar) which results in semantic mis-issuance of one or more certificates. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content.

2.1.2.1 The mis-issued certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor that is protecting the targeted Subject will detect the bogus certificate and alert the targeted Subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA will depend on the certificate serial number provided via the log entry, to effect revocation. (See Notes 1 + 2 below.) If TLS clients reject a certificate when no SCT is present, this might motivate the attacker to log the bogus certificates, which helps justify such client behavior.

2.1.2.2 The bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.)

2.2.1 If a certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. However, because the CA is presumed to be malicious, the certificate may be issued anyway. Thus checking for syntactic mis-issuance in this case does not, per se, prevent such mis-issuance. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case.

2.2.2 Because this CA is malicious, it may choose to not submit the certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case.

2.2.3 The CA may submit the bogus certificate to one or more logs that collude with this CA, and thus do not perform syntactic checks. In this case the syntactic mis-issuance will not be detected by logs. Unless Monitors (or Auditors?) also perform syntactic checks, this form of mis-issuance will not be thwarted in this case.

2.2.4 The malicious CA may semantically mis-issue a certificate, that is syntactically valid. We will refer to such a certificate as "bogus". Because it is syntactically valid, logs will not reject the certificate. This situation might result because the CA was bribed or was compelled to issue the bogus certificate. (A CA might be compelled to issue a bogus certificate by a government agency or a criminal organization.)  This CA might be one or more tiers below a trust anchor (aka root CA).

2.2.4.1 A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.)

2.2.4.2 A bogus certificate may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a standalone SCT. In either case, a Monitor protecting the targeted Subject will detect a bogus certificate and alert the targeted subject. The Subject, in turn, will request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. (It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc.) In this case, the CT mechanisms have detected mis-issuance, but the information logged by CT does not help remedy the problem. (See Note 4 below.)

2.2.5 A bogus certificate may have been submitted to one or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any Monitor from which the log is hiding data will not detect the bogus certificate, even if it is protecting the target Subject. If a client accepts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the semantically mis-issued certificate. Auditors are intended to detect logs that conspire to suppress log entries, based on XXX. [is the unspecified gossip protocol need here? If so, then until we have this protocol, CT does not provide the necessary info to detect this form of mis-issuance.]  If Auditors detect conspiring logs, Monitors and clients can be alerted to conspiring logs. This would cause clients to not accept SCTs generated by these logs, in the future. (See Note 5 below.)

Notes:

1. If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide "sufficient" coverage. Of course, if a Subject acts as its own Monitor, this problem is solved for that Subject.

2. A CA being presented with evidence of a bogus certificate probably will require more than the serial number of the bogus certificate. It will want to verify the Issuer and Subject (subjectAltname) to ensure that the certificate being revoked is not one that it has knowingly issued legitimately. Thus a Subject should not expect immediate revocation of a contested certificate in all cases. (The time frame in which a CA will respond to a revocation request usually is described in the CPS for the CA.) Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus, based on [CABF-Baseline] criteria. The SCT itself, because it contains a timestamp from a third party, is probably valuable for forensic purposes.

3. If a TLS client is to reject a certificate that lacks an embedded SCT, or is not accompanied by an SCT transported via the TLS handshake, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules.

4. A targeted Subject might request the parent or the offending CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage. A browser might be configured to reject all certificates issued by the malicious CA, e.g., using a CA hot list distributed by a browser vendor. However, if the malicious CA has a sufficient number of legitimate clients, treating all of them as bogus still represents serious collateral damage. If one can configure a browser to reject the specific, bogus certificate identified by a Monitor, then the bogus certificate could be rejected in that fashion. Moreover, this calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication is not specified. There are no standard ways to configure a browser to reject individual bogus certificates. Moreover, a malicious CA could easily issue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) fashion. Thus, for now, CT does not seem to provide a way to mitigate this form of attack, even though it provides a basis for detecting such attacks.

5. The combination of a malicious CA and one or more conspiring logs motivates the use of Auditors, to detect conspiring logs. If a Monitor protecting s Subject does not see mis-issued certificates, it cannot alert the Subject. If one or mlore SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if clients reject certificates that contains SCTs from conspiring logs will CT be able to deter use of such logs. Thus the means by which Auditors detect such logs, and inform TLS clients must be specified. Moreover, if a certificate (or TLS handshake) contains more than one SCT, the client MUST verify all of them if it is to counter the threat posed by conspiring logs.

Absent a "gossip" protocol that enables Auditors to verify that data from logs are reported in a consistent fashion to many (all?) Monitors, CT does not provide protection against logs that may conspire with, or be victims of, attackers effecting certificate mis-issuance. When a gossip protocol is defined and deployed, it will be necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log. Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection of mis-issuance.

Monitors play the critical role in detecting semantic certificate mis-issuance, for Subjects that have requested monitoring of their certificates. Thus Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting that Subject. This suggests that a Subject SHOULD request certificate monitoring from multiple sources to guard against such failures. Operation of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors, but the burden of Monitor operation may be viewed as to great for many web sites, and thus this mode of operation ought not be assumed to be universal when evaluating protection against Monitor compromise.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 03 Oct 2014 15:30:49 -0400

Santosh,
>
> Steve,
>
> Thanks.
>
> My primary concern with the analysis is that it does not discuss the 
> practicality  and resources and data required for the monitoring 
> activity.  It is quite possible that monitoring will not be done at 
> all or will miss things or will be ineffective leaving the benefit of 
> CT to largely as a deterrent as opposed to detection mechanism.  
> Threat analysis may wish to point that out with significant emphasis 
> since 6962 does not seem to emphasize this enough. I see CAs offering 
> to perform monitoring service, which will not detect problems if the 
> authorized CA or RA are compromised or have gone rogue.  In summary, 
> the last paragraph of the analysis may wish to point out the monitors 
> may require subjects to use secure means to provide a list of valid 
> certificates from time to time and for monitor to check the logs for 
> mis-issuance against this list.  6962 does not address the critical 
> aspect of monitoring from the perspective of checking that the 
> certificates are legitimate.
>
I'm happy to specific receive text to add to the analysis. I'll be 
updating it next week
to reflect the revised syntax checking anyway.  Also, I have completed 
an initial cut at
the EV cert syntax rules and pkan to issue a complete Appendix A version 
next week as well.

I agree that a CA that operates a log for itself, or a Monitor for its 
clients seems
questionable. When I think about Monitor services I look at what is 
available today for
address space monitoring. Companies monitor BGP advertisements, from 
open and proprietary
sources, looking for advertisements of prefixes that belong to client. 
If an advertised prefix
does not have the origin AS of the client, it's suspicious. The client 
is informed and can take
action, e.g., contacting the AS that is advertising itself as the origin 
of the client's prefix.
This works reasonable well, but it is a for profit activity, i.e., 
people pay to have their
prefixes monitored. If the designers of CT envision this as a likely 
deployment scenario for
CT, it ought to be mentioned.
>
> While just about everyone is against checking the certification path 
> and certificate, but if the goal is to secure Web PKI, to improve user 
> experience or at least protect less informed users from making bad 
> choices when a browser barfs, I would think checking certificate, 
> certification path, and even cipher suites including proper range for 
> RSA public exponent are good things.
>
I agree. Since I revised my proposal, so that even certs that fail 
syntactic validation are
logged, maybe we can revisit the path validation issue. One could 
imagine adding an error
code to an SCT that noted when the syntax is OK, but path validation 
fails, and why.
>
> On specifics of your analysis, on Note 2, I would think the CA may 
> wish to get the whole certificate to verify that the certificate was 
> issued by it by verifying the signature using its own public keys.
>
Good point. The log entry contains the cert, so it makes sense to 
provide that to the CA
what requesting that the cert be revoked.  I'll make that change.

Steve

---

From: Rick Andrews <[email-masked]>
Date: Fri, 3 Oct 2014 17:29:01 -0700

Steve,

RFC 6962 says "In order to avoid logs being spammed into uselessness, it is required that each chain is rooted in a known CA certificate", and that's a syntactic check, isn't it? So it's not a question of whether logs will perform syntax checks or not, it's a question of how much syntactic checking will be required.

Comments on your text are inline.

-Rick

From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2014 10:51 AM
To: [email-masked]
Subject: [Trans] updated definition and attack analysis text

Steve

------
A certificate is characterized as mis-issued if the certificate does not conform to the requirements established by CA Browser Forum (CABF) documents for "domain validation" (DV) or "extended validation" (EV) certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issuance takes two primary forms syntactic mis-issuance and semantic mis-issuance.
Missing a colon after "forms".

Most instances of the syntactic *form* of mis-issuance can be detected by examining a certificate against a set of criteria extracted from the CABF guidelines. Based on whether a certificate purports to be a DV or an EV certificate, one can examine it against almost all of the syntactic constraints imposed by the guidelines. Appendix A, Section A.1 enumerates the syntactic criteria to be used in this case. These checks can be performed by a log before issuing an SCT, and if a (pre-) certificate fails these checks, it *the SCT* should not be issued. This behavior is RECOMMENDED to provide feedback to CAs, to detect potential syntactic mis-issuance before the certificate is issued.

1. Criminals

2. Hacktivists

4. Other?
Malicious or non-malicious Web PKI CAs operating improperly?

If the certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. Because the CA is non-malicious, it will remedy the syntactic problem and re-submit the (pre-) certificate to a log again. Thus syntactic mis-issuance of this type will be thwarted.
But only if the log behaves as RECOMMENDED above.

2.2 A Malicious Web PKI CA
 2.2.1 If a certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. However, because the CA is presumed to be malicious, the certificate may be issued anyway. Thus checking for syntactic mis-issuance in this case does not, per se, prevent such mis-issuance. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case.
Again, only if the log behaves as RECOMMENDED above.

Notes:

1. If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide "sufficient" coverage. Of course, if a Subject acts as its own Monitor, this problem is solved for that Subject.
This raises the question of how a Monitor is supposed to know about all the logs, when new ones are added, etc.

5. The combination of a malicious CA and one or more conspiring logs motivates the use of Auditors, to detect conspiring logs. If a Monitor protecting *a* Subject does not see mis-issued certificates, it cannot alert the Subject. If one or *more* SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if clients reject certificates that contains SCTs from conspiring logs will CT be able to deter use of such logs. Thus the means by which Auditors detect such logs, and inform TLS clients must be specified. Moreover, if a certificate (or TLS handshake) contains more than one SCT, the client MUST verify all of them if it is to counter the threat posed by conspiring logs.

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 5 Oct 2014 18:37:48 +0000

Steve,

How about the following

"The entity (monitor, subject, or another entity) that is examining the logs for certificate of interest for a subject (i.e., domain) has or obtains a list valid certificates from the subject in a secure manner.   The examining party or the subject must not rely on the authorized CA or RA database for this information or use certificate discovery protocols; this information must be developed by the subject based on the certificates it has obtained and installed.  If the authorized CA or RA database is used to reconcile with the certificates in the log, the mechanism does not detect mis-issuance due to malfeasance on the part of the authorized CA or the RA  or due to compromise of the authorized CA or the RA.  If the authorized CA or RA database is used, it does detect mis-issuance by unauthorized CA.  The examining party must not rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms may also result in mis-issued certificates being added to the list."

From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Friday, October 03, 2014 3:31 PM
To: [email-masked]
Subject: Re: [Trans] updated definition and attack analysis text

Santosh,

Steve,

Thanks.

My primary concern with the analysis is that it does not discuss the practicality  and resources and data required for the monitoring activity.  It is quite possible that monitoring will not be done at all or will miss things or will be ineffective leaving the benefit of CT to largely as a deterrent as opposed to detection mechanism.  Threat analysis may wish to point that out with significant emphasis since 6962 does not seem to emphasize this enough.  I see CAs offering to perform monitoring service, which will not detect problems if the authorized CA or RA are compromised or have gone rogue.  In summary, the last paragraph of the analysis may wish to point out the monitors may require subjects to use secure means to provide a list of valid certificates from time to time and for monitor to check the logs for mis-issuance against this list.  6962 does not address the critical aspect of monitoring from the perspective of checking that the certificates are legitimate.
I'm happy to specific receive text to add to the analysis. I'll be updating it next week
to reflect the revised syntax checking anyway.  Also, I have completed an initial cut at
the EV cert syntax rules and pkan to issue a complete Appendix A version next week as well.

I agree that a CA that operates a log for itself, or a Monitor for its clients seems
questionable. When I think about Monitor services I look at what is available today for
address space monitoring. Companies monitor BGP advertisements, from open and proprietary
sources, looking for advertisements of prefixes that belong to client. If an advertised prefix
does not have the origin AS of the client, it's suspicious. The client is informed and can take
action, e.g., contacting the AS that is advertising itself as the origin of the client's prefix.
This works reasonable well, but it is a for profit activity, i.e., people pay to have their
prefixes monitored. If the designers of CT envision this as a likely deployment scenario for
CT, it ought to be mentioned.

 While just about everyone is against checking the certification path and certificate, but if the goal is to secure Web PKI, to improve user experience or at least protect less informed users from making bad choices when a browser barfs, I would think checking certificate, certification path, and even cipher suites including proper range for RSA public exponent are good things.
I agree. Since I revised my proposal, so that even certs that fail syntactic validation are
logged, maybe we can revisit the path validation issue. One could imagine adding an error
code to an SCT that noted when the syntax is OK, but path validation fails, and why.

 On specifics of your analysis, on Note 2, I would think the CA may wish to get the whole certificate to verify that the certificate was issued by it by verifying the signature using its own public keys.
Good point. The log entry contains the cert, so it makes sense to provide that to the CA
what requesting that the cert be revoked.  I'll make that change.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Oct 2014 11:05:40 -0400

Rick,

> Steve,
>
> RFC 6962 says "In order to avoid logs being spammed into uselessness, 
> it is required that each chain is rooted in a known CA certificate", 
> and that's a syntactic check, isn't it? So it's not a question of 
> whether logs will perform syntax checks or not, it's a question of how 
> much syntactic checking will be required.
>
Good point. Logs do perform some syntax checks, but 6962-bis isn't clear 
on the extent of them.
> Comments on your text are inline.
Thanks for the detailed comments. I have made edits to address all of them.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Oct 2014 11:37:48 -0400

Santosh,
>
> Steve,
>
> How about the following
>
> "The entity (monitor, subject, or another entity) that is examining 
> the logs for certificate of interest for a subject (i.e., domain) has 
> or obtains a list valid certificates from the subject in a secure 
> manner.   The examining party or the subject must not rely on the 
> authorized CA or RA database for this information or use certificate 
> discovery protocols; this information must be developed by the subject 
> based on the certificates it has obtained and installed.  If the 
> authorized CA or RA database is used to reconcile with the 
> certificates in the log, the mechanism does not detect mis-issuance 
> due to malfeasance on the part of the authorized CA or the RA  or due 
> to compromise of the authorized CA or the RA.  If the authorized CA or 
> RA database is used, it does detect mis-issuance by unauthorized CA.  
> The examining party must not rely on certificate discovery mechanisms 
> to build the list of valid certificates since such mechanisms may also 
> result in mis-issued certificates being added to the list."
>
I'll add a version of your text to the discussion of Monitor operation.
>
>
>      While just about everyone is against checking the certification
>     path and certificate, but if the goal is to secure Web PKI, to
>     improve user experience or at least protect less informed users
>     from making bad choices when a browser barfs, I would think
>     checking certificate, certification path, and even cipher suites
>     including proper range for RSA public exponent are good things.
>
I agree, for the most part. Ben was the one who suggested enforcing key 
size constraints, and,
implicitly algs. Ciphersuites are a TLS internal issue, so the best we 
can do is to enforce
constraints on the algs used for cert signing, and the alg in the 
subjectPublicKeyInfo field.

>      On specifics of your analysis, on Note 2, I would think the CA
>     may wish to get the whole certificate to verify that the
>     certificate was issued by it by verifying the signature using its
>     own public keys.
>
I have already made that change, based on one of Rick's comments.

Steve