Subject: [Trans] REMINDER: WGLC started for draft-ietf-trans-threat-analysis

From: Paul Wouters <[email-masked]>
Date: Fri, 4 May 2018 10:06:17 -0400 (EDT)

On Mon, 16 Apr 2018, Paul Wouters wrote:

Reminder that we are almost at the end of the WGLC with zero comments so far.

> This starts a 3 week WGLC for draft-ietf-trans-threat-analysis
>
> Previously, there were some contentious issues regarding the dual CA
> attack that dkg came up with. The current version should address all
> those issues. But since it has been a (very!) long time since this
> document was discussed and consumed, please review the entire document.
>
> https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-13
>
> Paul & Melinda
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 4 May 2018 14:08:30 +0000

I (re)read the document.  It's good.  Ship it.

On 5/4/18, 10:06 AM, "Paul Wouters" <[email-masked]> wrote:

    
    > https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-13
    
    _______________________________________________
    Trans mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/trans

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 4 May 2018 14:51:47 -0400

On 04/16/2018 05:01 PM, Paul Wouters
wrote:

Hi,

Previously, there were some contentious issues regarding the dual
CA

attack that dkg came up with. The current version should address
all

document was discussed and consumed, please review the entire
document.

Paul & Melinda

Hello Paul, Melinda,

I have review the current draft of the threat analysis document and
believe that there are a number of issues that should be addressed
before this document is approved. Below ar ethe comments that I have
on the draft:

The draft discusses three categories of CAs: non-malicious,
malicious, and compromised. However, the categories are
confusing due to the ways in which these terms are used. For
example, it implies that a CA is considered to be compromised
only if an attacker has stolen (purloined) a copy of the CA's
private key. It notes that "a compromised CA is essentially a
malicious CA." The text in Section 3.3 combined with the text
in Section 3.1 seems to explicitly exclude DigiNotar as being
an example of a compromised CA, even though the general
agreement is that what happened to DigiNotar was a compromise
(see https://en.wikipedia.org/wiki/DigiNotar).
It is unclear why Section 3.3 is needed at all, given that
Section 3.1 already addresses cases of compromised CAs.

Section 4 of the document includes a lot of text about
"attacks" involving syntactic mis-issuance, but there is
nothing explain how syntactic mis-issuance could be part of an
attack. The text describes a scenario in which a malicious CA
intentionally issues a certificate that is syntactically
incorrect, the Subject of the certificate reports the problem,
and the CA doesn't take action. No explanation is provided as
to how this could be part of an attack. Can't the Subject just
get a new certificate from a different CA? While it is clear
that there is a benefit to detecting syntactic mis-issuance
and working to have such errors corrected, it is not at all
clear how syntactic mis-issuance could be part of an attack.
Either some explanation of how syntactic mis-issuance could be
used as part of an attack (particularly an attack in which the
Subject is not one of the attackers) or the text about
"attacks" in Section 4 should be removed.

Section 2 begins by saying that "A threat is defined,
traditionally, as a motivated, capable adversary." But, this
is not correct, nor is it consistent with the remainder of
this draft. NISTIR 7298, for example, defines a threat as "the
potential source of an adverse event." This draft is supposed
to describe an attack model and describe threats to the Web
PKI. Mis-issuance (especially syntactic mis-issuance) does not
require an attacker or a motivated, capable adversary.
Mis-issuance may be the result of carelessness, but it is
still a threat, which is why Section 4.1.1.1 discusses
unintentional syntactic mis-issuance. Given that the threat
model includes unintentional mis-issuance, Section 2 needs to
be rewritten to take into account that not all threats involve
"attacks" or "a motivated, capable adversary."

The second paragraph of Section 2 begins "As noted above, the
goals of CT are to deter, detect, and facilitate remediation
of attacks on the web PKI." This is incorrect. What is noted
above is that "Certificate transparency (CT) is a set of
mechanisms designed to detect, deter, and facilitate
remediation of certificate mis-issuance." As noted in the
previous bullet, "certificate mis-issuance" is not the same as
"attack."

Section 2, paragraph 3 refers to "forged web site
certificates," but doesn't explain what "forged" means. Section
1 said that: Throughout the remainder of this document we refer
to a semantically mis-issued certificate as "bogus." So, is a
"forged" certificate something different from a "bogus"
certificate?

The final sentence of Section 1, paragraph 5 says that "This
extension also may be used by a browser to request OCSP
responses from a TLS server with which it is communicating
[RFC6066][RFC6961]." The sentence should be referring to the
"status_request" TLS extension, but the only extension
mentioned before this sentence is the Authority Information
Access (AIA) extension. So, saying "This extension" is
incorrect.

Figure 1 is missing arrows whenever information travels from
right to left.

Section 3.1 says that a CA "may have mis-issued a certificate
as a result of an error." This further suggests that the
"threats" that are covered by this draft are not limited to
ones involving "a motivated, capable adversary."

Section 3.1 (and Section 9.3) contains a link related to the
DigiNotar CA that no longer works.

The organization of Section 3.1 and 3.2 is confusing.
Sometimes self-monitoring subjects and benign third-party
monitors are covered together (in the same section), sometimes
they are covered in separate sections even though there are no
differences between the two, and sometimes the third-party
monitor is overlooked. Sometimes the case of a benign
third-party monitor is covered, but the case of a misbehaving
third-party monitor is overlooked.

Section 3.2.1.2, which is supposed to covered the case in
which the certificate is logged but the log is misbehaving,
says that "These logs may or may not issue SCTs, but will hide
the log entries from some or all Monitors." If a certificate
is logged (which is part of the premise), doesn't that mean
that an SCT must have been issued? So, why does the text say
that "these logs may or may not issue SCTs"?

Section 3.2.2.1, and other places in the document that make
similar statements, should be updated given that at least one
browser is now requiring SCTs for all newly issued
certificates.

As noted previously, if Section 3.3 is to remain, then the
text needs to be modified to make it clear that Section 3.3 is
only about CAs/logs that have had their keys stolen
(compromised) rather than all types of compromise (e.g.,
DigiNotar).

Section 3.3, paragraph 1: The final sentence begins "Section
3.3 explored...," but the sentence seems to be referring to
Section 3.4.

Section 3.3.3 begins "As noted in 3.4.1", but there is no
Section 3.4.1.

Section 3.4, paragraph 3 says "The malicious CA may have
obtained 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." This use of "compromising" seems to be more appropriate
than the use of "compromise" in Section 3.3, as it would
include all forms of compromise, not just cases in which the
attacker had stolen a copy of the CA's key.

Section 3.5 seems unnecessary, as Section 3.2.1.1.1 already
explained that a malicious CA may provide different status
information to different entities.

The final paragraph of Section 3.5 is unrelated to the rest
of the section and seems to be related to the content of
Section 3.4.

Section 4.1 should be reorganized. Sections 4.1.1.3 and
4.1.1.4 fall within 4.1.1 (Certificate Logged), but the
contents of Sections 4.1.1.3 and 4.1.1.4 do not depend on
whether or not the certificate was logged.

Section 4.1.1.2 says that "A log or Monitor that is
conspiring with the attacker," but it is not clear what
attacker there is in the scenario being described.

Section 4.1.1.4 says "Unfortunately, experience suggests that
many browsers do not perform thorough syntactic checks on
certificates, and so it seems unlikely that browsers will be a
reliable way to detect erroneous certificates." and Section
4.2.1.4 says "As noted above (4.1.1.4), most browsers fail to
perform thorough syntax checks on certificates." These
sentences should be removed or modified. There is no reason
that a browser should perform thorough syntactic checks on
certificates, and there are good reasons for browsers not to.
So, this document should not be labeling this as unfortunate
or a failure. We do not want to encourage browsers to perform
thorough syntax checks on certificates, as this could lead to
the same types of problems that TLS has experienced, where
making a change in something causes deployed products to
break.

The first paragraph of Section 4.2.1.1 includes references to
two personal drafts that have long since expired.

Section 4.2.1.3 should not fall within Section 4.2.1, since
the contents do not depend on whether or not the certificate
was logged.

Section 4.2.2 says "Since certificates are not logged in this
scenario, a Monitor (third-party or self) cannot detect the
issuance of an erroneous certificate." This is untrue. Section
4 is about certificates that are erroneous, but not bogus.
This means that the Subject identified in the certificate has
a copy of the certificate. So, the Subject can check the
certificate for syntactic errors regardless of whether the
certificate is logged. Similarly, as noted in Section 5.6, the
Subject will provide a copy of the certificate to any
third-party Monitor, so any third-party Monitor would also be
able to check the certificate for syntactic errors.

Section 4.2.2 says "However, even if errors are detected and
reported to the CA, a malicious/conspiring CA may do nothing
to fix the problem or may delay action." As noted previously,
no explanation is provided as to why this is a threat or
attack. If the Subject knows that there are errors in the
certificate, then the Subject can just get another certificate
(from a different CA, if necessary). It doesn't matter whether
the CA revokes the erroneous certificate or not.

Section 5.3 says

It also will likely require the targeted Subject
to provide assurances that it is the authorized entity
representing the Subject name (subjectAltname) in question.
Thus a Subject should not expect immediate revocation of a
contested certificate.  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 or erroneous, based on
applicable criteria.

This text seems to say that only the "Subject name
(subjectAltname)" is required "verify that the certificate
to be revoked is ... erroneous." This cannot be correct, as
a syntactic check a certificate would be looking for errors
in many fields and extensions other than "Subject name
(subjectAltname)."

Section 5.4 (and similar text elsewhere in the document)
seems out of date given that at least one browser now rejects
any newly issued certificates that are not accompanied by an
SCT.

Section 5.6, paragraph 4 says that "A Monitor must not rely
on certificate discovery mechanisms to build the list of valid
certificates since such mechanisms might result in bogus or
erroneous certificates being added to the list." What would be
the risk if an erroneous certificate was added to the list?
When a Monitor is obtaining a list of certificates for the
Subject to be monitored, wouldn't we want erroneous
certificates to be included in that list so that the Monitor
has a chance to detect the error?

Section 5.6, paragraph 5 says "If a Monitor is compromised
by, or conspires with, an attacker, it will fail to alert a
Subject to a bogus or erroneous certificate targeting that
Subject, as noted above." As noted previously, this document
needs to explain how an attacker can "target" a Subject with
an erroneous certificate.

---

From: Andrew Ayer <[email-masked]>
Date: Mon, 7 May 2018 12:29:41 -0700

draft-ietf-trans-threat-analysis-13 has a number of issues that ought
to be fixed before it's published.

A. Logs do not check for syntactic misissuance

Sections 4.1.1.1 and 4.2.1.1 give the impression that logs check,
or ought to check, submitted certificates for syntactic misissuance.
Page 20 says that syntactic misissuance will be detected "only if" a
(pre-)certificate is submitted to a log that performs syntactic checks.

This is not an intended function of logs, and not a single one of the
58 logs currently in operation performs syntactic misissuance checks.
Furthermore, having logs perform this function would violate separation
of concerns.  Instead, monitors perform syntactic misissuance checks.
crt.sh, for instance, runs all certificates through several certificate
linters.

Page 20 says that "syntactic checking [of pre-certificates] by a log
helps avoid issuance of an erroneous certificate."  This is contrary to
RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate
is a binding commitment by the CA to issue a certificate.  It would
be dangerous for a CA to follow the advice on page 20, as browsers
rightly consider misissuance of a pre-certificate to be equivalent to
misissuance of a real certificate.  CAs must perform syntactic checks on
the TBSCertificate prior to signing anything.

Section 4.2.1.1 is premised on two I-Ds that were not adopted by trans
and have expired.

I suggest that sections 4.1.1.1 and 4.2.1.1 be removed entirely.

B. Conflation of log misbehavior and CA misbehavior

Page 4 says that if a bogus SCT is discovered, it would trigger
a revocation request.  Page 26 says that browsers need to "reject
certificates that contain SCTs from conspiring logs."

Page 3 says "if an RP verified that a certificate that claims to have
been logged has a valid log entry, the RP would have a higher degree of
confidence that the certificate is genuine."

But behavior of a log says nothing about whether a certificate was
properly issued.  A properly-issued certificate might be logged to a
a misbehaving log, and a misissued certificate might be logged to a
well-behaved log.

Therefore, browsers should not consider a certificate more likely to
be genuine just because it's logged, and if a certificate contains an
embedded SCT from a log that's known to be bad, the browser should reject
only that SCT, and still check SCTs from other logs.  And there is no need
to revoke a properly-issued certificate just because it's submitted to
a log that misbehaves.

Section 5.3 says that "evidence of a bogus or erroneous certificate"
can be "in the form of a log entry and/or SCT."  An SCT is irrelevant
for this, as it attests only to log behavior.

C. Response to log misbehavior

On pages 4, 9, and 13, the draft says that monitors should not "trust"
or "rely upon" misbehaving logs.  But monitors don't trust or distrust
logs - they just view logs as a source of certificates.  Browsers, on
the other hand, do trust and distrust logs.  For example, after two logs
(WoSign and Startcom) issued bad SCTs, they were distrusted by Chrome, but
Cert Spotter and crt.sh continued monitoring them until they shut down.

The document should be updated to remove mention of monitors trusting or
relying upon logs, and to make clear that the primary response to a
misbehaving log is for browsers to distrust it.

D. Signature/chain mutation attack

There's another way a log can misbehave which ought to be mentioned in
section 3.1.1.2.  A misbehaving log that conspires with a CA could log
a misissued certificate, but mutate the certificate's signature or chain
such that the certificate is no longer cryptographically attributable to
the CA.  The CA could then plausibly deny that it issued the certificate.
Since the signature and chain are not part of the Merkle Tree, the SCT
will be accepted by browsers and be auditable, despite the log entry
being mutated and useless for responding to the misissuance.

Monitors should be sure to validate the signature and chain of logged
certificates so that this misbehavior can be detected.

E. Chrome is requiring SCTs now

As David A. Cooper pointed out, Chrome is now requiring new certificates
to contain SCTs, so sections 3.1.2.2, 3.2.2.1, and 5.4 need updates.

F. Organization

The organization of the draft seems sub-optimal.  At a high level, the
document is broken up into semantic and syntactic misissuance, and then
into malicious vs non-malicious CA.  Within these categories, the document
discusses the implications when the certificate is logged, not logged,
or when the log is misbehaving.  Very often, these implications are the
same regardless of the type of misissuance or the culpability of the CA.
As a result, there is a lot of duplication, often with minor differences
in wording, which makes the document harder to understand.

I think the structure of section 5, which discusses issues as standalone
concepts, is a better model.  Alternatively, the duplication could be
removed from sections 3 and 4 and replaced by references to prior sub-sections.

G. Minor comments

Page 3 says "'bad-CA-lists' a CA as noted above".  "Bad-CA-list" hasn't
been defined and doesn't appear to be noted above.

Page 3 talks about "validat[ing]" an SCT, which is ambiguous, as it
could refer to checking the SCT's signature, or auditing the SCT for
inclusion. I suggest replacing "validates" with "audits" and replacing
"is invalid" (in the same sentence) with "fails auditing."

Page 4 says that "a CA benefits from CT when it detects a (mis-issued)
certificate that represents the same Subject name as a legitimate
certificate issued by the CA." How is a CA supposed to know if the
certificate is misissued or not?

Page 10 says that a monitor/auditor will detect a misbehaving log when
it "sees the bogus certificate."  It also needs to see the SCT.

Section 3.1.2.1 talks about a Subject being able to detect the lack of
an SCT in a certificate that it is issued.  Since this is part of the
section on "Semantic misissuance," which is defined in the Introduction
as a certificate issued to someone who isn't the Subject, it's unclear
to me what the point of this sub-section is. A Subject, by definition,
would never be issued a semantically misissued certificate.

Section 3.3.1 ends with "If the bogus certificate is detected and
logged, browsers that require an SCT will reject the bogus certificate."
Wouldn't the logging of a certificate cause an SCT to be issued, and
thus allow it to be *accepted* by browsers that require an SCT?

The last paragraph of section 3.5 talks about the attack in 3.4 and
should be moved.

---

From: Andrew Ayer <[email-masked]>
Date: Mon, 7 May 2018 12:56:52 -0700

On Fri, 4 May 2018 14:51:47 -0400
"David A. Cooper" <[email-masked]> wrote:

> Section 4.1.1.4 says "Unfortunately, experience suggests that many
> browsers do not perform thorough syntactic checks on certificates, and so
> it seems unlikely that browsers will be a reliable way to detect erroneous
> certificates." and Section 4.2.1.4 says "As noted above (4.1.1.4), most
> browsers fail to perform thorough syntax checks on certificates." These
> sentences should be removed or modified. There is no reason that a
> browser should perform thorough syntactic checks on certificates, and
> there are good reasons for browsers not to. So, this document should
> not be labeling this as unfortunate or a failure. We do not want to
> encourage browsers to perform thorough syntax checks on certificates, as
> this could lead to the same types of problems that TLS has experienced,
> where making a change in something causes deployed products to break.

The trend in Firefox and Chrome is to make their certificate validators
much stricter about "syntactic" errors.  I think the main point of
section 4.1.1.4 is that it's not feasible for browsers to notify other
parties when it detects a syntactically misissued certificate, so these
checks need to be performed by monitors.

I think this sentence should just be dropped, as it's not true anymore
and tries to moralize about a controversial issue.

> Section 5.6, paragraph 4 says that "A Monitor must not rely on certificate
> discovery mechanisms to build the list of valid certificates since such
> mechanisms might result in bogus or erroneous certificates being added
> to the list." What would be the risk if an erroneous certificate was
> added to the list? When a Monitor is obtaining a list of certificates
> for the Subject to be monitored, wouldn't we want erroneous certificates
> to be included in that list so that the Monitor has a chance to detect
> the error?

Monitors look for subject names, not specific certificates.  The list
of valid certificates is so the monitor doesn't raise an alarm when it
finds a legitimate certificate for a monitored subject name.

So the answer to your first question is that the monitor would fail
to alert the Subject about an erroneous certificate.  This could be
clarified in section 5.6.

The answer to your second question is that the monitor would still
detect erroneous certificates, because it's monitoring based on subject
name.  This seems to be clear already from the description of a monitor
in the introduction.

Regards,
Andrew

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 7 May 2018 16:48:44 -0400

I think it's fine for browsers to check for syntactic errors in 
certificates. However, I interpreted "thorough syntactic checks on 
certificates" to mean that browsers should be performing checks such as 
the ones described in 
https://tools.ietf.org/html/draft-kent-trans-domain-validation-cert-checks 
and 
https://tools.ietf.org/html/draft-kent-trans-extended-validation-cert-checks.

Most of the checks in these drafts are fine, as they are checks for 
requirements that are unlikely to change. However, some of the checks 
are more problematic. For example, the first of these drafts say that 
for DV certificates

             if the [subject] name does not contain an organizationName 
attribute,
             then the streetAddress attribute MUST NOT be present. If
             the organizationName attribute is present, the streetAddress
             attribute MAY be present.  This requirement is derived from
             section 9.2.4b of [CABF-DV].

What if a browser implemented a check for this and then the CA/Browser 
Forum later updated their Baseline Requirements to allow a streetAddress 
attribute in the subject fields of certificates that do not contain an 
organizationName attribute? This wouldn't cause a problem for users who 
keep their browsers up to date, but some clients continue to use 
browsers that are very old.

Section 5.6 says that the Monitor needs to obtain a list of certificates 
for the Subject to use as a reference, and then it says that "A Monitor 
must not rely on certificate discovery mechanisms to build the list of 
valid certificates since such mechanisms might result in bogus or 
erroneous certificates being added to the list." The phrase "or 
erroneous" should be removed.

There is no risk if the Monitor adds an erroneous certificate (that is 
not bogus) to the list of valid certificates, as it will not not mean 
"that the monitor would fail to alert the Subject about an erroneous 
certificate." If a Monitor is going to perform syntactic checks on 
certificates, then it should check all certificates for syntactic 
errors, regardless of how they came into its possession, even 
certificates that are received from the Subject in a secure manner for 
the purpose of creating a reference list of non-bogus certificates.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 09 May 2018 08:49:01 -0400

I have review the current draft of the threat analysis document and believe that there are a number of issues that should be addressed before this document is approved. Below ar ethe comments that I have on the draft:

I believe the current last call was intended to solicit comments only on the changes made since the -012 version, since prior last calls solicited comments on the rest of this I-D months ago. It appears that almost all of your comments are on other parts of the document. Nonetheless, many of your comments identified valid points that merit charges to the text, as noted in my responses below.

- The draft discusses three categories of CAs: non-malicious, malicious, and compromised. However, the categories are confusing due to the ways in which these terms are used. For example, it implies that a CA is considered to be compromised only if an attacker has stolen (purloined) a copy of the CA's private key. It notes that "a compromised CA is essentially a malicious CA." The text in Section 3.3 combined with the text in Section 3.1 seems to explicitly exclude DigiNotar as being an example of a compromised CA, even though the general agreement is that what happened to DigiNotar was a compromise (see https://en.wikipedia.org/wiki/DigiNotar). It is unclear why Section 3.3 is needed at all, given that Section 3.1 already addresses cases of compromised CAs.

The primary distinction is between malicious and non-malicious CAs (Sections 3.1 and 3.2), as noted near the end of Section 1 (where the general outline for the taxonomy is presented). Compromised CAs are nominally non-malicious, but they act as though they were malicious, until the compromise is detected. That motivates Section 3.3 discussing undetected compromise. I agree that there is some overlap between 3.2 and 3.3, but I think it is helpful to explore undetected compromise separately. I also agree that the DigiNotar case is an example of a compromised CA, and so I will move the reference to it to Section 3.3. I also will change text in 3.3 to state that a compromise might not require an attacker to have acquired the private key per se.

- Section 4 of the document includes a lot of text about "attacks" involving syntactic mis-issuance, but there is nothing explain how syntactic mis-issuance could be part of an attack. The text describes a scenario in which a malicious CA intentionally issues a certificate that is syntactically incorrect, the Subject of the certificate reports the problem, and the CA doesn't take action. No explanation is provided as to how this could be part of an attack. Can't the Subject just get a new certificate from a different CA? While it is clear that there is a benefit to detecting syntactic mis-issuance and working to have such errors corrected, it is not at all clear how syntactic mis-issuance could be part of an attack. Either some explanation of how syntactic mis-issuance could be used as part of an attack (particularly an attack in which the Subject is not one of the attackers) or the text about "attacks" in Section 4 should be removed.

You raise an interesting question. I originally assumed that mis-issuance referred only to certificates that misrepresented the identity of the certificate holder or included bogus info intended to mislead relying parties. Several years ago I requested Ben to clarify what constituted mis-issuance. The term was (and is still) used throughout 6962-bis without definition. (I’m surprised that this lack of a definition for such a critical term in 6962-bis hasn’t merited a comment from you to the authors of that document!) Ben replied that a certificate that violated the syntax imposed by a criteria such as the CABF would qualify as mis-issued. That’s why syntactic mis-issuance became an element of this analysis. Violating the syntax rules imposed by such criteria might cause processing problems for browsers that would have adverse consequences. Perhaps what concerned Ben was the observation that, if a CA issues a certificate not consistent with its advertised syntax criteria, that merits detection by CT, as an example of CA misbehavior.

- Section 2 begins by saying that "A threat is defined, traditionally, as a motivated, capable adversary." But, this is not correct, nor is it consistent with the remainder of this draft. NISTIR 7298, for example, defines a threat as "the potential source of an adverse event." This draft is supposed to describe an attack model and describe threats to the Web PKI. Mis-issuance (especially syntactic mis-issuance) does not require an attacker or a motivated, capable adversary. Mis-issuance may be the result of carelessness, but it is still a threat, which is why Section 4.1.1.1 discusses unintentional syntactic mis-issuance. Given that the threat model includes unintentional mis-issuance, Section 2 needs to be rewritten to take into account that not all threats involve "attacks" or "a motivated, capable adversary."

The definition of threat used here has been employed for a long time, e.g., in the U.S. DoD, decades before the publication of NISTIR 7298. Several, easily found examples (thanks to a quick Google search) include the syllabus for Cornell CS 5430, for MIT course 6.805, the NRC Report “Who Goes There: Authentication Through the Lens of Privacy”, …  Mis-issuance is not a threat; it is an example of an attack. If the mis-issuance is the result of an error, then no adversary is involved. To help clarify the first paragraph of Section 2, will be revised: “Nonetheless, it is useful to document perceived threats against a system to provide a context for understanding attacks (even though some attacks may be the result of errors, not threats).”

- Them second paragraph of Section 2 begins "As noted above, the goals of CT are to deter, detect, and facilitate remediation of attacks on the web PKI." This is incorrect. What is noted above is that "Certificate transparency (CT) is a set of mechanisms designed to detect, deter, and facilitate remediation of certificate mis-issuance." As noted in the previous bullet, "certificate mis-issuance" is not the same as "attack."

Fair point- The text will be changed to reiterate that deterrence, detection and remediation of mis-issuance as the goal.

- Section 2, paragraph 3 refers to "forged web site certificates," but doesn't explain what "forged" means. Section 1 said that: Throughout the remainder of this document we refer to a semantically mis-issued certificate as "bogus." So, is a "forged" certificate something different from a "bogus" certificate?

Fair point- The instances of “forged” will be changed to “bogus”.

- The final sentence of Section 1, paragraph 5 says that "This extension also may be used by a browser to request OCSP responses from a TLS server with which it is communicating [RFC6066][RFC6961]." The sentence should be referring to the "status_request" TLS extension, but the only extension mentioned before this sentence is the Authority Information Access (AIA) extension. So, saying "This extension" is incorrect.

Good catch- The text in this sentence will be revised to refer to “The data from this extension …”

- Figure 1 is missing arrows whenever information travels from right to left.

Good point- The right to left arrows will be fixed.

- Section 3.1 says that a CA "may have mis-issued a certificate as a result of an error." This further suggests that the "threats" that are covered by this draft are not limited to ones involving "a motivated, capable adversary."

Not all attacks are the result of a threat, and attacks are not the same as threats. Thus no changes are planned in response this comment.

- Section 3.1 (and Section 9.3) contains a link related to the DigiNotar CA that no longer works.

Good catch- The link in 3.1 will be removed, leaving only the reference number. The Section 9.3 URI will be replaced with https://en.wikipedia.org/wiki/DigiNotar

- The organization of Section 3.1 and 3.2 is confusing. Sometimes self-monitoring subjects and benign third-party monitors are covered together (in the same section), sometimes they are covered in separate sections even though there are no differences between the two, and sometimes the third-party monitor is overlooked. Sometimes the case of a benign third-party monitor is covered, but the case of a misbehaving third-party monitor is overlooked.

Separate subsections were created when there are meaningful differences in cases involving self-monitoring vs. third party m monitors, etc. But, when these distinctions do not matter, the subsections have been merged, and the text explains this. No changes are planned in response to this comment.

- Section 3.2.1.2, which is supposed to covered the case in which the certificate is logged but the log is misbehaving, says that "These logs may or may not issue SCTs, but will hide the log entries from some or all Monitors." If a certificate is logged (which is part of the premise), doesn't that mean that an SCT must have been issued? So, why does the text say that "these logs may or may not issue SCTs"?

Fair point- the text will be changed to remove the reference to not issuing an SCT.

- Section 3.2.2.1, and other places in the document that make similar statements, should be updated given that at least one browser is now requiring SCTs for all newly issued certificates.

One browser does not the Internet make. Moreover, the text in 6962-bis is rather “flexible” with regard to what a browser MUST do, e.g., “It is up to a client's local policy to specify the quantity and form of evidence (SCTs, inclusion proofs or a combination) needed to achieve compliance and how to handle non-compliance.”  Thus no changes are planned in response to this comment.

- As noted previously, if Section 3.3 is to remain, then the text needs to be modified to make it clear that Section 3.3 is only about CAs/logs that have had their keys stolen (compromised) rather than all types of compromise (e.g., DigiNotar).

Changes to 3.2 and 3.3 (as noted in response to comment #1) address this comment.

- Section 3.3, paragraph 1: The final sentence begins "Section 3.3 explored...," but the sentence seems to be referring to Section 3.4.

Good catch- The reference will be changed to 3.4

- Section 3.3.3 begins "As noted in 3.4.1", but there is no Section 3.4.1.

Fair point- This reference will be changed to “Section 3.4”.

- Section 3.4, paragraph 3 says "The malicious CA may have obtained certificates from the two parents by applying to them for the certificates, or by compromisingthe parent CAs and creating the certificates without the knowledge of the CAs." This use of "compromising" seems to be more appropriate than the use of "compromise" in Section 3.3, as it would include all forms of compromise, not just cases in which the attacker had stolen a copy of the CA's key.

Changes to text in 3.3 will address this comment.

- Section 3.5 seems unnecessary, as Section 3.2.1.1.1 already explained that a malicious CA may provide different status information to different entities.

No changes are planned in response to this comment.

- The final paragraph of Section 3.5 is unrelated to the rest of the section and seems to be related to the content of Section 3.4.

This text was added in response to a comment ion the list (by Rob, I believe) who wanted this document to note that the cited revocation status distribution problems might be addressed by mechanisms not specified by 6962-bis. Thus no changes are planned in response to this comment.

- Section 4.1 should be reorganized. Sections 4.1.1.3 and 4.1.1.4 fall within 4.1.1 (Certificate Logged), but the contents of Sections 4.1.1.3 and 4.1.1.4 do not depend on whether or not the certificate was logged.

Fair point – a new section (4.1.3) will be created to address circumstances in which certificate logging is not a factor, and the two sections noted above will be moved there.

- Section 4.1.1.2 says that "A log or Monitor that is conspiring with the attacker," but it is not clear what attacker there is in the scenario being described.

The attacker is one who wants a syntactically mis-issued certificate to not be detected and revoked.

- Section 4.1.1.4 says "Unfortunately, experience suggests that many browsers do not perform thorough syntactic checks on certificates, and so it seems unlikely that browsers will be a reliable way to detect erroneous certificates." and Section 4.2.1.4 says "As noted above (4.1.1.4), most browsers fail to perform thorough syntax checks on certificates." These sentences should be removed or modified. There is no reason that a browser should perform thorough syntactic checks on certificates, and there are good reasons for browsers not to. So, this document should not be labeling this as unfortunate or a failure. We do not want to encourage browsers to perform thorough syntax checks on certificates, as this could lead to the same types of problems that TLS has experienced, where making a change in something causes deployed products to break.

It seems likely that the primary reason that browsers fail to perform thorough syntactic checks on certificates is because, at least historically, some CAs fail to issue syntactically valid certificates. This failure by browsers flies in the face of PKIX standards; you, as one who usually insists that failures to follow standards ought to be a capital crime, have no basis for criticizing this text. No changes will be made in response to this comment.

- The first paragraph of Section 4.2.1.1 includes references to two personal drafts that have long since expired.

Fair point- The offending references will be removed.

- Section 4.2.1.3 should not fall within Section 4.2.1, since the contents do not depend on whether or not the certificate was logged.

Fair point- The text from 4.2.1.3 will be moved to 4.2, and 4.2.1.4 will be relabeled 4.2.1.3.

- Section 4.2.2 says "Since certificates are not logged in this scenario, a Monitor (third-party or self) cannot detect the issuance of an erroneous certificate." This is untrue. Section 4 is about certificates that are erroneous, but not bogus. This means that the Subject identified in the certificate has a copy of the certificate. So, the Subject can check the certificate for syntactic errors regardless of whether the certificate is logged. Similarly, as noted in Section 5.6, the Subject will provide a copy of the certificate to any third-party Monitor, so any third-party Monitor would also be able to check the certificate for syntactic errors.

Fair point- This section will be reworded to note that a third-party Monitor, upon receipt of a certificate from a Subject, could check it for syntactic consistency, IF it is informed of the type of certificate being Monitored. The text already notes that a Subject MAY detect syntax errors by examining the certificate issued to it.

- Section 4.2.2 says "However, even if errors are detected and reported to the CA, a malicious/conspiring CA may do nothing to fix the problem or may delay action." As noted previously, no explanation is provided as to why this is a threat or attack. If the Subject knows that there are errors in the certificate, then the Subject can just get another certificate (from a different CA, if necessary). It doesn't matter whether the CA revokes the erroneous certificate or not.

See previous comment on why syntactic mis-issuance is included in this document.

- Section 5.3 says

o   It also will likely require the targeted Subject to provide assurances that it is the authorized entity representing the Subject name (subjectAltname) in question.  Thus a Subject should not expect immediate revocation of a contested certificate.  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 or erroneous, based on applicable criteria.

This text seems to say that only the "Subject name (subjectAltname)" is required "verify that the certificate to be revoked is ... erroneous." This cannot be correct, as a syntactic check a certificate would be looking for errors in many fields and extensions other than "Subject name (subjectAltname)."

Fair point- The sentence will, be truncated after “to effect revocation”.

- Section 5.4 (and similar text elsewhere in the document) seems out of date given that at least one browser now rejects any newly issued certificates that are not accompanied by an SCT.

See prior comment on why one browser’s behavior is not viewed as sufficient to merit a change to this and similar text.

- Section 5.6, paragraph 4 says that "A Monitor must not rely on certificate discovery mechanisms to build the list of valid certificates since such mechanisms might result in bogus or erroneous certificates being added to the list." What would be the risk if an erroneous certificate was added to the list? When a Monitor is obtaining a list of certificates for the Subject to be monitored, wouldn't we want erroneous certificates to be included in that list so that the Monitor has a chance to detect the error?

The text about not relying on certificate discovery mechanisms was added explicitly at the behest of Santosh. If he does not choose to explain his reasoning the sentence will be removed.

- Section 5.6, paragraph 5 says "If a Monitor is compromised by, or conspires with, an attacker, it will fail to alert a Subject to a bogus or erroneous certificate targeting that Subject, as noted above." As noted previously, this document needs to explain how an attacker can "target" a Subject with an erroneous certificate.

As noted above, Ben insisted that syntactically erroneous certificates were considered mis-issued, and hence motivated inclusion of the text in Section 4.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 May 2018 10:59:42 -0400 (EDT)

On Wed, 9 May 2018, Stephen Kent wrote:

> I believe the current last call was intended to solicit comments only on the changes made since the -012 version, since prior last calls solicited comments on the
> rest of this I-D months ago.

No. Any WGLC is about the entire document, and everyone is free and
encouraged to comment about the entire document. The IETF has no process
of last calling a part of a draft.

I encourage everyone to read the entire document and comment.  Especially,
since the document has been dormant for so long.

Paul

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 10 May 2018 14:37:07 -0400

On 05/09/2018 08:49 AM, Stephen Kent
wrote:

Section 4.1.1.4 says
"Unfortunately, experience suggests that many browsers do
not perform thorough syntactic checks on certificates, and
so it seems unlikely that browsers will be a reliable way to
detect erroneous certificates." and Section 4.2.1.4 says "As
noted above (4.1.1.4), most browsers fail to perform
thorough syntax checks on certificates." These sentences
should be removed or modified. There is no reason that a
browser should perform thorough syntactic checks on
certificates, and there are good reasons for browsers not
to. So, this document should not be labeling this as
unfortunate or a failure. We do not want to encourage
browsers to perform thorough syntax checks on certificates,
as this could lead to the same types of problems that TLS
has experienced, where making a change in something causes
deployed products to break.

It seems likely
that the primary reason that browsers fail to perform
thorough syntactic checks on certificates is because,
at least historically, some CAs fail to issue
syntactically valid certificates. This failure by
browsers flies in the face of PKIX standards; you, as
one who usually insists that failures to follow
standards ought to be a capital crime, have no basis
for criticizing this text. No changes will be made in
response to this comment.

If only I had a nickel for every time you made some false accusation
about me, I'd be retired by now.

Please see the message below, which I sent to mail list before you
sent your response above.

Even in your response yesterday you said that "a certificate that
violated the syntax imposed by a criteria such as the CABF would
qualify as mis-issued," so the document does not intend to suggest
that syntactic checks are just about PKIX standards, they are also
about certificate profiles, which are subject to change.

This isn't about accommodating CAs that issue certificates
incorrectly, but about acknowledging that (1) certificate profiles
can change over time and (2) some clients will continue to use
browsers that are very old.

-------- Forwarded Message --------

Subject:

Re: [Trans] WGLC started for
draft-ietf-trans-threat-analysis

Date:

Mon, 7 May 2018 16:48:44 -0400

From:

David A. Cooper <[email-masked]>

To:

Andrew Ayer <[email-masked]>

CC:

Paul Wouters <[email-masked]>, Trans
<[email-masked]>, Melinda Shore
<[email-masked]>

I think it's fine for browsers to check for syntactic errors in
certificates. However, I interpreted "thorough syntactic checks on
certificates" to mean that browsers should be performing checks
such as the ones described in
https://tools.ietf.org/html/draft-kent-trans-domain-validation-cert-checks
and
https://tools.ietf.org/html/draft-kent-trans-extended-validation-cert-checks.

Most of the checks in these drafts are fine, as they are checks
for requirements that are unlikely to change. However, some of the
checks are more problematic. For example, the first of these
drafts say that for DV certificates

if the [subject] name does not contain an
organizationName attribute,

then the streetAddress attribute MUST NOT be present.
If

the organizationName attribute is present, the
streetAddress

attribute MAY be present.  This requirement is
derived from

What if a browser implemented a check for this and then the
CA/Browser Forum later updated their Baseline Requirements to
allow a streetAddress attribute in the subject fields of
certificates that do not contain an organizationName attribute?
This wouldn't cause a problem for users who keep their browsers up
to date, but some clients continue to use browsers that are very
old.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 10 May 2018 14:46:20 -0400

I have been unable to find anywhere in
my comments where I suggested that syntactic mis-issuance should
not be discussed in the document. The "responses" you provided
have nothing to do with my comments.

On 05/09/2018 08:49 AM, Stephen Kent wrote:

Section 4.2.2 says
"However, even if errors are detected and reported to the
CA, a malicious/conspiring CA may do nothing to fix the
problem or may delay action." As noted previously, no
explanation is provided as to why this is a threat or
attack. If the Subject knows that there are errors in the
certificate, then the Subject can just get another
certificate (from a different CA, if necessary). It doesn't
matter whether the CA revokes the erroneous certificate or
not.

See previous
comment on why syntactic mis-issuance is included in
this document.

Section 5.6, paragraph 5
says "If a Monitor is compromised by, or conspires with, an
attacker, it will fail to alert a Subject to a bogus or
erroneous certificate targeting that Subject, as noted
above." As noted previously, this document needs to explain
how an attacker can "target" a Subject with an erroneous
certificate.

As noted above,
Ben insisted that syntactically erroneous certificates
were considered mis-issued, and hence motivated
inclusion of the text in Section 4.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 May 2018 11:26:08 -0400

Andrew,

Thanks for taking the time to review the document and for the nice organization of your comments.

Sections 4.1.1.1 and 4.2.1.1 give the impression that logs check, or ought to check, submitted certificates for syntactic misissuance. Page 20 says that syntactic misissuance will be detected "only if" a (pre-)certificate is submitted to a log that performs syntactic checks. 

There was no intent to suggest that logs do or ought to perform syntax checks. Sorry for any confusion in that regard. I did find several places where uppercase reserved words appear, which is inappropriate for an informational RFC. I will change all of these to lowercase. 

Also, note that 6962-bis says: “Logs SHOULD accept certificates and precertificates that are fully valid according to RFC 5280 [RFC5280] verification rules and are submitted with such a chain.” This text suggests that some logs might choose to verify certificate syntax as part of path validation, although none need to do so. The text goes on to note that a log may choose to accept certs that violate some 5280 rules, which also suggests to me that syntax checking is not outlawed by 6269-bis. It acknowledges that this leniency is needed to accept “quirks of CA certificate-issuing software.”

This is not an intended function of logs, and not a single one of the 58 logs currently in operation performs syntactic misissuance checks. Furthermore, having logs perform this function would violate separation of concerns. Instead, monitors perform syntactic misissuance checks. crt.sh, for instance, runs all certificates through several certificate linters. 

The document examines possible ways that one might detect syntax problems and how elements of CT might facilitate remediation of detected problems. Logs, if they chose to perform such checks, could help in this respect and that’s why they are discussed, irrespective of how logs currently operate. Also, I don’t see where 6962-bis states that a monitor performs syntax checks. For example, the 6962-bis text for the description of Monitor operation still says “Monitors watch logs to check that they behave correctly, for certificates of interest, or both.” (The “or both” makes no sense here, as I noted several times in 2017, but …)

Page 20 says that "syntactic checking [of pre-certificates] by a log helps avoid issuance of an erroneous certificate." This is contrary to RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate is a binding commitment by the CA to issue a certificate. It would be dangerous for a CA to follow the advice on page 20, as browsers rightly consider misissuance of a pre-certificate to be equivalent to misissuance of a real certificate. 

I'll change the text on page 20 to state that a log could help a CA detect and avoid issuing a syntactically erroneous cert. Also, what 6962 says is not relevant here- that was an experimental doc, not standards track. Submission of a pre-cert to a log probably does indicate an internet to issue a cert, but certificate issuance need not result in delivery to a Subject. If a CA were advised by a log that a certificate was malformed (e.g., due to “quirks of CA certificate-issuing software” then the CA could ditch the certificate, or revoke it, and try again.

CAs must perform syntactic checks on the TBSCertificate prior to signing anything.

In principle yes, but in practice, … “quirks of CA certificate-issuing software”

Section 4.2.1.1 is premised on two I-Ds that were not adopted by trans and have expired. I suggest that sections 4.1.1.1 and 4.2.1.1 be removed entirely. 

I believe that the two I-Ds in question were generated because of the text that I was writing here, not the other way around. The text in 4.1.1.1 says that a log could optionally check for syntax problems; it does not say that they MUST/SHOULD do so. I'll change the text in 4.1.1.1 to note, parenthetically, that syntax checks by a log are optional.

Page 4 says that if a bogus SCT is discovered, it would trigger a revocation request. Page 26 says that browsers need to "reject certificates that contain SCTs from conspiring logs." 

Page 4 says that discovery of a bogus SCT would "presumably, trigger" a revocation request. Page 26 does not require a browser to reject a certificate that does not contain an SCT. (As noted above, this document is not intended to establish requirements for any element of the CT system.) 5.4 describes issues that might arise IF such behavior were adopted.

Page 3 says "if an RP verified that a certificate that claims to have been logged has a valid log entry, the RP would have a higher degree of confidence that the certificate is genuine." 

But behavior of a log says nothing about whether a certificate was properly issued. A properly-issued certificate might be logged to a a misbehaving log, and a misissued certificate might be logged to a well-behaved log. 

Therefore, browsers should not consider a certificate more likely to be genuine just because it's logged, and if a certificate contains an embedded SCT from a log that's known to be bad, the browser should reject only that SCT, and still check SCTs from other logs. And there is no need to revoke a properly-issued certificate just because it's submitted to a log that misbehaves. 

I agree that a browser placing greater trust in a certificate because it has been logged is not fool-proof. However, it represents an important initial check. I believe Richard Barnes made some good arguments on the list last year about the utility of logging and the complexity and potential privacy issues that arise if browsers engage in auditing. So, yes, I believe that receipt of a certificate containing an SCT probably will inspire greater confidence. I will revise the text to insert the term "probably". Browser interactions with an audit system are not yet standardized and present some privacy concerns, so one ought not assume that the more extensive checks you note will be widely deployed.

Section 5.3 says that "evidence of a bogus or erroneous certificate" can be "in the form of a log entry and/or SCT." An SCT is irrelevant for this, as it attests only to log behavior. 

An SCT can be used to retrieve a log entry, so it seems reasonable to include it here. I’ll revise the text to say that a log entry or SCT is supporting evidence.

On pages 4, 9, and 13, the draft says that monitors should not "trust" or "rely upon" misbehaving logs. But monitors don't trust or distrust logs - they just view logs as a source of certificates. Browsers, on the other hand, do trust and distrust logs. For example, after two logs (WoSign and Startcom) issued bad SCTs, they were distrusted by Chrome, but Cert Spotter and crt.sh continued monitoring them until they shut down. 

The document should be updated to remove mention of monitors trusting or relying upon logs, and to make clear that the primary response to a misbehaving log is for browsers to distrust it. 

A monitor selects a set of logs that it will use to check for mis-issued certificates. By so doing it is implicitly trusting (relying on) them. If they are detected to misbehave, Monitors will, presumably, stop relying on them, as you indicated in your example.

There's another way a log can misbehave which ought to be mentioned in section 3.1.1.2. A misbehaving log that conspires with a CA could log a misissued certificate, but mutate the certificate's signature or chain such that the certificate is no longer cryptographically attributable to the CA. The CA could then plausibly deny that it issued the certificate. Since the signature and chain are not part of the Merkle Tree, the SCT will be accepted by browsers and be auditable, despite the log entry being mutated and useless for responding to the misissuance. 

Monitors should be sure to validate the signature and chain of logged certificates so that this misbehavior can be detected. 

I don’t think I understand the attack. Where is the mutated certificate signature? If you can provide a clear, detailed description of the attack I could include it in the revised text.

As David A. Cooper pointed out, Chrome is now requiring new certificates to contain SCTs, so sections 3.1.2.2, 3.2.2.1, and 5.4 need updates. 

As I noted in my reply to David, Chrome is just one browser. The WG has been informed, in the past, that the Chrome developers reserve to right to do whatever they feel is best for that product, irrespective of what the IETF describes in an RFC. So, for now, I don’t think, the sections in question require changes.

F.	Organization 

The organization of the draft seems sub-optimal. At a high level, the document is broken up into semantic and syntactic misissuance, and then into malicious vs non-malicious CA. Within these categories, the document discusses the implications when the certificate is logged, not logged, or when the log is misbehaving. Very often, these implications are the same regardless of the type of misissuance or the culpability of the CA. As a result, there is a lot of duplication, often with minor differences in wording, which makes the document harder to understand. 

I think the structure of section 5, which discusses issues as standalone concepts, is a better model. Alternatively, the duplication could be removed from sections 3 and 4 and replaced by references to prior sub-sections. 

I agree that there is some duplication, but I prefer the taxonomic approach and I’ve used that in other threat/attack documents, most recently RFC 7132. It’s rather late in this process to suggest a massive revision of the document.

G.	Minor comments 

Page 3 says "'bad-CA-lists' a CA as noted above". "Bad-CA-list" hasn't been defined and doesn't appear to be noted above. 

Fair point- I’ll try to provide an in-context definition. BTW, the cited text appears on page 4, not 3. 

Page 3 talks about "validat[ing]" an SCT, which is ambiguous, as it could refer to checking the SCT's signature, or auditing the SCT for inclusion. I suggest replacing "validates" with "audits" and replacing "is invalid" (in the same sentence) with "fails auditing." 

Section 8.1.3 of 6962-b defines SCT validation as checking the SCT signature, period. I’ll cite that section in the text. BTW, the cited text appears on page 4, not 3.

Page 4 says that "a CA benefits from CT when it detects a (mis-issued) certificate that represents the same Subject name as a legitimate certificate issued by the CA." How is a CA supposed to know if the certificate is misissued or not? 

I’ll reword the text to indicate that I was envisioning a CA acting as a Monitor for its clients in this case. BTW, the cited text appears on page 5, not 4.

Page 10 says that a monitor/auditor will detect a misbehaving log when it "sees the bogus certificate." It also needs to see the SCT. 

If the pre-certificate was logged, the certificate contains the SCT.  But, to be general, I’ll add a parenthetical reference to the SCT. BTW, the quoted text appears on page 11, not 10. 

Section 3.1.2.1 talks about a Subject being able to detect the lack of an SCT in a certificate that it is issued. Since this is part of the section on "Semantic misissuance," which is defined in the Introduction as a certificate issued to someone who isn't the Subject, it's unclear to me what the point of this sub-section is. A Subject, by definition, would never be issued a semantically misissued certificate. 

Fair point- I’ll move this text to Section 4.1.2

Section 3.3.1 ends with "If the bogus certificate is detected and logged, browsers that require an SCT will reject the bogus certificate." Wouldn't the logging of a certificate cause an SCT to be issued, and thus allow it to be *accepted* by browsers that require an SCT? 

Fair point- I’ll reword the text to note that if the certificate is logged, it is subject to detection as bogus. Since the CA is presumed to be malicious, it may delay revocation or try to suppress revocation status distribution (as per 3.5). Inn this case even browsers that require an SCT are still vulnerable.

The last paragraph of section 3.5 talks about the attack in 3.4 and should be moved.

The sentence that refers to “CA certificate 2” does belong with the discussion in 3.4, so I will move it to the end of that section. The rest of the text talks about ways that one might counter attacks based on manipulating distribution of revocation status, and thus belongs at the end of 3.5.

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 14 May 2018 22:06:43 -0400

On Mon, May 14, 2018 at 11:26 AM, Stephen Kent <[email-masked]> wrote:

> Also, note that 6962-bis says: “Logs SHOULD accept certificates and
> precertificates that are fully valid according to RFC 5280 [RFC5280]
> verification rules and are submitted with such a chain.” This text suggests
> that some logs might choose to verify certificate syntax as part of path
> validation, although none need to do so. The text goes on to note that a
> log may choose to accept certs that violate some 5280 rules, which also
> suggests to me that syntax checking is not outlawed by 6269-bis. It
> acknowledges that this leniency is needed to accept “quirks of CA
> certificate-issuing software.”
>

Perhaps I'm misunderstanding, but that sounds like an inversion of one of
the goals of CT. That is, that logs should do as little verification as
possible, and what verification they do perform is not a function of an
ecosystem benefit or of CA benefit, but rather, of mitigation of spam or
risk to the log itself.

> This is not an intended function of logs, and not a single one of the 58
> logs currently in operation performs syntactic misissuance checks.
> Furthermore, having logs perform this function would violate separation of
> concerns. Instead, monitors perform syntactic misissuance checks. crt.sh,
> for instance, runs all certificates through several certificate linters.
>
> The document examines possible ways that one might detect syntax problems
> and how elements of CT might facilitate remediation of detected problems.
> Logs, if they chose to perform such checks, could help in this respect and
> that’s why they are discussed, irrespective of how logs currently operate.
> Also, I don’t see where 6962-bis states that a monitor performs syntax
> checks. For example, the 6962-bis text for the description of Monitor
> operation still says “Monitors watch logs to check that they behave
> correctly, for certificates of interest, or both.” (The “or both” makes no
> sense here, as I noted several times in 2017, but …)
>

I have to agree with Andrew here, to the extent that we have considered for
Chrome formulating explicit policies prohibiting logs from doing what's
described here. Logs that perform such checks would not help the ecosystem,
but rather, they would actively harm the PKIs they were serving, by
preventing public record of and discovery of misissuance.

I'm also not sure why you believe "or both" is not reflective of the
reality. There are monitors that simply treat Logs as databases of
certificates, without regard for ensuring the cryptographic properties - on
a reliance of other members of the ecosystem performing such verification,
and perhaps agreeing upon some common shared STH. In this model, "or both"
is entirely reflective of real world.

> Page 20 says that "syntactic checking [of pre-certificates] by a log helps
> avoid issuance of an erroneous certificate." This is contrary to RFC6962
> and RFC6962-bis, which both state that issuing a pre-certificate is a
> binding commitment by the CA to issue a certificate. It would be dangerous
> for a CA to follow the advice on page 20, as browsers rightly consider
> misissuance of a pre-certificate to be equivalent to misissuance of a real
> certificate.
>
> I'll change the text on page 20 to state that a log could help a CA detect
> and avoid issuing a syntactically erroneous cert. Also, what 6962 says is
> not relevant here- that was an experimental doc, not standards track.
> Submission of a pre-cert to a log probably does indicate an internet to
> issue a cert, but certificate issuance need not result in delivery to a
> Subject. If a CA were advised by a log that a certificate was malformed
> (e.g., due to “quirks of CA certificate-issuing software” then the CA could
> ditch the certificate, or revoke it, and try again.
>

I don't think that would be a positive change, and have to agree with
Andrew here, that it would seem moreso detrimental to the ecosystem that CT
aims to improve.

I'm not sure the rationale for ditching the certificate is at all
reasonable - the fact that such a certificate was even considered as 'log
worthy' by a CA is a demonstration of a failure by that CA to uphold public
trust. In that model, it's vitally essential for the Log to make that known
- not to help the CA cover it up. In this regard, that the CA has used its
key to sign something - anything - that fails the checks is a demonstration
of risk to any PKI that trust this CAs.

I think painting it as quirks does a disservice - it's an operational
failure of the CA, and thus, by proxy, a security and trust failure by the
CA. That is, if anything, one of the most noteworthy events - rather than
the inverse.

> In principle yes, but in practice, … “quirks of CA certificate-issuing

I'm not sure what you're referring to as quirks again. This is a rather
fatal failure mode, and one of the express goals of 6962 (and, through
proxy, 6962-bis) is to detect and publicize any CA with such quirks, such
that relying parties can move to distrust or otherwise restrict such CAs.

> Section 4.2.1.1 is premised on two I-Ds that were not adopted by trans and
> have expired. I suggest that sections 4.1.1.1 and 4.2.1.1 be removed
> entirely.
>
> I believe that the two I-Ds in question were generated because of the text
> that I was writing here, not the other way around. The text in 4.1.1.1 says
> that a log could optionally check for syntax problems; it does not say that
> they MUST/SHOULD do so. I'll change the text in 4.1.1.1 to note,
> parenthetically, that syntax checks by a log are optional.
>

As mentioned, I think syntax checks should be SHOULD NOT. I only hesitate
to say MUST NOT because I think that requires normatively specifying that
few syntax checks that are necessary for spam/abuse prevention (for
example, checking the basicConstraints bit on the issuer, so that anyone
with a leaf can't just spam), and the ecosystem is still working through
them.

I agree that a browser placing greater trust in a certificate because it
> has been logged is not fool-proof. However, it represents an important
> initial check. I believe Richard Barnes made some good arguments on the
> list last year about the utility of logging and the complexity and
> potential privacy issues that arise if browsers engage in auditing. So,
> yes, I believe that receipt of a certificate containing an SCT probably
> will inspire greater confidence. I will revise the text to insert the term
> "probably". Browser interactions with an audit system are not yet
> standardized and present some privacy concerns, so one ought not assume
> that the more extensive checks you note will be widely deployed.
>

Like Andrew, I share these concerns about misplaced trust.

> A monitor selects a set of logs that it will use to check for mis-issued
> certificates. By so doing it is implicitly trusting (relying on) them. If
> they are detected to misbehave, Monitors will, presumably, stop relying on
> them, as you indicated in your example.
>

I fear this may misunderstand or misrepresent one of the goals of CT. A
monitor fully can continue to trust and rely on WoSign and StartCom logs
(in this example) as sources of logged certificates. While it may not be a
comprehensive view - that is, such logs may be omitting certificates - from
a monitor perspective, that does not alter or undermine the purpose and
value of the log, particularly for detecting misissuance.

A log is not necessarily expected to contain all certificates in existence.
Consider the set of logs we see these days that adopt policies in which
they will only accept certificates with validity periods in defined bands,
which beyond providing a defined lifetime of operation, also helps bound
growth. There's no reason to suggest or believe these logs become any less
useful once their issued certificates expire - for example, as ways of
analyzing past CA malfeasance ("quirks", but really "security bugs"). The
same way applies to logs that misbehave.

> section 3.1.1.2. A misbehaving log that conspires with a CA could log a
> misissued certificate, but mutate the certificate's signature or chain such
> that the certificate is no longer cryptographically attributable to the CA.
> The CA could then plausibly deny that it issued the certificate. Since the
> signature and chain are not part of the Merkle Tree, the SCT will be
> accepted by browsers and be auditable, despite the log entry being mutated
> and useless for responding to the misissuance.
>
> I don’t think I understand the attack. Where is the mutated certificate
> signature? If you can provide a clear, detailed description of the attack I
> could include it in the revised text.
>

Within the entry itself, as part of the proof of issuance to a CA.

> removed from sections 3 and 4 and replaced by references to prior

This remains one of the biggest challenges to providing a more meaningful
review at this time, and is worth considering as good feedback.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 May 2018 10:50:20 -0400

I can't speak for Steve, but I can
provide an example of a syntax error I encountered as a result of
"quirks of CA certificate-issuing software."

Many years ago when I was tasked to check whether certificates
being issued by a CA were being issued in conformance with the
appropriate profile, I discovered that the keyUsage extensions in
the certificates were not DER encoded. The contents of the
extension were correct according to BER, but not DER, and
everything else about the certificate was correct.

This must have been the fault of the developer of the CA software
and not the company operating the CA. This would not be a security
or trust failure by the CA and most clients wouldn't even notice
the problem. There would, however, be the risk that some client
software somewhere would not accept the certificate simply because
of the encoding problem, so it was useful for the encoding problem
to be identified and fixed.

It's not clear, however, that this is the type of error
draft-ietf-trans-threat-analysis has in mind. Section 1 of the
document says:

A certificate is characterized as syntactically mis-issued
(aka

erroneous) if it violates syntax constraints associated
with the

class of certificate that it purports to represent.  Syntax

constraints for certificates are established by certificate
profiles,

and typically are application-specific.

Similarly,
https://tools.ietf.org/html/draft-kent-trans-domain-validation-cert-checks
makes no mention of encoding errors, such as the one I
encountered.

But, my guess would be that syntactic mis-issuance was intended to
include encoding errors in addition to violations of
application-specific certificate profiles.

NOTE: I have no position of which entity, if any, should be
checking for these types of errors, or on how the discovery of
such errors should be handled if they are found.

On 05/14/2018 10:06 PM, Ryan Sleevi wrote:

Page 20 says that "syntactic checking [of
pre-certificates] by a log helps avoid issuance of an
erroneous certificate." This is contrary to RFC6962 and
RFC6962-bis, which both state that issuing a
pre-certificate is a binding commitment by the CA to
issue a certificate. It would be dangerous for a CA to
follow the advice on page 20, as browsers rightly
consider misissuance of a pre-certificate to be
equivalent to misissuance of a real certificate.

I'll change the text on page 20 to state that a log
could help a CA detect and avoid issuing a syntactically
erroneous cert. Also, what 6962 says is not relevant here-
that was an experimental doc, not standards track.
Submission of a pre-cert to a log probably does indicate
an internet to issue a cert, but certificate issuance need
not result in delivery to a Subject. If a CA were advised
by a log that a certificate was malformed (e.g.., due to
“quirks of CA certificate-issuing software” then the CA
could ditch the certificate, or revoke it, and try again.

I don't think that would be a positive change, and have
to agree with Andrew here, that it would seem moreso
detrimental to the ecosystem that CT aims to improve.

I'm not sure the rationale for ditching the certificate
is at all reasonable - the fact that such a certificate
was even considered as 'log worthy' by a CA is a
demonstration of a failure by that CA to uphold public
trust. In that model, it's vitally essential for the Log
to make that known - not to help the CA cover it up. In
this regard, that the CA has used its key to sign
something - anything - that fails the checks is a
demonstration of risk to any PKI that trust this CAs.

I think painting it as quirks does a disservice - it's
an operational failure of the CA, and thus, by proxy, a
security and trust failure by the CA. That is, if
anything, one of the most noteworthy events - rather than
the inverse.

CAs must perform syntactic checks on the TBSCertificate
prior to signing anything.

In principle yes, but in practice, … “quirks of CA
certificate-issuing software”

I'm not sure what you're referring to as quirks again.
This is a rather fatal failure mode, and one of the
express goals of 6962 (and, through proxy, 6962-bis) is to
detect and publicize any CA with such quirks, such that
relying parties can move to distrust or otherwise restrict
such CAs.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 15 May 2018 11:34:26 -0400

On Tue, May 15, 2018 at 10:50 AM, David A. Cooper <[email-masked]>
wrote:

> I can't speak for Steve, but I can provide an example of a syntax error I
> encountered as a result of "quirks of CA certificate-issuing software."
>
> Many years ago when I was tasked to check whether certificates being
> issued by a CA were being issued in conformance with the appropriate
> profile, I discovered that the keyUsage extensions in the certificates were
> not DER encoded. The contents of the extension were correct according to
> BER, but not DER, and everything else about the certificate was correct.
>
> This must have been the fault of the developer of the CA software and not
> the company operating the CA. This would not be a security or trust failure
> by the CA and most clients wouldn't even notice the problem. There would,
> however, be the risk that some client software somewhere would not accept
> the certificate simply because of the encoding problem, so it was useful
> for the encoding problem to be identified and fixed.
>

I think we may disagree on this assessment. I agree that it presents an
interoperability issue - but I think a failure of the CA to actually ensure
that their software conforms to the profile is a grounds for concern. We've
seen a spectrum of CAs and competencies - and I know of some CAs that have
expressly written tools to ensure everything they issue conforms to the
appropriate profile (i.e. they actually understand their systems) versus
CAs that think that if you use some COTS product, you've got Production
Grade issuance.

CT very much cares about detecting these issues, in practice, and in fact,
it's the detection, discovery, and mitigation of precisely these sorts of
issues that have demonstrated the most immediate practical value. Further,
because of the existence of such linting tools, CAs are now expected to run
such linting tools prior to their issuance.

It is thus, to that end, that having logs reject such certificates (i.e.
logs as linters) that would undermine the development of and enforcement of
issuance policy. Linting-as-a-service is provided by separable endpoints,
and while such services can mask the underlying issues that CAs have,
that's conversely part of the goal of having such APIs - to check a
tbsCertificate before the CA has actually signed the material, while
checking a precertificate/certificate means that the CA has actually signed
it, and is notable for detection and censure.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 May 2018 09:44:07 -0400

Folks,

Ben Kudak politely noted that my reply to Andrew's comments lost all formatting when I sent it. I have attached the formatted version that I prepared, as a PDF, to facilitate review.

Sorry,

Steve

​​

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On May 7, 2018 2:29 PM, Andrew Ayer <[email-masked]> wrote:

> ​​
> thus allow it to be accepted by browsers that require an SCT?
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 May 2018 14:09:08 -0400

Ryan,
Thanks for the comments, despite by unformatted reply to Andrew. Responses to your comments are inline below.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On May 14, 2018 9:06 PM, Ryan Sleevi <[email-masked]> wrote:

> Perhaps I'm misunderstanding, but that sounds like an inversion of one of the goals of CT. That is, that logs should do as little verification as possible, and what verification they do perform is not a function of an ecosystem benefit or of CA benefit, but rather, of mitigation of spam or risk to the log itself.

Please remember that the text I cited is from 6962-bis. It is that text that makes it optional for logs to perform syntax checks. I believe your comment on this should be directed to the authors of that document, not to me.

> I have to agree with Andrew here, to the extent that we have considered for Chrome formulating explicit policies prohibiting logs from doing what's described here.. Logs that perform such checks would not help the ecosystem, but rather, they would actively harm the PKIs they were serving, by preventing public record of and discovery of misissuance.

I understand the argument that logs ought to not perform any syntax checking behind what is needed to verify a signature chain. But, the text in 6962-bis doesn't say that, so, again, your complaint seems more appropriately directed at that document.

> I'm also not sure why you believe "or both" is not reflective of the reality. There are monitors that simply treat Logs as databases of certificates, without regard for ensuring the cryptographic properties - on a reliance of other members of the ecosystem performing such verification, and perhaps agreeing upon some common shared STH. In this model, "or both" is entirely reflective of real world.

I didn't say that "or both" does not reflect reality. I said that it makes no sense grammatically :-). Typically the phrase "or both" refers to two antecedents, e.g., A or B or both. In the sentence I cited from section 8 of 6962-bis can you identify the antecedents? I can't. I find it very confusing.

>> I'll change the text on page 20 to state that a log could help a CA detect and avoid issuing a syntactically erroneous cert. Also, what 6962 says is not relevant here- that was an experimental doc, not standards track. Submission of a pre-cert to a log probably does indicate an internet to issue a cert, but certificate issuance need not result in delivery to a Subject. If a CA were advised by a log that a certificate was malformed (e.g.., due to “quirks of CA certificate-issuing software” then the CA could ditch the certificate, or revoke it, and try again.
>
> I don't think that would be a positive change, and have to agree with Andrew here, that it would seem moreso detrimental to the ecosystem that CT aims to improve.
>
> I'm not sure the rationale for ditching the certificate is at all reasonable - the fact that such a certificate was even considered as 'log worthy' by a CA is a demonstration of a failure by that CA to uphold public trust. In that model, it's vitally essential for the Log to make that known - not to help the CA cover it up. In this regard, that the CA has used its key to sign something - anything - that fails the checks is a demonstration of risk to any PKI that trust this CAs.
>
> I think painting it as quirks does a disservice - it's an operational failure of the CA, and thus, by proxy, a security and trust failure by the CA. That is, if anything, one of the most noteworthy events - rather than the inverse.

The text in 6962-bis describes potential syntactic deviation from 5280 as quirks that need to accommodated by CT, not me. I agree that catching syntax errors by CAs, and providing an incentive for them to rectify such errors is a good goal. That could be accomplished several ways. For example, a log could refuse to use an SCT, making the cert less trustworthy to browser clients, and using an error message to there submitting CA. Or, a log could make an entry for the cert, generate an SCT, but return it with an error indication. Logging the certs, retiring an SCT, and providing no error feedback, seems to provide the least help in rectifying. the problem.

> I'm not sure what you're referring to as quirks again. This is a rather fatal failure mode, and one of the express goals of 6962 (and, through proxy, 6962-bis) is to detect and publicize any CA with such quirks, such that relying parties can move to distrust or otherwise restrict such CAs.

I think David Cooper's message suggests that CA "quirks" have not been uncommon, at least not historically. I recall when a widely-used (on mobile devices) browser failed to require the CA Boolean for a v3 cert purporting to be associated with a CA. This was a serious vulnerability that was exploited. If certs from the offending CAs were rejected by all browsers, the offendingCAs would have been forced to fix the problem. But, that was not  the case. The major browsers (Chrome, IE, Safari, Firefox, Opera) have not been very diligent about rejecting certs that deviated from 5280 specs. My guess is that no vendor wanted to become potentially less attractive to users by being there first (only?) to enforce such requirements. This may get better over time, but ...

>> I believe that the two I-Ds in question were generated because of the text that I was writing here, not the other way around. The text in 4.1.1..1 says that a log could optionally check for syntax problems; it does not say that they MUST/SHOULD do so. I'll change the text in 4.1.1.1 to note, parenthetically, that syntax checks by a log are optional.
>
> As mentioned, I think syntax checks should be SHOULD NOT. I only hesitate to say MUST NOT because I think that requires normatively specifying that few syntax checks that are necessary for spam/abuse prevention (for example, checking the basicConstraints bit on the issuer, so that anyone with a leaf can't just spam), and the ecosystem is still working through them.

Again, your suggestion for a SHOULD NOT ought tin be directed to 6962-bis, not to this document. My analysis is based primarily on what 6962-bis does or does not require of compliant CAs, logs, clients, Monitors, and Auditors.

> Like Andrew, I share these concerns about misplaced trust.

I don't dispute the fact that a more thorough checking of SCTs would be beneficial, but 6962-bis does not even require a client to fetch an inclusion proof (see section 8.1.4). Also note that Section 8.1.6 says that what a client has to do to satisfy "compliance" and what it does in the face of non-compliance is largely a local matter.

> I fear this may misunderstand or misrepresent one of the goals of CT. A monitor fully can continue to trust and rely on WoSign and StartCom logs (in this example) as sources of logged certificates. While it may not be a comprehensive view - that is, such logs may be omitting certificates - from a monitor perspective, that does not alter or undermine the purpose and value of the log, particularly for detecting misissuance.
>
> A log is not necessarily expected to contain all certificates in existence. Consider the set of logs we see these days that adopt policies in which they will only accept certificates with validity periods in defined bands, which beyond providing a defined lifetime of operation, also helps bound growth. There's no reason to suggest or believe these logs become any less useful once their issued certificates expire - for example, as ways of analyzing past CA malfeasance ("quirks", but really "security bugs"). The same way applies to logs that misbehave.

I don't see how your observations above relate to my comment that a Monitors relies on (trusts) the logs that it chooses to check. Can you cite text in 6962-bis that states what you characterize as the goals of CT relative to Monitors?

> Within the entry itself, as part of the proof of issuance to a CA.

I need a more complete description of the attack it if is to be included in this doc.

> This remains one of the biggest challenges to providing a more meaningful review at this time, and is worth considering as good feedback.

The overall structure of this document has been unchanged since it was submitted as a -00 draft in June 2015. A suggestion to restructure would have been appropriate two or three years ago, but not now.

Steve

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 17 May 2018 15:57:44 -0400

On Thu, May 17, 2018 at 2:09 PM, Stephen Kent <[email-masked]> wrote:

> <snip>

> I have to agree with Andrew here, to the extent that we have considered
> for Chrome formulating explicit policies prohibiting logs from doing what's
> described here.. Logs that perform such checks would not help the
> ecosystem, but rather, they would actively harm the PKIs they were serving,
> by preventing public record of and discovery of misissuance.
>
>
> I understand the argument that logs ought to not perform any syntax
> checking behind what is needed to verify a signature chain. But, the text
> in 6962-bis doesn't say that, so, again, your complaint seems more
> appropriately directed at that document.
>
>
> I didn't say that "or both" does not reflect reality. I said that it makes
> no sense grammatically :-). Typically the phrase "or both" refers to two
> antecedents, e.g., A or B or both. In the sentence I cited from section 8
> of 6962-bis can you identify the antecedents? I can't. I find it very
> confusing.
>

Monitors watch logs to check that they (logs) behave correctly
Monitors watch logs for certificates of interest
Monitors watch logs both to check that they (logs) behave correctly and to
check for certificates of interest.

>> RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate is
>> a binding commitment by the CA to issue a certificate. It would be
>> dangerous for a CA to follow the advice on page 20, as browsers rightly
>> consider misissuance of a pre-certificate to be equivalent to misissuance
>> of a real certificate.
>>
>> I'll change the text on page 20 to state that a log could help a CA
>> detect and avoid issuing a syntactically erroneous cert. Also, what 6962
>> says is not relevant here- that was an experimental doc, not standards
>> track. Submission of a pre-cert to a log probably does indicate an internet
>> to issue a cert, but certificate issuance need not result in delivery to a
>> (e.g.., due to “quirks of CA certificate-issuing software” then the CA
> The text in 6962-bis describes potential syntactic deviation from 5280 as
> quirks that need to accommodated by CT, not me. I agree that catching
> syntax errors by CAs, and providing an incentive for them to rectify such
> errors is a good goal. That could be accomplished several ways. For
> example, a log could refuse to use an SCT, making the cert less trustworthy
> to browser clients, and using an error message to there submitting CA. Or,
> a log could make an entry for the cert, generate an SCT, but return it with
> an error indication. Logging the certs, retiring an SCT, and providing no
> error feedback, seems to provide the least help in rectifying. the problem.
>

Right, I'm explicitly disagreeing with that position. I'm saying that Logs
that refuse to issue an SCT actively harms the CT ecosystem and does not
help the furtherance of the improving, at least, the Web PKI.

>From the point of view of RFC 6962 and RFC 6962-bis, it's not a protocol
error for a CA to have submitted such a cert, so returning an error message
for unrelated reasons seems to be the least helpful, in that it conflates
two separate systems of concern.

> I think David Cooper's message suggests that CA "quirks" have not been
> uncommon, at least not historically. I recall when a widely-used (on mobile
> devices) browser failed to require the CA Boolean for a v3 cert purporting
> to be associated with a CA. This was a serious vulnerability that was
> exploited. If certs from the offending CAs were rejected by all browsers,
> the offendingCAs would have been forced to fix the problem. But, that was
> not  the case. The major browsers (Chrome, IE, Safari, Firefox, Opera) have
> not been very diligent about rejecting certs that deviated from 5280 specs.
> My guess is that no vendor wanted to become potentially less attractive to
> users by being there first (only?) to enforce such requirements. This may
> get better over time, but ...
>

I'm not disagreeing that CA non-compliance to RFC 5280, which is a
normative requirement of the Baseline Requirements, has unfortunately not
been uncommon.
I'm saying it's not accurate to describe such non-compliance as a 'quirk' -
a somehow benign deviance - when it is active misissuance and failure to
abide by both stated and expected policy.

Regarding your view of diligence in rejecting such certs, I can't help but
feel that's a non-sequitor in the context of CT. However, since this has
been suggested a few times now as somehow a deficiency or non-conformancy
on behalf of the browsers or RFC 5280 clients, recall the following:

https://tools.ietf.org/html/rfc5280#section-6.1
   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks.

RFC 5280 is but one profile, and for a number of clients, they must deal
with profiles for other constituencies - for example, local
Enterprise-defined profiles.

While this is unquestionably symptomatic of the problems with the
Robustness Principle, as Martin Thompson has so thoroughly explored in
https://tools.ietf.org/html/draft-thomson-postel-was-wrong, it's worth
noting that such criticism is a bit misplaced.

>> I believe that the two I-Ds in question were generated because of the
>> text that I was writing here, not the other way around. The text in
>> 4.1.1..1 says that a log could optionally check for syntax problems; it
>> does not say that they MUST/SHOULD do so. I'll change the text in 4.1.1.1
>> to note, parenthetically, that syntax checks by a log are optional.
>
>
> Again, your suggestion for a SHOULD NOT ought tin be directed to 6962-bis,
> not to this document. My analysis is based primarily on what 6962-bis does
> or does not require of compliant CAs, logs, clients, Monitors, and Auditors.
>

I agree that I think RFC 6962-bis can benefit from improvements, to
highlight that the syntactical checks, as interpreted by you, was not
inline with the intention of syntax checks as written - that is, for
example, ensuring an interpretable parsing of the Certificate into its
corresponding tbsCertificate and signature fields, or the relationship of
the tbsCertificate's issuer to the next certificate's subject, etc.

That is, syntax is as minimal as necessary to ensure it's just not
arbitrary random bytes being added to the log (as that presents an
operational risk), but not to those matters of policy or profile
enforcement explicitly recommended against by 5280.

> I don't dispute the fact that a more thorough checking of SCTs would be
> beneficial, but 6962-bis does not even require a client to fetch an
> inclusion proof (see section 8.1.4). Also note that Section 8.1.6 says that
> what a client has to do to satisfy "compliance" and what it does in the
> face of non-compliance is largely a local matter.
>

I'm not sure how this addresses or responds to the concerns?

> A log is not necessarily expected to contain all certificates in
> existence. Consider the set of logs we see these days that adopt policies
> in which they will only accept certificates with validity periods in
> defined bands, which beyond providing a defined lifetime of operation, also
> helps bound growth. There's no reason to suggest or believe these logs
> become any less useful once their issued certificates expire - for example,
> as ways of analyzing past CA malfeasance ("quirks", but really "security
> bugs"). The same way applies to logs that misbehave.
>
>
> I don't see how your observations above relate to my comment that a
> Monitors relies on (trusts) the logs that it chooses to check. Can you cite
> text in 6962-bis that states what you characterize as the goals of CT
> relative to Monitors?
>

I'm not sure how you're arriving at a conclusion that there's either
reliance or trust involved here on the part of monitors, so that may be the
heart of the confusion.

> I need a more complete description of the attack it if is to be included

I'm not sure how to further expand on this, as this is a rather complete
and comprehensive description. Perhaps Andrew could reword it, but in terms
of informational content, it's fully descriptive of the risk - a log and a
CA conspiring using unauthenticated data that is still relied upon by
monitors.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 May 2018 14:05:55 -0400

Ryan,

Responses inline

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On May 18, 2018 12:19 PM, Stephen Kent <[email-masked]> wrote:

> On May 17, 2018 2:57 PM, Ryan Sleevi <[email-masked]> wrote:
>
>> Monitors watch logs both to check that they (logs) behave correctly and to check for certificates of interest.

OK, I now see why the “or both” makes sense, but it appears to be wrong J.

Both descriptions of Monitor operation in 8.2 say that step 4, checking for a certificate of interest, is performed “If applicable”. That implies that steps 1-3 and 5 are checking to see if a log is behaving correctly (in a very basic sense). So, it seems that Monitors are always checking logs for consistency, and optionally checking for certs of interest. If so, the opening sentence should say that Monitors watch logs to check that they behave correctly (in a basic sense) and, optionally, they watch logs for certificates of interest.

>> Right, I'm explicitly disagreeing with that position. I'm saying that Logs that refuse to issue an SCT actively harms the CT ecosystem and does not help the furtherance of the improving, at least, the Web PKI.
>>
>> From the point of view of RFC 6962 and RFC 6962-bis, it's not a protocol error for a CA to have submitted such a cert, so returning an error message for unrelated reasons seems to be the least helpful, in that it conflates two separate systems of concern.

(As an aside, I’m not sure what you cite 6962. It’s an experimental RFC that is Obsoleted by 6962-bis.)

Section 5.1 defines an error code “bad submission” that is sent if the submission is not a “valid” certificate or pre-certificate (see table on page 28). Since what constitutes a valid certificate is ambiguous (see my earlier comment about RFC 5280), I think this error code could be inapplicable in the case of a syntax problem.

>> I'm not disagreeing that CA non-compliance to RFC 5280, which is a normative requirement of the Baseline Requirements, has unfortunately not been uncommon.
>> I'm saying it's not accurate to describe such non-compliance as a 'quirk' - a somehow benign deviance - when it is active misissuance and failure to abide by both stated and expected policy.

I agree that issuing certificates with syntax errors is serious, but the term “quirk” was chosen by the authors of 6962-bis, not me.

>> Regarding your view of diligence in rejecting such certs, I can't help but feel that's a non-sequitor in the context of CT. However, since this has been suggested a few times now as somehow a deficiency or non-conformancy on behalf of the browsers or RFC 5280 clients, recall the following:
>>

The text you cite applies to certificate path validation. Other parts of 5280 define syntactic requirements for certificates

>> RFC 5280 is but one profile, and for a number of clients, they must deal with profiles for other constituencies - for example, local Enterprise-defined profiles.

I’m not sure what you point is here. I knew Jon and during my 10+ years on the IAB we (politely) disagreed about his mantra. I argued that being liberal in what one accepts is a dangerous strategy re security, despite from the perspective of interoperability.

>> While this is unquestionably symptomatic of the problems with the Robustness Principle, as Martin Thompson has so thoroughly explored in https://tools.ietf.org/html/draft-thomson-postel-was-wrong, it's worth noting that such criticism is a bit misplaced.
>>
>> I agree that I think RFC 6962-bis can benefit from improvements, to highlight that the syntactical checks, as interpreted by you, was not inline with the intention of syntax checks as written - that is, for example, ensuring an interpretable parsing of the Certificate into its corresponding tbsCertificate and signature fields, or the relationship of the tbsCertificate's issuer to the next certificate's subject, etc.
>>
>> That is, syntax is as minimal as necessary to ensure it's just not arbitrary random bytes being added to the log (as that presents an operational risk), but not to those matters of policy or profile enforcement explicitly recommended against by 5280.

If 6962-bis stated that logs MUST NOT check syntax beyond what is needed to perform certificate path validation, then we would not be disagreeing.

>> I'm not sure how this addresses or responds to the concerns?

The abstract for 6962-bis says: “The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.” This text suggests that the goal is for browsers to distrust certificates without SCTs. To me that suggests that the authors believe that a browser ought to view a certificate with an SCT as more trustworthy than one without, even if the browser performs no additional checks.

>> I'm not sure how you're arriving at a conclusion that there's either reliance or trust involved here on the part of monitors, so that may be the heart of the confusion.

There is no requirement that any Monitor watch all logs. Thus, when a Monitor elects to watch a set of logs it is relying on them as it tries to perform it’s optional task  of watching logs for certificates of interest for the clients of the Monitor. This seems consistent with the text in Section 1 (6962-bis): “Those who are concerned about misissuance can monitor the logs, asking them regularly for all new entries, and can thus check whether domains for which they are responsible have had certificates issued that they did not expect.” If a Monitor is associated with a CA, the choice of logs may be different; the CA would certainly watch the logs to which it submits its certs to receive SCTs. But it also may watch other logs to detect certificates issued under the same name as certificates that it has issued (to protect its clients).

>> I'm not sure how to further expand on this, as this is a rather complete and comprehensive description. Perhaps Andrew could reword it, but in terms of informational content, it's fully descriptive of the risk - a log and a CA conspiring using unauthenticated data that is still relied upon by monitors.

If you look at the descriptions of attacks involving a malicious CA and a misbehaving (or compressed log  in 3.2.1.2 and 3.3.3) they provide a lot of detail, compared to the very terse statement above.

Steve

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 21 May 2018 14:40:58 -0400

Thanks for the replies, Stephen.

Given the disagreements in interpretation and application of 6962-bis, it
sounds like this document should not progress until we've resolved those
matters in 6962-bis. Does that sound like a reasonable path forward? I
don't feel comfortable that this document describes the running code, and
I'm hesitant to believe we'll get rough consensus because of it, so that
might be a worthwhile path forward here.

Given the issues Andrew has pointed out, which I'm largely agreeing with or
contextualizing, would you feel comfortable proposing changes to 6962-bis
on areas you feel it disagrees with the feedback, or is that something that
you would feel more confident if Andrew and I do? If they are accepted,
would you feel comfortable making these changes to the threat document?

As it stands, I don't feel like the threat document is reflective of intent
or practice, and that leaves me a bit concerned about its general utility
for future readers.

On Mon, May 21, 2018 at 2:05 PM, Stephen Kent <[email-masked]> wrote:

>> Thanks for the comments, despite by unformatted reply to Andrew.
>> Responses to your comments are inline below.
>>
>>
>> <snip>
>
>>
>>> The document examines possible ways that one might detect syntax
>>> problems and how elements of CT might facilitate remediation of detected
>>> problems. Logs, if they chose to perform such checks, could help in this
>>> respect and that’s why they are discussed, irrespective of how logs
>>> currently operate. Also, I don’t see where 6962-bis states that a monitor
>>> performs syntax checks. For example, the 6962-bis text for the description
>>> of Monitor operation still says “Monitors watch logs to check that they
>>> behave correctly, for certificates of interest, or both.” (The “or both”
>>> makes no sense here, as I noted several times in 2017, but …)
>>
>>
>> I didn't say that "or both" does not reflect reality. I said that it
>> makes no sense grammatically :-). Typically the phrase "or both" refers to
>> two antecedents, e.g., A or B or both. In the sentence I cited from section
>> 8 of 6962-bis can you identify the antecedents? I can't. I find it very
>> confusing.
>>
>
> Both descriptions of Monitor operation in 8.2 say that step 4, checking
> for a certificate of interest, is performed “If applicable”. That implies
> that steps 1-3 and 5 are checking to see if a log is behaving correctly (in
> a very basic sense). So, it seems that Monitors are always checking logs
> for consistency, and optionally checking for certs of interest. If so, the
> opening sentence should say that Monitors watch logs to check that they
> behave correctly (in a basic sense) and, optionally, they watch logs for
> certificates of interest.
>
>
>
>
>>
>>
>>
>>
> Section 5.1 defines an error code “bad submission” that is sent if the
> submission is not a “valid” certificate or pre-certificate (see table on
> page 28). Since what constitutes a valid certificate is ambiguous (see my
> earlier comment about RFC 5280), I think this error code could be
> inapplicable in the case of a syntax problem.
>
>
>
>>
>>
>>
>>
> I'm saying it's not accurate to describe such non-compliance as a 'quirk'
> - a somehow benign deviance - when it is active misissuance and failure to
> I agree that issuing certificates with syntax errors is serious, but the
> term “quirk” was chosen by the authors of 6962-bis, not me.
>
>
>
>
> The text you cite applies to certificate path validation. Other parts of
> 5280 define syntactic requirements for certificates
>
>
> I’m not sure what you point is here. I knew Jon and during my 10+ years on
> the IAB we (politely) disagreed about his mantra. I argued that being
> liberal in what one accepts is a dangerous strategy re security, despite
> from the perspective of interoperability.
>
>
>>> and have expired. I suggest that sections 4.1.1.1 and 4.2.1.1 be removed
>>> entirely.
>>>
>> Again, your suggestion for a SHOULD NOT ought tin be directed to
>> 6962-bis, not to this document. My analysis is based primarily on what
>> 6962-bis does or does not require of compliant CAs, logs, clients,
>> Monitors, and Auditors.
>>
>
> If 6962-bis stated that logs MUST NOT check syntax beyond what is needed
> to perform certificate path validation, then we would not be disagreeing.
>
>
>
> The abstract for 6962-bis says: “The intent is that eventually clients
> would refuse to honor certificates that do not appear in a log,
> effectively forcing CAs to add all issued certificates to the logs.” This
> text suggests that the goal is for browsers to distrust certificates
> without SCTs. To me that suggests that the authors believe that a browser
> ought to view a certificate with an SCT as more trustworthy than one
> without, even if the browser performs no additional checks.
>
>
>
> There is no requirement that any Monitor watch all logs. Thus, when a
> Monitor elects to watch a set of logs it is relying on them as it tries to
> perform it’s optional task  of watching logs for certificates of interest
> for the clients of the Monitor. This seems consistent with the text in
> Section 1 (6962-bis): “Those who are concerned about misissuance can
> monitor the logs, asking them regularly for all new entries, and can thus
> check whether domains for which they are responsible have had
> certificates issued that they did not expect.” If a Monitor is associated
> with a CA, the choice of logs may be different; the CA would certainly
> watch the logs to which it submits its certs to receive SCTs. But it also
> may watch other logs to detect certificates issued under the same name as
> certificates that it has issued (to protect its clients).
>
>
>
> If you look at the descriptions of attacks involving a malicious CA and a
> misbehaving (or compressed log  in 3.2.1.2 and 3.3.3) they provide a lot of
> detail, compared to the very terse statement above.
>
>
>
> Steve
>
>

---

From: Rob Stradling <[email-masked]>
Date: Tue, 22 May 2018 10:16:14 +0100

On 21/05/18 19:05, Stephen Kent wrote:
<snip>
>>> Monitors watch logs both to check that they (logs) behave correctly 
>>> and to check for certificates of interest.
> 
> OK, I now see why the “or both” makes sense, but it appears to be wrongJ.
> 
> 
> for a certificate of interest, is performed “If applicable”. That 
> implies that steps 1-3 and 5 are checking to see if a log is behaving 
> correctly (in a very basic sense). So, it seems that Monitors are always 
> checking logs for consistency, and optionally checking for certs of 
> interest. If so, the opening sentence should say that Monitors watch 
> logs to check that they behave correctly (in a basic sense) and, 
> optionally, they watch logs for certificates of interest.

crt.sh does not currently check logs for consistency.  (Maybe one day 
I'll get around to implementing that).

crt.sh does check for "certs of interest".  (It downloads all the certs 
from all the logs, and takes the view that all certs are interesting ;-) ).

Is crt.sh a Monitor?

-- 
Rob Stradling
Senior Research & Development Scientist
ComodoCA.com

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 May 2018 11:55:53 -0400

Rob,

> from all the logs, and takes the view that all certs are interesting ;-) ).

As we described Monitor behavior in our (now expired, never adopted) Monitor draft, yes. Also in the architecture draft (not expired, but also not adopted).

According to the cited text in 6962-bis, no.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 May 2018 12:06:15 -0400

Ryan,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On May 21, 2018 2:40 PM, Ryan Sleevi <[email-masked]> wrote:

> Given the disagreements in interpretation and application of 6962-bis, it sounds like this document should not progress until we've resolved those matters in 6962-bis. Does that sound like a reasonable path forward?

Yes, but I will post a new version of the threat doc with all of the changes I promised to make in my replies to David and Andrew.

> I don't feel comfortable that this document describes the running code, and I'm hesitant to believe we'll get rough consensus because of it, so that might be a worthwhile path forward here.

Unfortunately, 6962-bis completed WGLC over 6 months ago, so it had the consensus of the WG at that time, as determined by the chairs.

> Given the issues Andrew has pointed out, which I'm largely agreeing with or contextualizing, would you feel comfortable proposing changes to 6962-bis on areas you feel it disagrees with the feedback, or is that something that you would feel more confident if Andrew and I do? If they are accepted, would you feel comfortable making these changes to the threat document?

I proposed numerous changes to 6962-bis over a several year interval. A few were adopted but many were not, e.g., the definition of the Monitor function. 6962-bis never defined mis--issuance, not does it provide a concise characterization of the broad purpose of CT. I included these things in the threat analysis (and in some docs that were not adopted by the WG). If 6962-bis were revised to address these omissions, the threat analysis doc would be revised accordingly. But, you need to get the WG chairs and the cognizant AD (EKR) to agree to make such changes to 6962-bis at this very late stage.

> As it stands, I don't feel like the threat document is reflective of intent or practice, and that leaves me a bit concerned about its general utility for future readers.

The analyses in the threat doc are based primarily on what 6962-bis says re how CT will operate. Intent is not clearly stated in several areas and, from what you and Rob have said, it may not reflect practice either. But, those issues are for the authors of 6962-bis to address, not me.

Steve