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
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.
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.
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?
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).
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?
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).”*
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.
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
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.
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)
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]."
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.*
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.
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
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 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.
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.*
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.
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).
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.
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
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."
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.*
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 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.*
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.
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.
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.
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.*
This is not a response. Neither this comment nor any other comment
suggested that syntactic mis-issuance should not be included in the
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”.*
The sentence was supposed to end just "to effect revocation," but it
just ends to "to effect."
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.*
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.
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.*
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.
Hopefully the revised text for 4.1 address this concern.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
