Frank Hecker wrote:
I'm finally getting back to working on requests for CA for their root certificates to be included in NSS/Mozilla. (Yes, I suck for leaving this undone for so long; my apologies.)

The first one I'm working on is for StartCom Ltd., bug 289077:

  https://bugzilla.mozilla.org/show_bug.cgi?id=289077

StartCom issues class 1 ("low assurance") and class 2 SSL and email certs. They've successfully completed an independent audit using the WebTrust for CAs criteria. Leaving aside a couple of open questions (as noted in the bug) StartCom appears to meet the requirements of our current CA cert policy.

The main "twist" in this case is that StartCom offers class 1 certificates at no charge, with an automated verification process (basically sending emails to standard addresses for domains with an authorization code to be "entered" by clicking a link back to the StartCom site). There's an obvious concern about this service being used fraudulently by phishers, and a philosophical issue about whether we should ever approve a no-charge CA that uses automated verification. (A no-charge CA with a more rigorous verification procedure would be a different issue.)

On the flip side, having to pay to register domain names has proved to not be an obstacle for phishers (especially when you can pay for them with stolen credit cards), and the lowest current prices for SSL certs ($15/year) are comparable to domain name registration fees. So it's not clear that this would worsen the situation from where it already is.

Feel free to comment on the bug regarding this specific application. If you have more general comments (i.e., not necessarily related to StartCom) please use the newsgroup/mailing list instead.

I'm going to allow a 1-2 week comment period for this request (depending on how many comments I get), and then I'll make a decision on this request.

Frank


For any class of certificate and for any certificate type (i.e., mail authentication, Web site security, code-signing), I would expect two levels of subscriber verification.

The first level would be to verify that the Web domain or E-mail address for the subscriber's certificate is indeed "owned" by the subscriber or that the person applying for the subscriber certificate is indeed authorized to do so by the owner. This appears to be met by StartCom's practices.

The second level would be to verify that the owner of the Web domain or E-mail address is indeed who he or she claims to be. For StartCom Class 1 certificates, this does not appear to be met by StartCom's practices. This level cannot be automated and requires positive identification of the corporeal persona, not of some abstract Internet entity.

These two levels of verification are very similar to the "web of trust" concept developed by Phil Zimmermann for PGP users. (1) You verify that someone owns a public key. (2) You verify that the owner of a public key is indeed who he or she claims to be. Once both levels are satisfied, you can mark that other person's public key as valid (by signing it with your own key). Once you see that the other person takes the same amount of care in verifying your own ownership and identity, then you can trust other public keys signed by that person.

No, there is no absolute certainty in verifying the identity of a person to be as claimed. But there is some degree of confidence established when the person provides more than one form of identification. See my <http://www.rossde.com/PGP/pgp_keysign.html>; scroll about half-way down the page to "The Conduct of the Party" and read the second bullet under "Items required". Of course, this is only for validating and trusting PGP keys of individuals, not keys of businesses.

Note that my checklist for CA audit (originally developed for reviewing CACert, another free certificate authority) specifies:

The CP clearly describes how the identity of each certificate
> subscriber is verified.

The CP clearly describes how the relationship of each subscriber
> for an E-mail certificate to the E-mail address is verified.

For a site certificate, the CP clearly describes how the relationship of the subscriber to the domain is verified, including a provision that a site certificate cannot be issued to a subscriber who does not own or otherwise control
the registration of the affected domain.

For a subscriber certificate to be used for authenticating files (e.g., code-signing certificates), the CP clearly describes how the relationship of the subscriber to the organization identified within the certificate is verified.

My intent was to address identifying the persons who are subscribers, well beyond merely verifying Web domains and E-mail addresses. According to the StartCom CP (Sect. 11.III.A), that level of verification is not done for Class 1 subscriber certificates.

In conclusion, I would not trust any Class 1 subscriber certificate issued or signed by StartCom. I would recommend against including in a Mozilla product any root or intermediate certificate used by StartCom to sign its Class 1 subscriber certificates.

As I indicated for CACert, those who really want the StartCom root or intermediate certificates can always download and install them, thereby assuming all risks without foisting those risks on Mozilla.

--

David E. Ross
<http://www.rossde.com/>

Concerned about someone (e.g., Pres. Bush) snooping
into your E-mail?  Use PGP.
See my <http://www.rossde.com/PGP/>
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to