User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040628 Firefox/0.9.1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040628 Firefox/0.9.1 Request to include CA certificates for the Comodo Group (EnterpriseSSL and InstallSSL services). For CA-related information see <http://www.hecker.org/mozilla/ca-certificate-list/>. Note that Comodo has been "WebTrust for CA" audited, and hence I plan to approve their inclusion under the current interim Mozilla Foundation policy, unless I hear any substantial objections. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Accepting bug as assigned to me.
Status: NEW → ASSIGNED
I have a couple of additional questions for the Comodo folks: 1. Are there URLs where the CA certs are available in a format suitable for direct loading into Mozilla (i.e., you can click on the links and get the Mozilla certificate dialog)? If I recall correctly the certs have to be available with a certain MIME type; I forget which one right at the moment. 2. Are there URLs where CRLs can be downloaded? IIRC the CPS says they can be downloaded at the repository URL <http://www.comodogroup.com/repository>, but they're not there. My approval is contingent on getting at least question 2 above answered. (After all, right now I have no idea if Comodo really maintains and publishes CRLs or not.)
Answers to your questions:- 1) We have put the certificates on http://www.comodogroup.com/repository (at the end). We think we have the mime-type right, but aren't 100%. 2) The CPS says that the CRL is available as indicated in the certificate profile. The certificate profile says that the URL for the CRL is in the end- entity certificate. The URLs for the three CRLs are:- http://crl.comodo.net/AAACertificateServices.crl http://crl.comodo.net/SecureCertificateServices.crl http://crl.comodo.net/TrustedCertificateServices.crl
Thanks for adding this information. Clicking on the CA certificate links still doesn't invoke the proper Mozilla dialog. You are presenting the certificates as MIME type "application/pkix-cert", but I think the needed MIME type is "application/x-x509-ca-cert", at least per <http://wp.netscape.com/eng/security/ssl_2.0_certificate.html>, which I think is the original reference for this. See also Nelson Bolyard's post at <http://firstname.lastname@example.org/msg03257.html> for some background information on this. I believe that for CRLs the necessary MIME type for Mozilla to recognize them is "application/x-pkcs7-crl", but I haven't found official documentation to confirm this. Note that Mozilla behavior differs from MSIE behavior, so you may need to include two different sets of links in order to cater to both.
(In reply to comment #4) > You are presenting the certificates as > MIME type "application/pkix-cert", but I think the needed MIME type is > "application/x-x509-ca-cert", at least per > <http://wp.netscape.com/eng/security/ssl_2.0_certificate.html>, which I think is > the original reference for this. Actually <http://wp.netscape.com/eng/security/comm4-cert-download.html> is the more recent reference; however note that it still doesn't address the question of MIME types for CRL links.
(In reply to comment #4) > I believe that for CRLs the necessary MIME type for Mozilla to recognize them > is "application/x-pkcs7-crl", but I haven't found official documentation to > confirm this. From the Mozilla source code, the MIME type used by Mozilla for CRLs is indeed "application/x-pkcs7-crl"; see http://lxr.mozilla.org/mozilla/source/netwerk/mime/public/nsMimeTypes.h#84 I have not been able to find any place where this is documented other than in the source code itself. Note that RFC 2585, "Internet X.509 Public Key Infrastructure, Operational Protocols: FTP and HTTP" defines the MIME type of "application/pkix-crl" for CRLs transported by HTTP. Mozilla doesn't use the corresponding MIME type "application/pkix-cert" defined in RFC 2585 for certificates, for reasons noted in Nelson's post referenced above and in bug 184649. However the reasons noted by Nelson (e.g., there are multiple types of certs) don't necessarily apply in the CRL case; for example, AFAIK there's only one type of CRL we need to deal with, at least at present. So it's an open question whether Mozilla should support "application/pkix-crl" as an alternative to "application/x-pkcs7-crl". But in any case that's a discussion for another bug. For now the answer is that Comodo should make CRLs available with MIME type "application/x-pkcs7-crl" in order for Mozilla users to be able to download and install them. I suggest Comodo consider doing this, because even if we preload the Comodo root CA certs we can't prload the CRLs given Mozilla and NSS as they exist today; thus Mozilla users wishing to validate Comodo-issued certs will need to download the Comodo CRLs and get them installed in Mozilla. Also note that AFAIK Apache (at least Apache 2.0) does not have a pre-defined MIME type for CRL files, so by default CRLs would presumably be served as plain/text files as far as Mozilla is concerned. (However IE would probably recognize them based on the .crl suffix, since IIRC IE allows file extensions to override the MIME type, at least in certain contexts. http://www.apps.ietf.org/rfc/rfc2585.html
I just checked, and apparently the Comodo CRLs are now indeed served up by the correct MIME type and are loadable into Mozilla by clicking on the links. The CA certs appear to be still served up as application/pkix-cert, with no option to download them with MIME type x-x509-ca-cert. However this is of less concern to me since downloading the certs won't be necessary if/when they're pre-loaded into Mozilla. I've updated the draft CA page at http://www.hecker.org/mozilla/ca-certificate-list/ to reflect the new CRL URLs. Pursuant to my comments, I'm going to approve Comodo for inclusion in Mozilla absent further objection. Going once, going twice...
Frank, IINM, the application/x- MIME content types were add devised prior to the standardization of other official MIME content types for these data types. Now that standard content types exist, I agree that PSM should honor them, in addition to the old ones (for backwards compatibliity), especially for CRLs. Sounds like another PSM RFE. I also opine that mozilla should now handle the standard MIME content type for certs, and should choose UI based on the content of the cert actually downloaded.
Per my earlier comments, I'm approving Comodo Group CA certs for inclusion in Mozilla. I'm off now to file a bug against NSS to actually add the certs.
Frank, It has been my experience that the comodo web site for enrollment for certs only works with IE, not with mozilla/Netscape. That is reflected in the instructions that I posted to the newsgroup about how to obtain a comodo email cert. news://news.mozilla.org:email@example.com Should the ability to entroll for a cert with mozilla be a criterion for acceptance, at least for email certs?
Refering comment #10, I suggest the proposed policy require the following for any authority's root certificate to be installed in the Mozilla database: 1. The Web site (all public pages) of the certificate authority must be viewable via Mozilla. 2. A user must be able to acquire root certificates directly from the authority while using Mozilla. 3. A client of the authority must be able to obtain (order and receive) certificates while using Mozilla. 4. A Web page, E-mail message, or other data entity signed by a certificate issued by the authority and signed by the authority's root certificate must be capable of being verified while using Mozilla providing the data entity itself can be viewed or otherwise appropriately processed by Mozilla.
(In reply to comment #11) > Refering comment #10, I suggest the proposed policy require the following for > any authority's root certificate to be installed in the Mozilla database: <snip> This should really be part of a discussion in n.p.m.crypto, and I'll include this topic when I get a chance to re-start the public discussion on criteria (soon, I hope). I think requirements like this are reasonable but not necessarily something we want to be rigid about. For example, take the requirement that the CA support enrollment using Mozilla. Remember that the CA's customers are not necessarily the same population as would be actually encountering the CA-issued certs in web browsing, etc. As a somewhat contrived but at least plausible example, consider a CA that issues server certs only to banks, using some special private mechanism. Here whether the CA allows enrollment using Mozilla is irrelevant, since no Mozilla user would actually be enrolling; the users just want to be able to use Mozilla to connect to their banks' SSL-enabled web sites.
Frank, Nelson has added these root CA certs to NSS. So you can mark the bug fixed now.
Certificates are in Firefox 1.0.2 and Thunderbird 1.0.2; resolving as fixed and removing dependency on bug 252132.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
No longer depends on: 252132
Resolution: --- → FIXED
*** Bug 239484 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.