On 1/10/2018 8:15 μμ, Ryan Sleevi via dev-security-policy wrote:
On Mon, Oct 1, 2018 at 9:21 AM Dimitris Zacharopoulos <[email protected]>
wrote:
[...]
I am certainly not suggesting that CAs should put inaccurate and
misleading information in certificates :-) I merely said that if the
Subscriber introduces misleading or inaccurate information in certificates
via a reliable information source, then there will probably be a trail
leading back to the Subscriber. This fact, combined with the lack of clear
damage that this can cause to Relying Parties, makes me wonder why doesn't
the Subscriber, that wants to mislead Relying Parties, just use a DV
Certificate where this probably doesn't leave so much evidence tracing back
to the Subscriber?
"The lack of clear damage" - I'm not sure how better to communicate, since
we're discussing fundamental damage to the value that OV and EV are said to
provide. The only way we can say "lack of clear damage" is to say that OV
and EV are worthless - otherwise, it's incredibly damaging.
I'm actually still waiting for Ian to elaborate if the "attack" was just
the insertion of an intentionally wrong address in an EV Certificate or
if he was attempting something else. Although his attempt failed (no
Certificate was issued with that wrong Street Address), I consider the
discussion that followed very useful (at least to me).
For this particular case though, a Company's righful owner or Legal
Representative can file for an address change to a government registry
and I am not aware about what additional verification (if any) is
performed by the government. We must have something to compare this
process to, in order to establish what is "reasonably verified".
I have no idea where the notion of 'tracability' comes from, or why that's
relevant. It again seems to be anchoring on getting a certificate for the
real cloudflare.com or stripe.com, which is not the discussion. We're
talking about "confusing" a user (or subscriber or relying party or threat
monitoring system) by suggesting that the certificates being issued are
'benign' or 'authorized'.
Yes, it's clear that this is a follow-up discussion of
https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/stripe%7Csort:date/mozilla.dev.security.policy/NjMmyA6MxN0/1cC9IrwjCAAJ.
Sorry for the confusion.
But this inaccurate data is not used in the validation process nor
included in the certificates. Perhaps I didn't describe my thoughts
accurately. Let me have another try using my previous example. Consider an
Information Source that documents, in its practices, that they provide:
1. the Jurisdiction of Incorporation (they check official government
records),
2. registry number (they check official government records),
3. the name of legal representative (they check official government
records),
4. the official name of the legal entity (they check official
government records),
5. street address (they check the address of a utility bill issued
under the name of the legal entity),
6. telephone numbers (self-reported),
7. color of the building (self-reported).
The CA evaluates this practice document and accepts information 1-5 as
reliable, dismisses information 6 as non-reliable, and dismisses
information 7 as irrelevant.
Your argument suggests that the CA should dismiss this information source
altogether, even though it clearly has acceptable and verified information
for 1-5. Is that an accurate representation of your statement?
Yes, I'm stating that the existence of and inclusion of 5-7 calls into
question whether or not this is a reliable data source.
Right, but in my example, the data source has already described -via
their practices- that this is how they collect each piece of data. The
CA, as a recipient of this data, can choose how much trust to lay upon
each piece of information. Therefore, IMHO the CA should evaluate and
use the reasonably verified information from that data source and
dismiss the rest. That seems more logical to me than dismissing a data
source entirely because they include "the color of the building", which
is self-reported.
Your parenthetical
about how they check that is what the CA has the burden to demonstrate,
particularly given that they have evidence that there is less-than-reliable
data included. How does the competent CA ensure that the registry number is
not self-reported -
The information in the parenthesis would be documented in the trusted
source practices and the CA would do an inquiry to check that these
practices are actually implemented and followed.
or that the QIIS allows it to be self-reported in the
future?
No one can predict the future, which is why there is a process for
periodic re-evaluation.
This is where the 'stopped-clock' metaphor is incredibly appropriate. Just
because 1-5 happen to be right, and happen to be getting the right process,
is by no means a predictor of future guarantees or correctness or accuracy.
Of course, this is why you need re-evaluation. You can't guarantee
correctness for anything, otherwise we wouldn't have cases of
mis-issuance or mis-behavior. We add controls in processes to minimize
the risk of getting bad data.
More importantly, the inclusion of 5-7 in the reporting suggest that there
is *unreliable* data actively being seen as acceptable, and because of
that, the CA needs to take a view against including.
I am not sure if you have misunderstood my description, but let me
repeat that despite getting the full data set, the CA would use only the
information pre-evaluated as reliable, and that doesn't include
self-reported data which they know -beforehand- (because it is
documented in the data source's practices) it is self-reported.
[...]
Funny enough, that subjectivity you just described is not permitted of CAs,
and for good reason. Every one of those certificates needs to be revoked,
per 4.9.1.1 of the BRs. The CA has also material misstated its warranty for
these certificates, per 9.6.1.
Yet we've seen this being exercised before and definitely in violation of
the 24 hour window. The main issue that we have seen some CAs struggle with
and explain in Incident Reports is that this information might actually be
proven to be accurate and can be re-validated without causing interruptions
for Subscribers and Relying Parties.
This is the stopped-clock argument - that the process to getting that
information doesn't matter, as long as the information turns out eventually
consistent. However, the act of certification is about ensuring that the
process is well-formed.
It was considered well-formed when the certificate was issued.
If the only backstop against misissuance is
eventual consistency, then there's no incentive to get the process correct.
And if the process isn't correct, there's nothing to mitigate adversarial
impact.
This is not what is described in the current requirements. Re-evaluation
of data sources, quarterly internal reviews are some of the existing
controls to check for possible inconsistencies and flaws in existing
processes with a goal of improving and correcting these processes. The
CA audit schemes themselves aim for continuous improvements in all areas
(organizational and technical controls).
I have already agreed that creating a global list of reliable
information sources is great because transparency will bring common
understanding in the evaluation processes. Until we get there though,
there is room for improving existing requirements and, as Tim said, one
does not prevent the other.
By comparison, we don't leave the root password to our servers as "secret",
with the assumption that 99/100, the person logging in to that server will
be authorized. Just because it's eventually consistent doesn't mean it's
not fundamentally flawed.
Your example is analogous only if the CA "knowingly" allowed and used
self-reported information from a data source. Just like the
administrators intentionally leaves the root password as "secret" when
they know this is a very insecure practice. My examples described that
the CA WOULD NOT accept and use unreliable information from a data
source but only reliable information that had been previously evaluated.
A better analogy might be for the administrator to set the password to
minimum 8 characters (alphanumeric/mixed case/special characters) and
during re-evaluation decided to improve it to minimum 12 characters.
This change of password policy doesn't imply that the previous setting
was insecure or that the server is compromised.
Similarly, if the CA accepted a piece of information (street address)
from data "source A" that was considered reliable during certificate
issuance, but during re-evaluation the CA discovered that this
information is more reliable in "source B", they can check all existing
validations that include the "street address" attribute and compare it
with the new -more reliable- information. Again, these are theoretical
examples and reality is more complicated. We have seen different
reactions from different CAs in the past for clear cases of mis-issuance
and cases where there is a suspicion that some of the information is not
accurate. The only very clear case which resulted in revocations from
all affected CAs was the .tg TLD compromise
(https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00052,Q00053).
This seems to be the safest approach in general.
Dimitris.
If you believe that there are national jurisdictional databases, they can
be added to the whitelist. Indeed, the entire point would be to ensure
that, for the appropriate jurisdictional boundary, there's a clear
indication as to appropriate data sources. Then, there is no need for CA
discretion - or indiscretion.
You are basically suggesting that the evaluation of a data source
performed by the CA (at least for the smaller jurisdictions) be made public
and added in the white-list. I'm fine with that. However, we will face the
same problem if during re-evaluation we discover that some piece of
information is not as reliable as we thought.
Of course, but then we end up with a consistent interpretation and
application of that data.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
