SSL server certificates don't only just relate to money, I use them for IMAP and SMTP and again this goes back to my comments about making things no longer black and white security, I don't see how you can lump everyone in 1 box and say ok this is the 1 size fits all category, Ian gave a very good reason to split things up. How can you possibly fit everyone into the US centric documentation required model if there is no documentation or it's of dubious origins?
Thanks for your comments. For the record, I too use SSL for IMAP and SMTP on the hecker.org site (actually a virtual host within a larger site that I administer), and I understand the point about all SSL use not being connected to ecommerce.
I think the issue comes down to this: 1) Should the policy specify a "floor" in terms of acceptable CPs and CPSs; and 2) If so, what should that policy be?
If you look at something like the LCP from TS 102 042 I think it would be sufficient to rule out most of the practices Nelson was highlighting in his extreme test case in bug 233458. Does it rule out all of the practices Nelson was concerned about? I haven't double-checked yet to see.
Another issue is whether even the LCP is overkill in the context of certificate application indentification. 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...
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.
(Of course the browser or email client could make such distinctions, since they know the context in which a cert is being used, and in theory the email client could accept an SSL cert for use with IMAP/SMTP and the browser not accept that same cert for use with HTTP. But this gets us into the area of requiring new implementations in order to create a policy, and I want to avoid that, at least for a 1.0 policy.)
Why should informational items on certificates be simply considered just that, why shouldn't there be some minimum requirements to remove the confusion and not to mention the potentially misleading situation that gets hidden away in the fine print.
I'm sorry, I'm a bit confused here: It appears that you are agreeing that it would be a good idea for the policy to include some minimum requirements for CAs in terms of their policies (i.e., avoid the scenario Nelson mentioned where we're simply asking CAs to provide evidence they're following their CPS, no matter how loose), but you're disagreeing on what those minimum requirements should be. Am I correct? If not, could you clarify?
If you want case studies on webmail, smtp, imap and other browser related functions that have nothing to do with monetary relations and how companies use their certificates I will post something to the CAcert mailing list and get people to express their current situations on the matter, because I know for a fact I'm not the only one in this boat, and the mailing list archives show this fact time and time again.
As I mentioned above, I don't need convincing that use of SSL certs for non-financial transactions, including use with IMAP, SMTP, webmail, etc., is a major use case. It's certainly of great interest to me personally.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
