On 1 May 2006 19:07:58 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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.
Nor should it be, class 1 certificates means that only cursory checking
is done, regardless of the CA. Look at all the CAs that are signed by
GeoTrust that are already validated because it, Komodo, and Registerfly
are the 2 that spring to mind.
I know, from using Registerfly, that no greater care is given issuing
certificates thru registerfly than is done for Class 1 certs from
StartCom.
Does this fact mean that you are going to remove your GeoTrust root and
only accept "High Assurance" certificates from now on? I doubt it,
try doing it on your personal browser and see how far you get.
Yet another example of why the X.509 certificate system as it exists
is broken... but, nothing that we can do, other than work around it.
Would it be possible to offer a "default/legacy" view of the lock
icon, and then change the UI to have a "(ID unverified)" or such next
to the lock for those CAs that we know do issue or have issued class 1
certificates? (If the CPS template RFC were updated to include a
means of defining how different classes of certificates would be
marked, this would be easier...)
But even then, I'm fairly confused as to the meanings of the terms
"class 1", "class 2", and "class 3" (which are the only terms I've
seen used). Is there a standard definition?
> 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.
...just as I don't trust the Thawte root certificate because it issues
SSL123 certificates, but it's already included in the browser. I had
to explicitly remove trust for it, so that I could see when a given
cert was fully validated or domain-validated.
> 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.
...and I'll make the point that 2 others have made, that there are
already certificates accepted in Mozilla's root store that have
already foisted those risks on Mozilla. What's Mozilla's exposure?
(Is there a member of the legal team available?)
As long as the big CAs like Verisign, Thawte, and GeoTrust offer
certificates that are less than thoroughly checked, or sign the root
certs for CAs who offer them, I don't believe it is fair to exclude a
CA soley on these grounds.
Agreed. They've been independently audited, which means that they
don't issue certificates (and have procedural safeguards in place to
prevent the issuance of certificates) in ways different than their
policies state. The larger CAs who pay for audits only get audted
once, and then they change their practices or procedures, and the
audit shouldn't be valid anymore. (Kinda like FIPS 140-2
certification.)
At least with StartCom they actually use the terms "Class 1" and "Class
2" in the names of the Intermediate CAs so you can easily SEE which
verification level a cert has received. I wish the big CAs did that.
So do I.
-Kyle H
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
