Closed Bug 367670 Opened 18 years ago Closed 17 years ago

Add SecureTrust root certificates

Categories

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

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: Scott, Assigned: hecker)

Details

(Whiteboard: EV)

Attachments

(5 files)

Zip file of new roots
1.96 KB, application/octet-stream
Details
Zip file of test certificates
2.47 KB, application/octet-stream
Details
Audit report (PDF)
30.15 KB, application/pdf
Details
SecureTrust CA root certificate
1.53 KB, application/x-x509-ca-cert
Details
Secure Global CA root certificate
1.53 KB, application/x-x509-ca-cert
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: 

Please add the following roots to the mozilla root store.  Both roots are embedded in IE and are marked as Extended Validation ("EV") roots.

SecureTrust CA
SHA1 thumbprint: 87 82 c6 c3 04 35 3b cf d2 96 92 d2 59 3e 7d 44 d9 34 ff 11 
Secure Global CA
SHA1 thumbprint: 3a 44 73 5a e5 81 90 1f 24 86 61 46 1e 3b 9c c4 5f f5 3a 1b 

Contact information:
SecureTrust Corporation
Attn: Scott Harris
10000 Vista Verde
San Antonio, TX 78255 
210-249-4750

Please let me know what other information you require.

Best Regards,
Scott Harris
SecureTrust Corporation
XRamp Security Services, Inc.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Attached file Zip file of new roots — 
Scott Harris sent me these files for this RFE
Additional info from Scott Harris:

3. Company Web page address URL
http://www.SecureTrust.com/

4. List of new roots and their SHA1 thumbprint. 
SecureTrust CA
SHA1 thumbprint: 87 82 c6 c3 04 35 3b cf d2 96 92 d2 59 3e 7d 44 d9 34 ff 11
Secure Global CA
SHA1 thumbprint: 3a 44 73 5a e5 81 90 1f 24 86 61 46 1e 3b 9c c4 5f f5 3a 1b
(in attached zip file)

5. CPS (URL or attachment)
Scott wrote:

... as far as the CPS goes, due to the new EV processes we will be issuing certificates off the same root but under different certificate policies.  
I could attach a CPS, but it would only be for ONE of the policies that 
we will use when issuing certificates off that root.  We took the approach 
of no longer associating a root with a CPS, only associating end entity 
certs with policies that link to the CPS that the certificate was issued 
under. ... Rather than having a CPS for SecureTrust CA, we will have an 
OV policy, an EV policy, a Code Signing policy, an S/MIME policy and a 
DV (maybe) policy.

6. Audit results from a licensed auditor
(in attached zip file)

7. EV policy OID(s) and the SHA1 hash of the applicable root(s)
EV Policy OID: 2.16.840.1.114404.1.1.2.4.1
This OID will be used for EV certificates issued from EITHER/BOTH of the new roots submitted with this application (See #4 for SHA1 thumbprints).

8. List of EKUs for each new root. 
Both new roots submitted with this application are for "All Issuance Policies" or All Purposes.

9. One test certificate for every root.
The Test Certificates can be found live on the following links:
SecureTrust CA: https://stca.securetrust.com/
Secure Global CA: http://sgca.securetrust.com/
The test certificates can also be found in the attached zip file:
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Hi Scott,

here are a large number of outstanding CA requests, and it will take me some time to work through them. You can, should you wish, speed up the processing of your request by providing the following data in the following format, as a *plain text comment* in this bug. This will help me do whatever evaluation is necessary, and then will be part of a public record describing the Mozilla default root certificates.

Some of the information may already be present in, or calculable from, data in this bug or other Mozilla-maintained documents. However, having it all in one place in a standard plain format for each request will save me a great deal of time, and help me to make everyone happier quicker. :-)

CA Details
----------

CA Name:
Website:
One Paragraph Summary of CA, including the following:
 - General nature (e.g., commercial, government, academic/research, nonprofit)
 - Primary geographical area(s) served
 - Number and type of subordinate CAs
Audit Type (WebTrust, ETSI etc.):
Auditor:
Auditor Website:
Audit Document URL(s):
  
Certificate Details
-------------------
(To be completed once for each certificate)
  
Certificate Name:
Summary Paragraph, including the following:
 - End entity certificate issuance policy
Certificate URL (on CA website):
Version:
SHA1 Fingerprint:
MD5 Fingerprint:
Modulus Length (a.k.a. "key length"):
Valid From (YYYY-MM-DD):
Valid To (YYYY-MM-DD):
CRL URL:
OCSP URL:
Class (domain-validated, identity-validated or EV):
Certificate Policy URL:
CPS URL:
Requested Trust Indicators (email and/or SSL and/or code):

Thanks for your help in this matter. :-)

Gerv
Scott: It's been over a month. Are you able to provide the requested information?

Thanks,

Gerv
CA Name: SecureTrust Corporation
Website: http://www.SecureTrust.com/

One Paragraph Summary of CA, including the following:
We are a commercial CA serving customers worldwide.  At this time we do not have any subordinates off of either root.

Audit Type (WebTrust, ETSI etc.): WebTrust
Auditor: Boysen & Miller PLLC
Auditor Website: NA
Audit Document URL(s): https://cert.webtrust.org/SealFile?seal=359&file=pdf

Certificate Details
-------------------
(To be completed once for each certificate)

Certificate Name: SecureTrust CA
Summary Paragraph, including the following:
Root certificate utilized for issuing all certificate types
Version: V3
SHA1 Fingerprint: 87 82 c6 c3 04 35 3b cf d2 96 92 d2 59 3e 7d 44 d9 34 ff 11
MD5 Fingerprint: N/A
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2006-11-07
Valid To (YYYY-MM-DD): 2029-12-31
CRL URL: http://crl.securetrust.com/STCA.crl
OCSP URL: N/A
Class (domain-validated, identity-validated or EV): All, inc. EV
Certificate Policy URL: https://www.securetrust.com/legal/
CPS URL: https://www.securetrust.com/legal/
Requested Trust Indicators (email and/or SSL and/or code): Server Auth, Client Auth, S/MIME, CodeSigning, Timestamping

Certificate Name: Secure Global CA
Summary Paragraph, including the following:
Root certificate utilized for issuing all certificate types
Version: V3
SHA1 Fingerprint: 3a 44 73 5a e5 81 90 1f 24 86 61 46 1e 3b 9c c4 5f f5 3a 1b
MD5 Fingerprint: N/A
Modulus Length (a.k.a. "key length"): 2048
Valid From (YYYY-MM-DD): 2006-11-07
Valid To (YYYY-MM-DD): 2029-12-31
CRL URL: http://crl.securetrust.com/SGCA.crl
OCSP URL: N/A
Class (domain-validated, identity-validated or EV): All, incl. EV
Certificate Policy URL: https://www.securetrust.com/legal/
CPS URL: https://www.securetrust.com/legal/
Requested Trust Indicators (email and/or SSL and/or code): Server Auth, Client Auth, S/MIME, CodeSigning, Timestamping

Please let me know if you need anything else!
Thanks,
Scott
Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv
Assignee: hecker → gerv
- How can I verify that Boysen & Miller, PLLC actually exists and is a legal CPA? The only hit Google has for them is your audit document. :-) The AICPA does not have a membership list on their site.

- The audit documents relate to an "XRamp Corporation". How can I verify that this and SecureTrust Corporation are the same thing? :-)

- Please can you provide HTTP download URLs for each certificate, along with a (test?) website using an end entity certificate issued by each?

- Is there actually any difference between the two roots, in terms of types of certs issued or issuing conditions? (Just for my own interest.)

- Do you have a certificate hierarchy diagram?

Gerv

Scott: there are open questions in this bug; I'm waiting for a response from someone at SecureTrust.

Gerv

(In reply to comment #10)
> Scott: there are open questions in this bug; I'm waiting for a response from
> someone at SecureTrust.
> Gerv

(In reply to comment #9)
> - How can I verify that Boysen & Miller, PLLC actually exists and is a legal
> CPA? The only hit Google has for them is your audit document. :-) The AICPA
> does not have a membership list on their site.

I would think you would rather check to make sure that they are Licensed to perform WebTrust audits...  :)  To check if they exist and are legal you would need to check with the Texas Board of Accountancy, found here: http://www.tsbpa.state.tx.us/

Here is the results of a search of their database:
BOYSEN & MILLER, PLLC 	C04172 	02/19/1997 	09/31/2008 	  	SAN ANTONIO, TX 

> - The audit documents relate to an "XRamp Corporation". How can I verify that
> this and SecureTrust Corporation are the same thing? :-)

XRamp Security Services, Inc. and SecureTrust Corporation are distinct and separate entities, which is why they were both included in our audit results. In fact, we got two separate EV Readiness audit reports, one for each company.

> - Please can you provide HTTP download URLs for each certificate, along with a
> (test?) website using an end entity certificate issued by each?

https://stca.securetrust.com/
https://sgca.securetrust.com/


> - Is there actually any difference between the two roots, in terms of types of
> certs issued or issuing conditions? (Just for my own interest.)

Yes, but we can discuss the differences in a different forum - shoot me a private email if you are truly curious.

> - Do you have a certificate hierarchy diagram?

No - it would be completely flat at this point in any case.

> Gerv

Thanks Gerv,
Scott
Scott,

> XRamp Security Services, Inc. and SecureTrust Corporation are distinct and
> separate entities, which is why they were both included in our audit results.
> In fact, we got two separate EV Readiness audit reports, one for each 
> company.

However, only XRamp Security Services, Inc. has a WebTrust audit... - at least, that's the URL you've given me. Does SecureTrust Corporation have one?

> > - Please can you provide HTTP download URLs for each certificate, along 
> > with a
> > (test?) website using an end entity certificate issued by each?
> 
> https://stca.securetrust.com/
> https://sgca.securetrust.com/

Thanks for the test sites. Do you have an HTTP(S) download URL for the roots themselves?

Gerv


Hi Gerv,  

Actually, it may not matter at this point - all of our roots are owned by XRamp Security Services, Inc. including the SecureTrust CA and Secure Global CA.  

I do not have a http download URL for the roots, can you simply save the certificate to disk?  I can email them to you if you wish.

Cheers,
Scott
Scott: could you clarify exactly the legal relationship between XRamp
Security Services, Inc. and SecureTrust Corporation?

Is it your understanding of the WebTrust procedures and criteria that the WebTrust audit for XRamp covers SecureTrust? If so, why do the two have separate EV Readiness audits? If not, do you plan to get a WebTrust audit for SecureTrust?

Regarding the certificates, we like to put an HTTP download URL on our "pending certificates" page so that people can install the certificates even before we have approved them. Also, having them available from the domain of the CA makes it obvious that we are downloading the correct, approved certificates.

However, if you wish, you can attach them to this bug individually (not as a zip). Please use the "add attachment" link at the top of the page.

Thanks,

Gerv


    
    

    
  


  

    
    

    
  
OK, thanks.

I have gathered together all the information you have provided, and placed it
in the "pending" CA root certificate request list, which is here:
http://www.mozilla.org/projects/security/certs/pending/
(Note: may take an hour or two to update.)

Please confirm that the information for your CA is correct, and add a comment
to this bug to that effect. Once you have done that, your application will turn
"green" and be ready for consideration. (The question of how the audits work and how the companies relate has, in effect, been breached prematurely - it's really part of the next phase.)

If your CA or certificate does not have a summary paragraph, please feel free
to provide one. Note: these paragraphs are not supposed to be marketing
statements :-)

Gerv

    
    

    
  
Hi Gerv,

The information looks correct - please move the application to a green status for consideration.

Thanks!
Scott

    
    

    
  
Scott: thanks for this. I've started the evaluation, and here are my first round of questions:

- We really need some sort of public clarification of the exact relationship between XRamp, SecureTrust and AmbironTrustWave, and some confirmation from an appropriate authority that the WebTrust audit for XRamp covers these roots. How do you think we can best go about this?

- The CPSes listed in your entry in the pending list seem to cover only SSL signing. Do you have documentation covering email and code signing, or should I remove those types of certificate from your application?

- At what frequency do you issue CRL updates for end-entity certificates?

Thanks,

Gerv


    
    

    
  
Scott: Are you able to provide answers to these questions? This bug may be closed if no response is received...

Gerv


    
    

    
  
Gerv,

SecureTrust Corporation is a wholly owned subsidiary of TrustWave Holdings, Inc. dba AmbironTrustWave.  XRamp was merged with SecureTrust at the time of the acquisition.  Our WebTrust Auditor has been in contact with Bryan Walker and he assures us that we are still covered under WebTrust.  If you are in need of more validation, you may want to call Bryan Walker yourself.

Our Public CPS does not deal with Code Signing Certificates, most notably because we do not offer Code Signing certificates to the public.  We do have a CPS for S/MIME, it is available on our website in the email certificate section.  Most importantly, we WILL be issuing a new type of S/MIME certificate and we WILL be issuing code signing certificates soon, so it is important to include these extensions in Mozilla.  As a WebTrust certified CA we will have to put a code signing CP in place prior to issuing a code signing certificate or we risk our WebTrust certification.  All our roots are accepted by Microsoft for code signing and S/MIME.  I would think it would be acceptable to have those types of certificates approved by Mozilla, but not issued by the CA until a later date.

As far as the CRL goes, we update our CRL daily.

Thanks,
Scott

    
    

    
  
I'm afraid I'm on holiday for the next two weeks, so no more will happen here until after that. My apologies :-(

Gerv


    
    

    
  
Scott,

If you don't offer code signing certificates to the public, and the relevant CPS is not public, then we can't enable your roots for code signing. So you can either publish the CPS you are going to be using, or withdraw that part of the request for now, and put in a later request to modify the trust bits on the root. (That would be a rather simpler request than the addition of new roots.)

I can't seem to find the S/MIME CPS you refer to. It's not at https://www.securetrust.com/legal/ . Could you give me the URL?

I have sent an email to Bryan Walker just to confirm the WebTrust situation.

BTW, https://www.securetrust.com/resources/evfaq/ erroneously lists Apple as a member of the CAB Forum.

Gerv


    
    

    
  
Hi Gerv,

I have copied our S/MIME CPS into our legal directory and posted our Code Signing CPS there as well.  I hope this meets the requirement.  Thanks for your patience!  Please let me know if there is anything else I need to do.

https://www.securetrust.com/legal/

Thanks again,
Scott
Whiteboard: EV

    
    

    
  
Bryan Walker of CICA says in an email to me:

"Gervase

I have had some discussions with the auditor of Xramp and based on my understanding of the current situation the audit report is valid."

Scott: I have some questions about the S/MIME and Code Signing CPSes. III B) of both says:

"Other than as provided in Section III.B.3, SecureTrust does not verify the authority of the Subscriber to request a Certificate."

However, there is no section numbered III.B.3 in either CPS!

In the S/MIME CPS, III.B.2 says:

"S/MIME certificates issued under this CPS are validated as to the email address only."

However, it gives no information as to what validation is done or how. As you will know, our policy states that:

"for a certificate to be used for digitally signing and/or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf;"

Do you confirm this? If so, how? When you are updating your CPS to fix the above error, can these steps please be spelled out?

As for the Code Signing CPS, Section III.B.2 suggests that the CPS permits issuance of code signing certificates based on faxed documentation. Is this correct?

It also suggests that you validate only the Organisational Name. Is that also correct?

Gerv


    
    

    
  
Gerv/Frank,
New versions of both the code signing and S/MIME CPSs are at https://www.securetrust.com/legal/.  Changes to the practice statements are twofold: 
1) legal review necessitating minor edits in regards to language by one of our in-house attorneys (Ms. Annabel R. Lewis)  and myself.  Syntax/spelling errors corrected including III.B.3 error mentioned above.  
2) expansion of the verification and validation processes for both S/MIME & code signing CPSs .  Due to the higher assurance levels required for code signing certificates, internal SecureTrust processes for diligence match corresponding processes for EV organization and legal entity validation and verification.  In regards to the issuance of code signing certificates based on faxed documentation, Internal processes may _gather_ information from applicants based upon faxed documentation.  Validation and verification of accuracy of documentation is done separately for code signing.  Due to the high assurance level implicitly required for the issuance of a code signing certificate, as we do not want to issue to an "rogue" entity, validation processes are aligned much like the EV process - in regards to legal and organizational verification.

Thank you,
Andrew W. Gray
SecureTrust CA Architect


    
    

    
  
Reassigning all open CA certificate inclusion request bugs to Frank Hecker, who is currently running the root program.

Gerv
Assignee: gerv → hecker

    
    

    
  
I'm resolving this bug as INVALID, not because I'm rejecting the application, but because it is superseded by bug 409837 and bug 409838 (along with bug 409840 which refers to the separate XRamp CA operated by Trustwave. The most recent information can be found in the new bugs, and any follow-up comments should be directed there.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID

    
  
Product: mozilla.org → NSS

    
    

    
      
  
Product: NSS → CA Program

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: