Subject: [Trans] The trans threat analysis document

From: Melinda Shore <[email-masked]>
Date: Thu, 2 Aug 2018 11:37:12 -0800

Hi, all:

Paul and I discussed the status of the threat document and
agree that it is not appropriate for chairs to make changes
to the content of working group documents in the absence of
working group consensus.  We've been deadlocked on the
threat analysis document for several years now, and while
we would very much like for the parties who disagree to
find a compromise, and for the document to be published, it
does not weaken the protocol document if it is not.  So, if
the authors and those who have issues with the current text
cannot find some compromise text before the working group
shuts down, the document will not be published as a working
group document.  The authors, of course, are free to
pursue publication through alternative processes should they
continue to be unable to arrive at a compromise.

Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 3 Aug 2018 16:50:33 +0000

As chairs, you can appoint a new author.

On 8/2/18, 3:37 PM, "Melinda Shore" <[email-masked]> wrote:

    Hi, all:

    Melinda
    
    _______________________________________________
    Trans mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/trans

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Aug 2018 10:41:29 -0700

> On Aug 3, 2018, at 09:50, Salz, Rich <rsalz=[email-masked]> wrote:
> 

We know that. The interest in the document seems to be almost exclusively the two persons involved that cannot seem to reach consensus, which is why we are asking those two people to resolve their issues and/or find others interested in moving the document towards consensus.

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 3 Aug 2018 17:54:05 +0000

I am asking you to pick a new author NOW so that the document can get published.

As I have said multiple times, it is a worthwhile and useful document.  Leaving it stuck as a draft because of stupid bickering should not prevent its publication.

On 8/3/18, 1:41 PM, "Paul Wouters" <[email-masked]> wrote:

    
    
    Paul

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Aug 2018 14:44:02 -0400

The chair's message is a mis-characterization of the history and status 
of this document.

As the cognizant AD, Eric Rescorla  discussed the document status with 
the WG chairs early this year. Paul stated that that there were a two 
paragraphs in the version -12 text (in sections 3.4 and 3.5) that were 
sticking points for David Cooper. A telecon was arranged and took place 
on April 12.  The participants were Paul, David, Eric, Richard Barnes 
(acting as secretary) and me. The outcome of that telecon  was text, 
crafted by Richard, which was agreed to by all parties.  This text was 
incorporated into the next version (-13) of the document which was 
published later in April.

I assumed that were were done, but I was wrong. After this version was 
posted, David sent a large number (~29) of additional comments to the 
list. Thus Paul's assertion that there were only two paragraph that need 
to be changed to satisfy David was incorrect.
I made changes based on all but 6 or 7 of David's comments. Most of his 
comments were straightforward and I agreed that the requested changes 
were appropriate. I  posted a message detailing the changes and the 
rationale for not making changes for the remaining few comments. A new 
version (-14) was posted on May 29. I think the changes I made represent 
a good faith effort to address David's legitimate issues, especially 
since all of the telecon participants believed that we had already done 
so in April.

Ryan Sleevi and I began an exchange based on his comments, on version 
-14. Ryan argued that some of the text did not represent the intent of 
CT, or the practice of CT implementations, based on his experience as a 
developer. I countered that the analysis is based on 6962-bis, and if 
that text was not consistent with intent and practice, from his 
perspective, then the document should change. We agreed to table our 
discussion pending relevant changes to 6962-bis.

I believe there have been no changes to 6269-bis that are relevant to 
the points Ryan and I discussed, and thus no new version of the threat 
analysis is merited.

Steve

---

From: Tim Hollebeek <[email-masked]>
Date: Fri, 3 Aug 2018 20:47:53 +0000

I just re-read large portions of the document, and I agree it should be 
published.
It appears to be in excellent shape.

-Tim

> -----Original Message-----
> From: Trans <[email-masked]> On Behalf Of Stephen Kent
> Sent: Friday, August 3, 2018 2:44 PM
> To: [email-masked]
> Subject: Re: [Trans] The trans threat analysis document
>
> The chair's message is a mis-characterization of the history and status of 
> this
> document.
>
> As the cognizant AD, Eric Rescorla  discussed the document status with the
> WG chairs early this year. Paul stated that that there were a two paragraphs 
> in
> the version -12 text (in sections 3.4 and 3.5) that were sticking points for
> David Cooper. A telecon was arranged and took place on April 12.  The
> participants were Paul, David, Eric, Richard Barnes (acting as secretary) 
> and
> me. The outcome of that telecon  was text, crafted by Richard, which was
> agreed to by all parties.  This text was incorporated into the next version 
> (-13)
> of the document which was published later in April.
>
> posted, David sent a large number (~29) of additional comments to the list.
> Thus Paul's assertion that there were only two paragraph that need to be
> changed to satisfy David was incorrect.
> rationale
> for not making changes for the remaining few comments. A new version (-14)
> was posted on May 29. I think the changes I made represent a good faith
> effort to address David's legitimate issues, especially since all of the 
> telecon
> participants believed that we had already done so in April.
>
> Ryan Sleevi and I began an exchange based on his comments, on version -14.
> Ryan argued that some of the text did not represent the intent of CT, or the
> practice of CT implementations, based on his experience as a developer. I
> countered that the analysis is based on 6962-bis, and if that text was not
> consistent with intent and practice, from his perspective, then the document
> should change. We agreed to table our discussion pending relevant changes to
> 6962-bis.
>
> I believe there have been no changes to 6269-bis that are relevant to the
> points Ryan and I discussed, and thus no new version of the threat analysis 
> is
> merited.
>
> Steve
>
> >      Hi, all:
> >

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Aug 2018 21:40:22 -0400 (EDT)

> It appears to be in excellent shape.

It is good to see interest from more people about the document.
Hopefully that can translate in text for the document.

The issues that seem to need consensus can be seen in thie message:

https://www.ietf.org/mail-archive/web/trans/current/msg03163.html

David, can you tell us which issues you raised in your message that you
believe are not yet resolved with the -14 version that was released in
response to your message?

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 4 Aug 2018 17:28:44 +0000

You don't get an infinite number of chances to object.  You get the WGLC time period. 

There was one open issue, it seems to have been addressed. You don't get to come back with more issues.

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 6 Aug 2018 15:36:22 -0400

> There was one open issue, it seems to have been addressed. You don't get to come back with more issues.

Please see the message below from the WG chairs.

On 04/16/2018 05:01 PM, Paul Wouters wrote:
>
> Hi,
>
> 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: Melinda Shore <[email-masked]>
Date: Mon, 6 Aug 2018 12:04:59 -0800

> Please see the message below from the WG chairs.

Hi, David - are you okay with the document as it stands?

Melinda

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 23 Aug 2018 17:32:48 -0400

On 08/03/2018 09:40 PM, Paul Wouters
wrote:

The
issues that seem to need consensus can be seen in thie message:

David, can you tell us which issues you raised in your message
that you

believe are not yet resolved with the -14 version that was
released in

Paul,

Below are the comments that I raised in my message on May 9 that I
believe have not been resolved.

However, it does not seem accurate to suggest that the only issues
that need consensus are the ones from my message on May 9. Andrew
Ayer and Ryan Sleevi also raised issues with the most recent draft
(see for example
https://www.ietf.org/mail-archive/web/trans/current/msg03178.html)
and I have not seen any messages on the list since then to suggest
that the issues they raised have been address - only a comment from
Steve Kent suggesting that he does not feel any changes are needed
(https://www.ietf.org/mail-archive/web/trans/current/msg03225.html).
In addition, Eric Rescorla submitted some, mainly editorial,
comments on draft -12
(https://www.ietf.org/mail-archive/web/trans/current/msg03103.html),
and there was never any response to his comments, many of which
remain unaddressed.

I would also like to note again, given the nature of
https://www.ietf.org/mail-archive/web/trans/current/msg03225.html,
that I submitted the comments on May 9 specifically because of a
request from the WG chairs
(https://www.ietf.org/mail-archive/web/trans/current/msg03146.html)
to "please review the entire document." So, any implication that
there was something inappropriate about submitting comments on new
issues after draft -13 was published is rather unfortunate.

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

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.

The response is not related to the comment. The comment did not
suggest that issuing a certificate with syntactic errors shouldn't
be considered mis-issuance, nor did it suggest that the threat
analysis document shouldn't discuss syntactic mis-issuance. The
problem is that the text suggests that the issuance of a certificate
with syntactic errors might be part of an attack, but it does not
explain how it could be part of an attack.

This text is particularly confusing in the case in which the Subject
is aware that there is an error in the certificate. The text states
that "a malicious CA may do nothing or may
delay the action(s) needed to remedy the problem." How can
the CA "attack" the Subject in this way when the Subject can just
get a new certificate from a different CA and not use the mis-issued
certificate?

The source of the problem may be that the document appears to be
using rather bizarre definitions for "threat" and "attack." For
example, there is new text in Section 2 that says:

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).

The parenthetical makes no sense. It seems to be based on some
definition of "attack" that encompasses unintentional errors while
also relying on an incorrect definition of "threat" (see below). For
what reasonable definition of "attack" could one say that an attack
may be the result of errors in the context of certificate
mis-issuance?

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).”

I can find no such DoD definition for threat, cannot find the word
"threat" in the Cornell CS 5430 syllabus, and cannot seem to access
either the MIT course 6.805 syllabus or the NRC report. I do see,
however, that Steve Kent is listed as one of the authors of the NRC
report, which suggests that it is not a independent source for the
definition. Certainly in some cases the only source of a threat may
be a "motivated, capable adversary," and in such a context the term
may be described in that way, but that does not mean the definition
of threat is limited to motivated, capable adversaries.

On the other hand, there are sources such as https://dictionary.cambridge.org/us/dictionary/english/threat
and https://en.wikipedia.org/wiki/Threat_(computer).
The Wikipedia article specifically notes that "a threat type can
have multiple origins" and it lists deliberate, accidental,
environmental, and negligence.

Also, note that in the original comment I did not suggest that
mis-issuance is a threat. When I said "Mis-issuance may be the
result of carelessness, but it is still a threat" I intended to
suggest possibility that someone could act carelessly is a threat.

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.

This text is still odd, and seems inconsistent with the previous
paragraph. The previous paragraph has new text that says "some
attacks may be the result of errors," whereas this paragraph now
says:

As noted above, the goals of CT
are to deter, detect, and facilitate remediation of attacks that
result in certificate mis-issuance in the Web PKI.  (CT also may
facilitate detection and remediation of errors that result in
certificate mis-issuance.)

So, unlike in the previous paragraph, this text seems to acknowledge
that an error is not an attack. It is still not clear the reason for
two separate sentences. What is actually "noted above" is that CT is
"designed to detect, deter, and facilitate remediation of
certificate mis-issuance" (regardless of the reason the mis-issuance
happened), so why imply that it is primarily about mis-issuance that
was caused by an attack, especially when Section 4 is devoted to
syntactic mis-issuance, which is far more likely to be the result of
an error than an attack.

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 …”

This text is still incorrect.  It now says "The
data from this [Authority Information Access] extension also may
be used by a browser to request OCSP responses from a TLS server
with which it is communicating [RFC6066][RFC6961]."

To obtain OCSP responses from a TLS server the browser just sends a
status_request [RFC6066] (or status_request_v2 [RFC6961]) extension
in the ClientHello. The status_request extension sent in the
ClientHello does not contain any information from the server
certificate's AIA extension - the client doesn't obtain the server's
certificate until after sending the ClientHello. Also, there is no
information in the AIA extension that could be included in the
status_request extension.

The sentence should just be changed to something like: "A browser
may also request OCSP responses from a TLS server with which it is
communicating [RFC6066][RFC6961]."

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.

The response here seems to be based on the highly unusual, but
unspecified definition of "attack" used in this document. The
response certainly has nothing to do with the comment, which doesn't
suggest anything like what the response implies that it does.

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.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.

See
https://www.ietf.org/mail-archive/web/trans/current/msg03160.html
and
https://www.ietf.org/mail-archive/web/trans/current/msg03103.html.

There was no suggestion that one browser makes the Internet. The
problem is that the text says, for example:

If a browser rejects certificates
without SCTs (see Section 5.4), CAs may be "encouraged" to log
the certificates they issue.  This, in turn, would make it
easier for Monitors to detect bogus certificates. However, the CT architecture
does not describe how such behavior by browsers can be
deployed incrementally throughout the Internet. As a result,
this attack model does not assume that browsers will reject a
certificate that is not accompanied by an SCT.

It might be perfectly fine to say that the attack model does not
assume that browsers will reject a certificate that is not
accompanied by an SCT since the CT architecture does not require
browsers to do so. But, that is not what the text says. The text
says that the model doesn't make the assumption because the CT
architecture does describe how browsers can do it.

The comment was not suggesting that since Chrome requires SCTs for
all newly issued certificates, the attack model needs to assume that
browsers will reject certificates not accompanied by an SCT. The
point is that since the developers of Chrome have described "how
such behavior by browsers can be deployed incrementally throughout
the Internet," the lack of such a description in "the CT
architecture" isn't relevant. Browser developers may have good
reasons not to reject certificates that are not accompanied by an
SCT, but it is not because no one described to them how to deploy
such behavior.

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.

This problem is still not addressed. The DigiNotar case was moved to
Section 3.3, where parts of the corresponding paragraph notes that
not all compromises involve theft of the private key. However, the
second paragraph of Section 3.3 still says:

The section focuses on undetected
compromise of CAs.  Such compromises warrant some additional
discussion, since some relying parties may see signed objects
issued by the legitimate (non-malicious) CA, others may see
signed objects from its compromised counterpart, and some may
see objects from both

and Section 3.3.1 begins:

In the case of a compromised
(non-malicious) CA, an attacker uses the purloined private key to
generate a bogus certificate (that the CA would not knowingly
issue).

So while there is now some text that notes that not all compromises
involve theft of the private key, there is still other text that
says otherwise.

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”.

This reference was corrected, but draft -14 still has problems with
incorrect references. I have not checked all of the references, but
there is a parenthetical in Section 3.3.1 that says "(see 3.1.2.2)" even though there is no
Section 3.1.2.2. Similarly, Section 4.2.1.3 begins "As noted above (4.1.1.4)," but there is no
Section 4.1.1.4.

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.

Both this comment and
https://www.ietf.org/mail-archive/web/trans/current/msg03160.html
noted that the final paragraph of Section 3.5 is related to the
attack in Section 3.4 and not to the contents of Section 3.5. The
text has nothing to do with the rest of Section 3.5 nor does it
"note that the cited revocation status distribution problems might
be addressed by mechanisms not specified by 6962-bis."

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.

This is a non-answer. Did the attacker do something that caused the
certificate to be mis-issued? If so, how? The CA can't be the
attacker since it is non-malicious in Section 4.1. Is this sentence
considering the possibility that the Subject could an an "attacker,"
sending a certificate request that somehow tricks the CA into
issuing an erroneous certificate? Is there any other than the CA or
Subject that could influence the contents of the certificate?

Could it be that the "attacker" had no influence over the issuance
of the certificate, but was just hoping that a certificate would be
mis-issued? If so, what role does it play in the "attack" (other
than passive observer)?

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.

As I noted previously (see, for example,
https://www.ietf.org/mail-archive/web/trans/current/msg03162.html)
this response is not related to the comment. There is a difference
between a browser checking for things that can be expected not to
change (e.g., is the keyUsage extension DER encoded -
https://www.ietf.org/mail-archive/web/trans/current/msg03172.html)
and checking for things may may change (e.g., does a subject field
that doesn't contain an organizationName attribute contain a
streetAddress attribute -
https://www.ietf.org/mail-archive/web/trans/current/msg03162.html).

While the underlying syntax rules for X.509 certificates can be
presumed to be unchanging, certificate profiles can change over
time, and this document makes clear that syntax checks includes
checking for conformance with the appropriate profile. If a browser
performed "thorough syntax checks" as this document defined that
term, then it would be effectively checking for conformance to a
particular version of a certificate profile. There can't be an
assumption that every browser on every client will be updated as
soon as any certificate profile changes, so browsers performing such
checks would create problems. As a related example, consider the
recent discussions in the TLS WG about ossification, the need to
make last-minute changes to the TLS 1.3 protocol in order to deal
with version-intolerant servers and middleboxes, and the addition of
text to RFC 8446 about protocol invariants.

There seems to be some confusion about the nature of syntactic
mis-issuance. Section 1 of the threats 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.  For example, certificates used in the Web
PKI environment might be characterized as domain validation (DV)
or extended validation (EV) certificates. Certificates used with
applications such as IPsec or S/MIME have different syntactic
constraints from those in the Web PKI context.

Yet, in the response to the above comment and in
https://www.ietf.org/mail-archive/web/trans/current/msg03174.html,
Steve seems to suggest that checking for syntactic mis-issuance is
really about checking whether certificates are valid with respect to
RFC 5280. Of course one could check for both types of errors.
However, there is a very big difference between just checking for
compliance with X.509 (RFC 5280) and checking for compliance with
the current profile rules for DV certificates.

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.

This is not a response. Neither this comment nor any other comment
suggested that syntactic mis-issuance should not be included in the
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”.

The sentence was supposed to end just "to effect revocation," but it
just ends to "to effect."

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.

See response to prior comment. A method has been defined that is
compatible with incremental deployment. It may not have been defined
in an RFC, but it has been defined. So, the text shouldn't be
implying that no one has defined a mechanism that accommodates
incremental deployment of a capability to reject certificates that
have not been logged.

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.

Again, the comment does not suggest that syntactically erroneous
certificates are not mis-issued nor does it suggest that syntactic
mis-issuance should not be discussed in this document. So, the
response does not address the comment.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Aug 2018 22:19:05 -0400 (EDT)

On Thu, 23 Aug 2018, David A. Cooper wrote:

> Below are the comments that I raised in my message on May 9 that I believe have not been resolved.

Thanks for providing these. I hope you and Steve can communicate in
private or via the list to resolve these. As we said, we are not keeping
the working group open for the threat document, so without consensus in
time this document has to find another way to move forward.

> However, it does not seem accurate to suggest that the only issues that need consensus are the ones from my message
> on May 9. Andrew Ayer and Ryan Sleevi also raised issues with the most recent draft (see for example
> https://www.ietf.org/mail-archive/web/trans/current/msg03178.html) and I have not seen any messages on the list since
> then to suggest that the issues they raised have been address - only a comment from Steve Kent suggesting that he
> does not feel any changes are needed (https://www.ietf.org/mail-archive/web/trans/current/msg03225.html). In

We stated in the past that we are not letting the threat document put a
hold on the bis document. We are not changing the bis document for the
threat document. So to me these issues cannot be taken on if it requires
changes in the bis document. Wether or not that means changes in the
threat document is up to Steve and the commentors.

> addition, Eric Rescorla submitted some, mainly editorial, comments on draft -12
> (https://www.ietf.org/mail-archive/web/trans/current/msg03103.html), and there was never any response to his
> comments, many of which remain unaddressed.

These seem minor and I trust Steve can make the appropriate changes here.

> https://www.ietf.org/mail-archive/web/trans/current/msg03225.html, that I submitted the comments on May 9
> specifically because of a request from the WG chairs
> (https://www.ietf.org/mail-archive/web/trans/current/msg03146.html) to "please review the entire document." So, any
> implication that there was something inappropriate about submitting comments on new issues after draft -13 was
> published is rather unfortunate.

Indeed. Due to the long delays between draft versions we encouraged
people to look at the entire document again. And seeing how it has
taken a lot of time again, any new WGLC on this document would also
be phrased like this.

Paul

> On 05/09/2018 08:49 AM, Stephen Kent wrote:
>        2. 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.
> 
> 
> The response is not related to the comment. The comment did not suggest that issuing a certificate with syntactic
> errors shouldn't be considered mis-issuance, nor did it suggest that the threat analysis document shouldn't discuss
> syntactic mis-issuance. The problem is that the text suggests that the issuance of a certificate with syntactic
> errors might be part of an attack, but it does not explain how it could be part of an attack.
> 
> This text is particularly confusing in the case in which the Subject is aware that there is an error in the
> certificate. The text states that "a malicious CA may do nothing or may delay the action(s) needed to remedy the
> problem." How can the CA "attack" the Subject in this way when the Subject can just get a new certificate from a
> different CA and not use the mis-issued certificate?
> 
> The source of the problem may be that the document appears to be using rather bizarre definitions for "threat" and
> "attack." For example, there is new text in Section 2 that says:
>       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).
> 
> The parenthetical makes no sense. It seems to be based on some definition of "attack" that encompasses unintentional
> errors while also relying on an incorrect definition of "threat" (see below). For what reasonable definition of
> "attack" could one say that an attack may be the result of errors in the context of certificate mis-issuance?
>
>        3. 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).”
> 
> 
> I can find no such DoD definition for threat, cannot find the word "threat" in the Cornell CS 5430 syllabus, and
> cannot seem to access either the MIT course 6.805 syllabus or the NRC report. I do see, however, that Steve Kent is
> listed as one of the authors of the NRC report, which suggests that it is not a independent source for the
> definition. Certainly in some cases the only source of a threat may be a "motivated, capable adversary," and in such
> a context the term may be described in that way, but that does not mean the definition of threat is limited to
> motivated, capable adversaries.
> 
> On the other hand, there are sources such as https://dictionary.cambridge.org/us/dictionary/english/threat and
> https://en.wikipedia.org/wiki/Threat_(computer). The Wikipedia article specifically notes that "a threat type can
> have multiple origins" and it lists deliberate, accidental, environmental, and negligence.
> 
> Also, note that in the original comment I did not suggest that mis-issuance is a threat. When I said "Mis-issuance
> may be the result of carelessness, but it is still a threat" I intended to suggest possibility that someone could act
> carelessly is a threat.
>
>        4. 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.
> 
> 
> This text is still odd, and seems inconsistent with the previous paragraph. The previous paragraph has new text that
> says "some attacks may be the result of errors," whereas this paragraph now says:
>       As noted above, the goals of CT are to deter, detect, and facilitate remediation of attacks that result
>       in certificate mis-issuance in the Web PKI.  (CT also may facilitate detection and remediation of errors
>       that result in certificate mis-issuance.)
> 
> So, unlike in the previous paragraph, this text seems to acknowledge that an error is not an attack. It is still not
> clear the reason for two separate sentences. What is actually "noted above" is that CT is "designed to detect, deter,
> and facilitate remediation of certificate mis-issuance" (regardless of the reason the mis-issuance happened), so why
> imply that it is primarily about mis-issuance that was caused by an attack, especially when Section 4 is devoted to
> syntactic mis-issuance, which is far more likely to be the result of an error than an attack.
>
>        6. 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 …”
> 
> 
> This text is still incorrect.  It now says "The data from this [Authority Information Access] extension also may be
> used by a browser to request OCSP responses from a TLS server with which it is communicating [RFC6066][RFC6961]."
> 
> To obtain OCSP responses from a TLS server the browser just sends a status_request [RFC6066] (or status_request_v2
> [RFC6961]) extension in the ClientHello. The status_request extension sent in the ClientHello does not contain any
> information from the server certificate's AIA extension - the client doesn't obtain the server's certificate until
> after sending the ClientHello. Also, there is no information in the AIA extension that could be included in the
> The sentence should just be changed to something like: "A browser may also request OCSP responses from a TLS server
>        8. 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
>       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.
> 
> 
> The response here seems to be based on the highly unusual, but unspecified definition of "attack" used in this
> document. The response certainly has nothing to do with the comment, which doesn't suggest anything like what the
> response implies that it does.
> 
>
>        10. 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.
>
>        12. 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.
> 
> 
> See https://www.ietf.org/mail-archive/web/trans/current/msg03160.html and
> There was no suggestion that one browser makes the Internet. The problem is that the text says, for example:
>       If a browser rejects certificates without SCTs (see Section 5.4), CAs may be "encouraged" to log the
>       certificates they issue.  This, in turn, would make it easier for Monitors to detect bogus certificates.
>       However, the CT architecture does not describe how such behavior by browsers can be deployed
>       incrementally throughout the Internet. As a result, this attack model does not assume that browsers will
>       reject a certificate that is not accompanied by an SCT.
> 
> 
> It might be perfectly fine to say that the attack model does not assume that browsers will reject a certificate that
> is not accompanied by an SCT since the CT architecture does not require browsers to do so. But, that is not what the
> text says. The text says that the model doesn't make the assumption because the CT architecture does describe how
> browsers can do it.
> 
> The comment was not suggesting that since Chrome requires SCTs for all newly issued certificates, the attack model
> needs to assume that browsers will reject certificates not accompanied by an SCT. The point is that since the
> developers of Chrome have described "how such behavior by browsers can be deployed incrementally throughout the
> Internet," the lack of such a description in "the CT architecture" isn't relevant. Browser developers may have good
> reasons not to reject certificates that are not accompanied by an SCT, but it is not because no one described to them
> how to deploy such behavior.
>
>        13. 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.
> 
> 
> This problem is still not addressed. The DigiNotar case was moved to Section 3.3, where parts of the corresponding
> paragraph notes that not all compromises involve theft of the private key. However, the second paragraph of Section
> 3.3 still says:
>       The section focuses on undetected compromise of CAs.  Such compromises warrant some additional
>       discussion, since some relying parties may see signed objects issued by the legitimate (non-malicious)
>       CA, others may see signed objects from its compromised counterpart, and some may see objects from both
> 
>       In the case of a compromised (non-malicious) CA, an attacker uses the purloined private key to generate a
>       bogus certificate (that the CA would not knowingly issue).
> 
> So while there is now some text that notes that not all compromises involve theft of the private key, there is still
> other text that says otherwise.
> 
>
>        15. 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”.
> 
> 
> This reference was corrected, but draft -14 still has problems with incorrect references. I have not checked all of
> the references, but there is a parenthetical in Section 3.3.1 that says "(see 3.1.2.2)" even though there is no
> Section 3.1.2.2. Similarly, Section 4.2.1.3 begins "As noted above (4.1.1.4)," but there is no Section 4.1.1.4.
>
>        18. 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.
> 
> 
> Both this comment and https://www.ietf.org/mail-archive/web/trans/current/msg03160.html noted that the final
> paragraph of Section 3.5 is related to the attack in Section 3.4 and not to the contents of Section 3.5. The text has
> nothing to do with the rest of Section 3.5 nor does it "note that the cited revocation status distribution problems
> might be addressed by mechanisms not specified by 6962-bis."
>
>        20. 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.
> 
> 
> This is a non-answer. Did the attacker do something that caused the certificate to be mis-issued? If so, how? The CA
> can't be the attacker since it is non-malicious in Section 4.1. Is this sentence considering the possibility that the
> Subject could an an "attacker," sending a certificate request that somehow tricks the CA into issuing an erroneous
> certificate? Is there any other than the CA or Subject that could influence the contents of the certificate?
> 
> Could it be that the "attacker" had no influence over the issuance of the certificate, but was just hoping that a
> certificate would be mis-issued? If so, what role does it play in the "attack" (other than passive observer)?
>
>        21. 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.
> 
> 
> As I noted previously (see, for example, https://www.ietf.org/mail-archive/web/trans/current/msg03162.html) this
> response is not related to the comment. There is a difference between a browser checking for things that can be
> expected not to change (e.g., is the keyUsage extension DER encoded -
> https://www.ietf.org/mail-archive/web/trans/current/msg03172.html) and checking for things may may change (e.g., does
> a subject field that doesn't contain an organizationName attribute contain a streetAddress attribute -
> While the underlying syntax rules for X.509 certificates can be presumed to be unchanging, certificate profiles can
> change over time, and this document makes clear that syntax checks includes checking for conformance with the
> appropriate profile. If a browser performed "thorough syntax checks" as this document defined that term, then it
> would be effectively checking for conformance to a particular version of a certificate profile. There can't be an
> assumption that every browser on every client will be updated as soon as any certificate profile changes, so browsers
> performing such checks would create problems. As a related example, consider the recent discussions in the TLS WG
> about ossification, the need to make last-minute changes to the TLS 1.3 protocol in order to deal with
> version-intolerant servers and middleboxes, and the addition of text to RFC 8446 about protocol invariants.
> 
> There seems to be some confusion about the nature of syntactic mis-issuance. Section 1 of the threats 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.  For
>       example, certificates used in the Web PKI environment might be characterized as domain validation (DV) or
>       extended validation (EV) certificates. Certificates used with applications such as IPsec or S/MIME have
>       different syntactic constraints from those in the Web PKI context.
> 
> Yet, in the response to the above comment and in https://www.ietf.org/mail-archive/web/trans/current/msg03174.html,
> Steve seems to suggest that checking for syntactic mis-issuance is really about checking whether certificates are
> valid with respect to RFC 5280. Of course one could check for both types of errors. However, there is a very big
> difference between just checking for compliance with X.509 (RFC 5280) and checking for compliance with the current
> profile rules for DV certificates.
>
>        25. 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.
> 
> 
> This is not a response. Neither this comment nor any other comment suggested that syntactic mis-issuance should not
> be included in the document.
>
>        26. 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”.
> 
> 
> The sentence was supposed to end just "to effect revocation," but it just ends to "to effect."
>
>        27. 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.
> 
> 
> See response to prior comment. A method has been defined that is compatible with incremental deployment. It may not
> have been defined in an RFC, but it has been defined. So, the text shouldn't be implying that no one has defined a
> mechanism that accommodates incremental deployment of a capability to reject certificates that have not been logged.
>
>        29. 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. 
> 
> 
> Again, the comment does not suggest that syntactically erroneous certificates are not mis-issued nor does it suggest
> that syntactic mis-issuance should not be discussed in this document. So, the response does not address the comment.
> 
> 
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 27 Aug 2018 08:54:44 -0400

David,
>>
>>  2. 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
>> *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.*
>>
>
> suggest that issuing a certificate with syntactic errors shouldn't be 
> considered mis-issuance, nor did it suggest that the threat analysis 
> document shouldn't discuss syntactic mis-issuance. The problem is that 
> the text suggests that the issuance of a certificate with syntactic 
Sorry if my reply was not clear. A cert that is syntactically 
inconsistent with criteria established by (or for) a CA could, as I 
suggested, cause problems for a Subject. I have revised the text in 
Section 4.1 as follows:

This section analyzes the scenario in which the CA has no intent to

issue a syntactically incorrect certificate, but it may do so in error. 
(Remember that errors are consideredform of attack in this document, see 
Section 2).As noted in Section 1, we refer to a syntactically incorrect 
certificate as erroneous. A certificate is erroneous if it violates a 
criteria to which the issuing CA claims to adhere. This might be a 
general profile such as RFC 5280 [5280], or a narrower profile such as 
those established by the CABF for domain validated (DV) or extended 
validation (EV) certificates. If the Subject is a web site that expected 
to receive an EV certificate, but the certificate issued to it carries 
the DV policy OID, or no policy OID, relying parties may reject the 
certificate, causing harm to the business of the Subject. Conversely, if 
a CA issues a certificate to a web site and erroneously includes the EV 
policy OID, relying parties may place more trust in the certificate than 
is warranted.

> that "a malicious CA may do nothing or may delay the action(s) needed 
> to remedy the problem." How can the CA "attack" the Subject in this 
> way when the Subject can just get a new certificate from a different 
> CA and not use the mis-issued certificate?
I hope the text above clarifies this issue, by giving two examples. It's 
not that the Subject could not detect the attack, but that the Subject 
may not detect the attack, because it does not carefully the cert issued 
to it. We know that many web servers have failed to pay attention to 
details such as expiration dates, so it does not seem unlikely that a 
server might not carefully examine the cert issued to it.
>
> The source of the problem may be that the document appears to be using 
> rather bizarre definitions for "threat" and "attack." For example, 
> there is new text in Section 2 that says:
>
>     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).
>
> may be the result of errors in the context of certificate mis-issuance?
Errors by CAs are considered attacks in some contexts, c.f., RFC 8211. 
Also, the revised text above gives examples that might be the result of 
errors by a CA.
>
>>  3. 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).”*
>>
>
> definition. Certainly in some cases the only source of a threat may be 
> a "motivated, capable adversary," and in such a context the term may 
> be described in that way, but that does not mean the definition of 
> threat is limited to motivated, capable adversaries.
I don't know what happened to the syllabi I cited. I should have copied 
the text, which seemed to have changed. Sorry.

I was  the editor of the NRC report, so the cite is not independent, but 
it's still appropriate. Also, the committee that produced the report 
included Steve Bellovin, a former Sec AD, Drew Dean, Bob Blakley, and 
other well-known security experts, all of whom were OK with the definition.

You can also find a similar characterization of "threat" in: 
https://books.google.com/books?id=jDhr1Egw-n0C&pg=PA240&lpg=PA240&dq=motivated+capable+adversary&source=bl&ots=TmazJ98jMM&sig=TR_jbWTChVQBJeJSEEZPdAkNpB8&hl=en&sa=X&ved=2ahUKEwjug9qAs4TdAhXSct8KHS_8CtUQ6AEwAnoECAgQAQ#v=onepage&q=motivated%20capable%20adversary&f=false

For the Cornell course, the syllabus may have changed, but a current 
handout page discussing threat models is available here: 
http://www.cs.cornell.edu/courses/cs5430/2018sp/lectures/04-threats/threats.pdf

Nonetheless, in the spirit of compromise, I have revised the text as 
follows:

In the context of this document, a threat is defined as a motivated, capable

adversary.

>
>>  4. 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
>> *Fair point- The text will be changed to reiterate that deterrence, 
>> detection and remediation of mis-issuance as the goal.*
>>
>
> paragraph. The previous paragraph has new text that says "some attacks 
> may be the result of errors," whereas this paragraph now says:
>
>     As noted above, the goals of CT are to deter, detect, and
>     facilitate remediation of attacks that result in certificate
>     mis-issuance in the Web PKI.  (CT also may facilitate detection
>     and remediation of errors that result in certificate mis-issuance.)
>
> "designed to detect, deter, and facilitate remediation of certificate 
> mis-issuance" (regardless of the reason the mis-issuance happened), so 
> why imply that it is primarily about mis-issuance that was caused by 
> an attack, especially when Section 4 is devoted to syntactic 
> mis-issuance, which is far more likely to be the result of an error 
> than an attack.
You're right that this text is inconsistent. I have revised the text as 
follows:

As noted above, the goals of CT are to deter, detect, and facilitate

remediation of attacks that result in certificate mis-issuance in the

Web PKI. (Note that errors by a CA are viewed as attacks in the context 
of this document.)

>
>>  6. 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)
>> *Good catch- The text in this sentence will be revised to refer to 
>> “The data from this extension …”*
>>
>
> This text is still incorrect.  It now says "The data from this 
> [Authority Information Access] extension also may be used by a browser 
> to request OCSP responses from a TLS server with which it is 
> status_request [RFC6066] (or status_request_v2 [RFC6961]) extension in 
> the ClientHello. The status_request extension sent in the ClientHello 
> does not contain any information from the server certificate's AIA 
> extension - the client doesn't obtain the server's certificate until 
> after sending the ClientHello. Also, there is no information in the 
> AIA extension that could be included in the status_request extension.
>
> The sentence should just be changed to something like: "A browser may 
> also request OCSP responses from a TLS server with which it is 
Thanks for the clear characterization of the mechanism. I'll use your 
text above in lieu of the last sentence you noted.
>
>>  8. 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.*
>>
>
> unspecified definition of "attack" used in this document. The response 
> certainly has nothing to do with the comment, which doesn't suggest 
> anything like what the response implies that it does.
>
I believe the revised text I proposed addresses this issue, i.e., the 
explicit statement that errors by a CA are viewed as attacks in this 
document.
>>
>> 10. 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
>>     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.*
>>
>> 12. 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.*
>>
>
> See https://www.ietf.org/mail-archive/web/trans/current/msg03160.html 
> and https://www.ietf.org/mail-archive/web/trans/current/msg03103.html.
>
>     If a browser rejects certificates without SCTs (see Section 5.4),
>     CAs may be "encouraged" to log the certificates they issue.  This,
>     in turn, would make it easier for Monitors to detect bogus
>     certificates. However, the CT architecture does not describe how
>     the Internet. As a result, this attack model does not assume that
>     browsers will reject a certificate that is not accompanied by an SCT.
>
>
> assume that browsers will reject a certificate that is not accompanied 
> by an SCT since the CT architecture does not require browsers to do 
> so. But, that is not what the text says. The text says that the model 
> doesn't make the assumption because the CT architecture does describe 
> how browsers can do it.
>
> The comment was not suggesting that since Chrome requires SCTs for all 
> newly issued certificates, the attack model needs to assume that 
> browsers will reject certificates not accompanied by an SCT. The point 
> is that since the developers of Chrome have described "how such 
> behavior by browsers can be deployed incrementally throughout the 
> Internet," the lack of such a description in "the CT architecture" 
> isn't relevant. 
The threat and attack analysis is based primarily on what 6962-bis says, 
not what a specific browser may have implemented, so the lack of a 
description of how to incrementally deploy mandatory SCT checking is 
relevant. However, I have revised the text in 5.4 to better address this 
issue:

If a browser is to reject a certificate that lacks an embedded SCT,

or is not accompanied by an SCT transported via the TLS handshake,this 
behavior needs to be defined in a way that is compatible withincremental 
deployment. 6962-bis does not describe a strategy for incremental 
deployment, however it calls for local policy controls that might be 
used to facilitate incremental deployment (see 3.2.2.1 earlier). For 
example a browser might establish a date after which all certificates 
issued MUST contain an SCT or be accompanied by an SCT during TLS 
session establishment. A strategy like this wouldallow certificates 
issued before that date to be “grandfathered”. This approach would allow 
a malicious CA to backdate a certificate to avoid logging it, exploiting 
a window of vulnerability.

> Browser developers may have good reasons not to reject certificates 
> that are not accompanied by an SCT, but it is not because no one 
> described to them how to deploy such behavior.
I think the text above address this comment.
>
>> 13. 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, where parts of the corresponding paragraph notes that not 
> all compromises involve theft of the private key. However, the second 
> paragraph of Section 3.3 still says:
>
>     The section focuses on undetected compromise of CAs.  Such
>     compromises warrant some additional discussion, since some relying
>     parties may see signed objects issued by the legitimate
>     (non-malicious) CA, others may see signed objects from its
>     compromised counterpart, and some may see objects from both
>
>     In the case of a compromised (non-malicious) CA, an attacker uses
>     the purloined private key to generate a bogus certificate (that
>     the CA would not knowingly issue).
>
> involve theft of the private key, there is still other text that says 
> otherwise.
I've revised 3.3.1 as follow, to address this observation:

In the case of a compromised (non-malicious) CA, an attacker may have 
acquired the CA’s private key, or it may be able to cause the CA to sign 
certificates using that key, even though the attacker does not know the 
key per se. In ether case the goal is to cause the CA to issues a bogus 
certificate (that the CA would not knowingly issue).

>> *Fair point- This reference will be changed to “Section 3.4”.*
>>
>
> there is a parenthetical in Section 3.3.1 that says "(see 3.1.2.2)" 
> even though there is no Section 3.1.2.2. Similarly, Section 4.2.1.3 
> begins "As noted above (4.1.1.4)," but there is no Section 4.1.1.4.
Thanks for noting this. I have changed the reference to be to 3.2.2.1 I 
expect the RFC Editor will work with us to find and correct other typos 
of this sort.
>
>> 18. 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.*
>>
>
> Both this comment and 
> noted that the final paragraph of Section 3.5 is related to the attack 
> in Section 3.4 and not to the contents of Section 3.5. The text has 
> nothing to do with the rest of Section 3.5 nor does it "note that the 
> cited revocation status distribution problems might be addressed by 
> mechanisms not specified by 6962-bis."
I have moved the paragraph to the end of 3.4, and revised the text, 
slightly, to better fit there.
>
>> 20. 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.*
>>
>
> certificate to be mis-issued? If so, how? The CA can't be the attacker 
> since it is non-malicious in Section 4.1. Is this sentence considering 
> the possibility that the Subject could an an "attacker," sending a 
> certificate request that somehow tricks the CA into issuing an 
> erroneous certificate? Is there any other than the CA or Subject that 
> could influence the contents of the certificate?
>
> Could it be that the "attacker" had no influence over the issuance of 
> the certificate, but was just hoping that a certificate would be 
> mis-issued? If so, what role does it play in the "attack" (other than 
> passive observer)?
Section 4.1 deals with a non-malicious CA, so the CA is not 
intentionally mis-issuing a cert, but it may mis-issuae a cert as a 
result of an error. The revised text for 4.1 makes this clear.
>
>> 21. 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.*
>>
>
> https://www.ietf.org/mail-archive/web/trans/current/msg03172.html) and 
> checking for things may may change (e.g., does a subject field that 
> doesn't contain an organizationName attribute contain a streetAddress 
> attribute - 
> presumed to be unchanging, certificate profiles can change over time, 
> and this document makes clear that syntax checks includes checking for 
> conformance with the appropriate profile. If a browser performed 
> "thorough syntax checks" as this document defined that term, then it 
> would be effectively checking for conformance to a particular version 
> of a certificate profile. There can't be an assumption that every 
> browser on every client will be updated as soon as any certificate 
> profile changes, so browsers performing such checks would create 
> problems. As a related example, consider the recent discussions in the 
> TLS WG about ossification, the need to make last-minute changes to the 
> TLS 1.3 protocol in order to deal with version-intolerant servers and 
> middleboxes, and the addition of text to RFC 8446 about protocol 
> invariants.
I agree that trhe phrase thorough syntax checks" is ambiguous, and that 
adherence to a version of a cert profile is something that would be hard 
to a browser to check. However,a (now expired) I-D described exactly how 
a log could check for compliance to a specified version of a profile, as 
asserted by a CA, which would address the issue you cite. So, I have 
rewored the text as follows (and fixed the refereces to 4.1.1.4 to be to 
4.1.3.2.

Unfortunately, experience suggests thatmany browsers do not always 
perform very good syntactic checks oncertificates. For example, a 
browser may fail to verify that a certificate used in a certificate path 
is properly marked as a CA certificate. Also, it would be problematic 
for a browser to check a certificate against a specific version of a 
profile if the profile changes and the policy OID remains constant. Thus 
it seems unlikely that browsers will be a reliable was to detect 
erroneous certificates in all circumstances.

>     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.  For example,
>     certificates used in the Web PKI environment might be
>     characterized as domain validation (DV) or extended validation
>     (EV) certificates. Certificates used with applications such as
>     IPsec or S/MIME have different syntactic constraints from those in
>     the Web PKI context.
>
> RFC 5280. Of course one could check for both types of errors. However, 
> there is a very big difference between just checking for compliance 
> with X.509 (RFC 5280) and checking for compliance with the current 
I agree that there are different criteria against which syntactic 
mis-issuance may be judged. I thiink the revised text for 4.1, which 
cites DV and EV profiles, and the uodated text for4.1.3.2, address the 
concern you cited.

>
>> 25. 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.*
>>
>
The revised text for 4.1 provides examples of how syntactic mis-issuance 
may result in an attack.
>
>> 26. Section 5.3 says
>>
>> oIt 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”.*
>>
>
Sorry for the omission of "revocation". I've fixed that.
>
>> 27. 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.*
>>
>
> in an RFC, but it has been defined. So, the text shouldn't be implying 
> that no one has defined a mechanism that accommodates incremental 
> deployment of a capability to reject certificates that have not been 
> logged.
The document did not mean to imply that no browser has a strategy for 
incremental deployment. I have revised the text in 5.4 to address this 
comment.

Section 3.1.2.1 mentioned incremental deployment. Upon re-reading it, I 
decied to delete that section, as it is in a part of the analysis that 
deals with a non-malicious CA.

Section 3.2.2.1 also mentioned incremental deployment. I have revised 
that text as follows:

If careful browsers reject certificates without SCTs, CAs may be

"encouraged" to log certificates (see section 5.4.)However, the CT 
architecture does not require a browser to reject a certificate lacking 
a matching SCT (or equivalent evidence of logging) in all cases. This is 
a matter of local policy. Section 8.1.6 of [6962-bis] says: “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.” As a result, this attack model does 
not assume that browsers will reject a certificatethat is not 
accompanied by an SCT in all circumstances.Since certificates have to be 
logged to enable detection of mis-issuance by Monitors, and to trigger 
subsequent revocation, the effectiveness of CT is diminished in 
circumstances where local policy does not mandate SCT or inclusion proof 
checking.

>
>> 29. 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.*
>>
>>
Hopefully the revised text for 4.1 address this concern.