Closed
Bug 242610
Opened 20 years ago
Closed 18 years ago
Add USERTRUST Root certificates
Categories
(CA Program :: CA Certificate Root Program, task)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: support, Assigned: hecker)
References
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: We contacted Frank Hecker about adding our root certificates and he asked we submit the request as a bug report. We are a Certificate Authority located in Salt Lake City, UT and would like the following roots added: 1.) UTN-USERFirst-Client Authentication and Email Certificate URL: http://www.usertrust.com/cacerts/UTN-USERFirst- ClientAuthenticationandEmail.crt CRL URL: http://crl.usertrust.com/UTN-USERFirst- ClientAuthenticationandEmail.crl 2.) UTN-USERFirst-Hardware Certificate URL: http://www.usertrust.com/cacerts/UTN-USERFirst-Hardware.crt CRL URL: http://crl.usertrust.com/UTN-USERFirst-Hardware.crl 3.) UTN-DATACorpSGC Certificate URL: http://www.usertrust.com/cacerts/UTN-DATACorpSGC.crt CRL URL: http://crl.usertrust.com/UTN-DATACorpSGC.crl 4.) UTN-USERFirst-Object Certificate URL: http://www.usertrust.com/cacerts/UTN-USERFirst-Object.crt CRL URL: http://crl.usertrust.com/UTN-USERFirst-Object.crl The url for our CPS is: http://www.usertrust.com/cps As to the audit requirements, while we have not undergone a full WebTrust audit, we have been a certificate authority since 1999 and have passed successive CS2 audits. This last year we expanded the audit to include testing for compliance with the SISAC CPRD and accreditation by SISAC. We believe the SISAC standards to be equal to or exceed the WebTrust review. We have begun our 2004 CS2 and SISAC audit that should be completed in mid June 2004. Please feel free to contact me if you have any further questions, nl@usertrust.com Reproducible: Always Steps to Reproduce: 1. 2. 3.
Assignee | ||
Comment 1•20 years ago
|
||
Accepting this bug into the queue of pending requests from CAs. PS to the UserTrust folks: thanks for including the detailed info including URLs, usually I have to hunt that stuff down :-)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 2•20 years ago
|
||
I just noticed that when you submitted this bug you marked it as security-sensitive. That's really not necessary; the "security-sensitive" status is reserved for bugs that related to Mozilla security vulnerabilities, and having that status prevents the general public from viewing the bug, which is contrary to the CA request policy we're creating. If you can uncheck the "security-sensitive" checkbox please do so; otherwise I'll find someone else to do it. (I should be able to do it, but I need to have my bugzilla account privileges fixed.)
Reporter | ||
Comment 3•20 years ago
|
||
(In reply to comment #2) > I just noticed that when you submitted this bug you marked it as > security-sensitive. That's really not necessary; the "security-sensitive" status > is reserved for bugs that related to Mozilla security vulnerabilities, and > having that status prevents the general public from viewing the bug, which is > contrary to the CA request policy we're creating. If you can uncheck the > "security-sensitive" checkbox please do so; otherwise I'll find someone else to > do it. (I should be able to do it, but I need to have my bugzilla account > privileges fixed.) I am unable to uncheck the security sensitive bug (it is disabled for me). I apologize for checking that in the first place, I guess I didn't understand what it really ment :)
Assignee | ||
Comment 4•20 years ago
|
||
(In reply to comment #3) > I am unable to uncheck the security sensitive bug (it is disabled for me). I > apologize for checking that in the first place, I guess I didn't understand > what it really ment :) No problem; I should have noted in my instructions not to check it. In any case I should now have privileges to turn it off, which I'm doing; the bug should now be viewable by anyone.
Group: security
Reporter | ||
Comment 5•20 years ago
|
||
Is there anything else you need from us? It has been several months with no communication. Could somebody please shed some light on this issue. Thank you
Assignee | ||
Comment 6•20 years ago
|
||
My apologies. For some reason I hadn't listed USERTrust in my list of CAs at http://www.hecker.org/mozilla/ca-certificate-list and (partly for that reason) had lost track of it. I have now updated the page with the information provided. As to acting on USERTrust's request: Originally our interim policy was to accept only WebTrust-audited CAs; that's why I didn't do anything with this request back when it was originally submitted. Now I'm also looking at CAs that claim to have undergone "WebTrust-equivalent" audits, so I'm willing to reconsider this request. To start with, I need more detail on the claimed audits. I'm presuming that "SISAC" refers to the program described at <http://www.sisac.org>? Do you have a published audit report relating to this? I'm also presuming that "CS2" refers to Common Criteria evaluation according to the Commercial Security 2 protection profile? Or are you referring to something else? If Common Criteria, I have to double-check this but CC validation is normally something that applies to the software being used, and only to that software. We are also interested in audits relating to your CA practices and processes. (Maybe SISAC does this?) If you also approached Microsoft about getting your certs included into Windows and IE, it would be useful to have documentation similar to what you provided them in support of your "WebTrust-equivalent" claim.
Assignee | ||
Comment 7•20 years ago
|
||
I'm approving the USERTrust UTN certificates for approval based on the acquisition of the UTN roots by Comodo and the CAs' operations coming under the scope of the Comodo WebTrust audit. (There's no public link I can reference right now re UTN and Comodo, e.g., a press release, but I've confirmed all this with representatives of both Comodo and USERTrust via email and phone.) I've verified the following SHA-1 fingerprints on the UTN certs in a phone conversation with a Comodo representative: UTN USERFirst Client Email and Authentication: http://www.usertrust.com/cacerts/UTN-USERFirst-ClientAuthenticationandEmail.crt B1 72 B1 A5 6D 95 F9 1F E5 02 87 E1 4D 37 EA 6A 44 63 76 8A UTN USERFirst Hardware: http://www.usertrust.com/cacerts/UTN-USERFirst-Hardware.crt 04 83 ED 33 99 AC 36 08 05 87 22 ED BC 5E 46 00 E3 BE F9 D7 UTN DATACorp SGC: http://www.usertrust.com/cacerts/UTN-DataCorpSGC.crt 58 11 9F 0E 12 82 87 EA 50 FD D9 87 45 6F 4F 78 DC FA D6 D4 UTN USERFirst Object: http://www.usertrust.com/cacerts/UTN-USERFirst-Object.crt E1 2D FB 4B 41 D7 D9 C3 2B 30 51 4B AC 1D 81 D8 38 5E 2D 46 I am double-checking this with Comodo, but I believe that trust bits should be set to "S/MIME" for the UTN USERFirst Client Email and Authentication CA and to "all" for the others. [Above was also sent to Nelson Bolyard via digitally-signed email.]
Assignee | ||
Comment 8•20 years ago
|
||
Filed bug 271585 to get the certs actually added, and marked that bug as blocking this bug.
No longer depends on: 271585
Reporter | ||
Comment 9•20 years ago
|
||
(In reply to comment #7) Please mark "UTN USERFirst Client Email and Authentication" certificate valid for SMIME and Client Authentication. The rest of the certs can be marked as "all". Thanks! Nathan Luke > I'm approving the USERTrust UTN certificates for approval based on the > acquisition of the UTN roots by Comodo and the CAs' operations coming under the > scope of the Comodo WebTrust audit. (There's no public link I can reference > right now re UTN and Comodo, e.g., a press release, but I've confirmed all this > with representatives of both Comodo and USERTrust via email and phone.) > I've verified the following SHA-1 fingerprints on the UTN certs in a phone > conversation with a Comodo representative: > UTN USERFirst Client Email and Authentication: > http://www.usertrust.com/cacerts/UTN-USERFirst- ClientAuthenticationandEmail.crt > B1 72 B1 A5 6D 95 F9 1F E5 02 87 E1 4D 37 EA 6A 44 63 76 8A > UTN USERFirst Hardware: > http://www.usertrust.com/cacerts/UTN-USERFirst-Hardware.crt > 04 83 ED 33 99 AC 36 08 05 87 22 ED BC 5E 46 00 E3 BE F9 D7 > UTN DATACorp SGC: > http://www.usertrust.com/cacerts/UTN-DataCorpSGC.crt > 58 11 9F 0E 12 82 87 EA 50 FD D9 87 45 6F 4F 78 DC FA D6 D4 > UTN USERFirst Object: > http://www.usertrust.com/cacerts/UTN-USERFirst-Object.crt > E1 2D FB 4B 41 D7 D9 C3 2B 30 51 4B AC 1D 81 D8 38 5E 2D 46 > I am double-checking this with Comodo, but I believe that trust bits should be > set to "S/MIME" for the UTN USERFirst Client Email and Authentication CA and to > "all" for the others. > [Above was also sent to Nelson Bolyard via digitally-signed email.]
Comment 10•20 years ago
|
||
Nathan, The UTN root CA certs have been added with the following trust settings. UTN-USERFirst-Client Authentication and Email: This certificate can identify mail users. (Note: what certs to trust for SSL client authentication is a server's decision, so our builtin root CA list for client apps is not concerned with this trust setting.) UTN-USERFirst-Hardware: This certificate can identify web sites. UTN - DATACorp SGC: This certificate can identify web sites. UTN-USERFirst-Object: This certificate can identify software makers. The trust settings for the last three root CAs are different from what you wanted in comment 9. Is this okay?
Comment 11•20 years ago
|
||
Wan-Teh, Please read the explanation of this situation in https://bugzilla.mozilla.org/show_bug.cgi?id=271585#c14 When a certificate contains a signed extension that says it is only good for a perticular purpose (e.g. SSL only), then IMO we should not mark it trusted for other purposes.
Assignee | ||
Comment 12•20 years ago
|
||
Right, and I already accepted Nelson's position on this.
Comment 13•20 years ago
|
||
Frank, in that case you can mark the bug fixed now.
Comment 15•18 years ago
|
||
This request was fulfilled in 2005.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
Product: mozilla.org → NSS
Updated•2 years ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•