Frank Hecker posted a plausible identification policy:
...The specific language of TS 102 042 applicable to the LCP is as
follows:
7.3.1. Subject registration ...
e) [CHOICE]:
[LCP] No requirement.
[NCP] If the subject is a physical person evidence of the subject's
identity (e.g. name) shall be checked against a physical person
either directly or indirectly using means which provides equivalent
assurance to physical presence (see note 2). Evidence for verifying
other entities shall involve procedures which provide the same
degree of assurance.
NOTE 2: An example of evidence checked indirectly against a physical
person is documentation presented for registration which was acquired
as the result of an application requiring physical presence.
f) [CONDITIONAL] If the subject is a physical person, evidence shall
be provided of: - full name (including surname and given names); -
date and place of birth, reference to a nationally recognized identity
document, or other attributes which may be used to, as far as
possible, distinguish the person from others with the same name.
NOTE 3: It is recommended that the place be given in accordance to
national conventions for registering births.
Here 7.3.1.e appears to dispense with id checks for the LCP policy,
but then 7.3.1.f appears to bring them back again, and in a manner
which appears to be overkill for a simple low-assurance email cert
(where our primary concern is whether the user controls the email
account). Other provisions such as 7.3.1.j (requirement for physical
address) also appear to be overkill for this scenario.
So having thought about it some more I think that if we do want a
"floor" maybe it would be better to specify LCP as a general floor
(i.e., not worry about NCP) and then tweak things a tad to avoid
overkill. But I'm still thinking about this...
I'm curious about this identity requirement. Has
anyone here in the debate ever worked in or
near a business that does this?
As this a quasi-security list, I'm sure you'll
understand the security nature of these
questions. The goal is the security of the end
users, right?
Of those who worked in a business that routinely
checks for identity, etc, has anyone got a feeling
for how easy or hard it is for an attacker to bypass
the system?
That is, if we were to put in place the above floor
(loosely interpreted as "check the identity of the
applicant with reference to some documents") then
the CAs would ... follow that.
And Mozilla's users would be then protected ?
So, how much would the be protected? Would we
be able to
a) guaruntee no fraudulently issued certs,
b) show a significant reduction in fraudulently
issued certs
c) show a minor or statistically insignificant
reduction
d) no change at all, or
e) make matters worse?
Secondly, when it came to where the rubber meets
the road, would we see
a) no more fraudulent transactions (e.g., phishing)
b) a significant reduction in fraud transactions
c) a minor or statistically insignificant reduction,
d) no change at all, or
e) makes matters worse!
(I hope you can see the difference in that the first
is about issuing certs to 'the wrong party' and the
second is about money being stolen from users.)
Now, we can fiddle with those choices, and also
fiddle with the money test. I chose phishing because
it's the one with a billion dollar price tag, per annum,
but someone else might choose eavesdopping on
private sex chat for blackmail purposes. Whatever.
But the core thing here is: We take Action A. How
does this lead to Result B ? Can we show that?
It sort of comes down to, is a phisher going to be
deterred by Action A?
iang
To protect my (IMAP/SMTP) passwords why should a certificate have as
much checking as for a site doing $1,000,000 transactions?
I'm not sure anyone is claiming that it does. However... I think what
people (e.g., Gerv) *are* claiming is that you can't make requirements
for e.g., IMAP/SSL certs too loose or otherwise you make phishing
attacks involving SSL-enabled web sites easier, since in practice CAs
just issue "SSL certs" independent of what their intended use is.
Right. So see above. If you tighten up the requirements,
can you show that they actually slow down the phishing?
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
