242610 - Add USERTRUST Root certificates

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Nathan Luke]

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, 
[e-mail]




Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Frank Hecker]

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 :-)

Comment 2

[Frank Hecker]

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.)

Comment 3

[Nathan Luke]

(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 :)

Comment 4

[Frank Hecker]

(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.

Comment 5

[Nathan Luke]

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

Comment 6

[Frank Hecker]

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.

Comment 7

[Frank Hecker]

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 8

[Frank Hecker]

Filed bug 271585 to get the certs actually added, and marked that bug as
blocking this bug.

Comment 9

[Nathan Luke]

(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

[Wan-Teh Chang]

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

[Nelson Bolyard (seldom reads bugmail)]

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.  

Comment 12

[Frank Hecker]

Right, and I already accepted Nelson's position on this.

Comment 13

[Wan-Teh Chang]

Frank, in that case you can mark the bug fixed now.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

This is an enhancement request.

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

This request was fulfilled in 2005.