bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Request to add two additional IdenTrust root CA certificates

RESOLVED FIXED

Status

NSS
CA Certificate Root Program
P1
enhancement
RESOLVED FIXED
12 years ago
a year ago

People

(Reporter: Travis Cornaby, Assigned: gerv)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

Request to have 2 IdenTrust Root certificates added to the Mozilla root store.


Reproducible: Always
(Reporter)

Comment 1

12 years ago
Request to have 2 IdenTrust Root certificates added to the Mozilla root store
Assignee: nobody → hecker
Component: Software Update → CA Certificates
Product: Firefox → mozilla.org
QA Contact: software.update
Version: unspecified → other
Summary: CA Certificates → Request to add two IdenTrust root CA certificates

Comment 2

12 years ago
Digital Signature Trust (DST) is a subsidiary of IdenTrust, Inc.  Root certificates for DST are already in Mozilla (at least SeaMonkey).  Are there additional certificates for IdenTrust separate from DST certificates?  If so, they need to be identified.  
(Reporter)

Comment 3

12 years ago
This is a Root roll over for 2 of our existing certificates that will expire 11/2008.  

DST RootCA X1
will be replaced with
DST Root CA X3

And 

DST RootCA X2
will be replaced with
DST ACES CA X6

Please let me know if you need copies of these new roots.  Thanks much,
-Travis
Summary: Request to add two IdenTrust root CA certificates → Request to add two additional IdenTrust root CA certificates
(Reporter)

Comment 4

12 years ago
I forgot to add that DST RootCA X1 and DST RootCA X2 must remain in the current root store until they expire.  Thanks!
-Travis
I confirm that this is an enhancement request.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: ca-certificates
Priority: -- → P1
Travis: we are adding new roots under our CA certificate policy:
http://www.mozilla.org/projects/security/certs/policy/

Could you please provide the information in section 14 of that document?

Given that your organisation already has roots in Mozilla, we won't (at this time) be doing as extensive an amount of scrutiny as for a new entrant. But we do need the information listed in that section - as comments or attachments in this bug please.

Thanks,

Gerv
Travis: never mind; forget that last comment and see the below instead.

There 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. 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. However, having it all in one place in a standard 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):
(Reporter)

Comment 8

12 years ago
Created attachment 256074 [details]
IdenTrust Root submittal document

Thanks Gervase.  Let me know if you need additional information.
Travis: Are the certificates (and CRL for X3) available over HTTP? Firefox doesn't understand ldap:// :-)

Gerv

(Reporter)

Comment 10

12 years ago
(In reply to comment #9)
Gervase, you can find the HTTP based CRL and CA Certificate for X3 at:


for CRL:
http://crl.identrust.com/DSTROOTCAX3.crl

for CA certificate:
http://apps.identrust.com/roots/DSTROOTCAX3.cer

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/

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.

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

Comment 12

12 years ago
Gerv, All information looks correct.  Thanks much,
-Travis


(In reply to comment #11)
> 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/
> 
> 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.
> 
> 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 Travis,

I have begun this evaluation. As you may be aware, our CA certificate policy has some (fairly minimal) requirements on the amount of validation a CA must do of key fields in the cert before issuance (section 7). Obviously, bullet 3 of section 7 doesn't apply to you because you are not asking for the Code Signing bit. But I've looked through the four CP/CPS documents linked from our pending list <http://www.mozilla.org/projects/security/certs/pending/> and I can't see anywhere it states e.g. whether and how you verify someone owns an email address before issuing them a cert for it.

Could you point me at the relevant sections?

Thanks,

Gerv
Reassign all open CA bugs to me. Apologies for the bugspam.

Gerv
Assignee: hecker → gerv
(Reporter)

Comment 15

11 years ago
Hi Gerv, 
IdenTrust issues personal and business identity certificates under both the ACES and the TrustID policy documents.   The primary purpose of these certificates is to establish an identity credential that enables the subscriber to digitally sign documents and authenticate to secure websites (regardless of S/MIME functionality).  The IdenTrust certificate issuance process is based on confirming the physical existence of an organization, its address, the identity of the subscriber, and his/her relationship to the employer, whereas the e-mail address of an individual is of a secondary concern and it is used in correspondence that would flag if a person really did not own that e-mail address or if the e-mail address was invalid.   

TrustID and ACES business certificates are issued only to representatives of organizations that have been vetted through the establishment of the organization’s parent account.  In those cases, the organization controls the domain and the e-mail addresses associated with it, and again e-mail correspondence would flag if a person really owns that e-mail address or if the e-mail address was invalid.    

For TrustID personal and ACES individual certificates, identity is established through out-of-bands means linked to the person’s identity and physical location.  IdenTrust has established in its risk analysis that verification of these identity components is a stronger mitigant to fraudsters than just establishing the person’s e-mail address.  For example, anyone can get a GMail, Yahoo or MSN e-mail account.  Moreover, the potential for spoofing and fraud are less because messages are routed via e-mail protocols like SMTP.  (As you know, certificates with e-mail addresses in them may be used by S/MIME-compliant programs like Thunderbird to send e-mail that is digitally signed, or to decrypt e-mail that has been encrypted with the public key.  In the former case, the sender’s e-mail address could be spoofed.  However, S/MIME agents should confirm that the address in the “From” header in an e-mail matches the e-mail address in the certificate and display that address, not just the friendly name, and the signature icon should link to a certificate viewer.  Digitally-signed e-mails should not work unless the two match.  In the latter case, a spoofed encrypted e-mail would be sent to the intended destination address--one would need to resort to hacking, DNS poisoning or other means to intercept the e-mail for decryption with the spoofer’s private key.)  

IdenTrust has assessed the risk of not specifically relying on verifying e-mail addresses prior to certificate issuance and has also found that the risk is sufficiently mitigated by the e-mail correspondence that it sends to the subscriber’s e-mail address during certificate life-cycle events, such as the issuance process as previously stated.  During this process, an e-mail is sent to the e-mail address provided, which includes a statement, “Please contact Customer Support with any questions by sending e-mail to helpdesk@identrust.com, or call 888-248-4447 (call direct at 801-326-5555).  Customer Support representatives are available to assist you Monday through Friday, 7 a.m. to 6 p.m. Mountain Time.”  If the person did not enroll for Certificate, he or she would be alerted to the fact and can report this to IdenTrust.  Also, other functions of the certificate holder’s account would not work without the correct e-mail address (e.g. password reset codes and renewal notifications are also sent to the e-mail address provided).

After eight years of operation, we are confident in the soundness and compliance with best practices of our identity-vetting and certificate issuance processes.  Other CAs may issue similar e-mail certificates that are validated only for a person’s e-mail address, and not for the identity of an actual, living person (e.g., CN=Mickey Mouse).   IdenTrust does not, and will not, issue e-mail only certificates.  Our certificate issuance mechanisms also include out-of-band communications, the interception of which would violate federal law, and IdenTrust has other mechanisms, which cannot be disclosed in a response such as this, or in public documents like the CPs and CPSs you have reviewed, which IdenTrust uses to vet identity prior to certificate issuance.  IdenTrust has procedures that are documented and audited by best-practices, PKI audits including the WebTrust for Certification Authorities and by regulators (Office of the Comptroller of Currency or OCC).  So, although IdenTrust does not publicly disclose such practices, some of them could be incorporated into our upcoming versions of RFC-3647-compliant CPSs if needed under the e-mail-vetting requirements of Mozilla’s CA Certificate Policy.  However, at present we believe that what we do to establish identity and include e-mail addresses in certificates would satisfy the Mozilla policy for enablement of the e-mail bit for both X3 and X6 roots in Mozilla software.  


(In reply to comment #13)
> Hi Travis,
> 
> I have begun this evaluation. As you may be aware, our CA certificate policy
> has some (fairly minimal) requirements on the amount of validation a CA must do
> of key fields in the cert before issuance (section 7). Obviously, bullet 3 of
> section 7 doesn't apply to you because you are not asking for the Code Signing
> bit. But I've looked through the four CP/CPS documents linked from our pending
> list <http://www.mozilla.org/projects/security/certs/pending/> and I can't see
> anywhere it states e.g. whether and how you verify someone owns an email
> address before issuing them a cert for it.
> 
> Could you point me at the relevant sections?
> 
> Thanks,
> 
> Gerv
> 

Travis,

Thanks for your detailed explanation of your procedures. 

As I understand it, you are applying for the "email trust bit" to be set for your certificates. This means that, regardless of the intended use of your certs, any certificate you issue can be used to send mail "as" the email address embedded in it, and Thunderbird will recognise it. Therefore I'm sure you will understand that it is vital that the possibility of issuing a cert to a person when they don't control the respective email address is minimised.

I'm trying to follow your argument. Are you saying that the email address for business identity certificates is confirmed because you first confirm that the business controls the domain, and then only put email addresses at that domain in the certificate, and issue the cert to individuals approved by and related to the business? If so, that might be acceptable for that class of certificates.

In terms of personal certificates, I am not saying that you should _just_ verify email address control, merely that it is a necessary step. I agree anyone can get a gmail account - but if a CA issues a certificate with that account name embedded in it, it needs to issue it only to the person controlling that account. This may not give you absolute identity, but it does give you relative identity (repeatability), and that's valuable for some applications.

I understand that email is sent during the certificate life cycle. I contend that email sent at any time other than certificate issuance is irrelevant - because the aim is to stop the bad guy getting the cert in the first place. I see you also send an email during issuance, but it's a "stop us if you object" email, not a "please authorise this" email - so if the person is on holiday, or the email gets spam-filtered, then the cert will be issued without the permission of the owner of the address. And if a fraudster was trying it on, I suspect they'd be sure to do it when the owner of the email address they were targetting was actually on holiday.

Of course, if the purpose of certificates issued by IdenTrust is for authenticating clients to servers, then perhaps you don't need the email trust bit?

Also, I apologise if this wasn't clear, but section 7 has three bullets. The third one (code signing) doesn't apply in this case, and we are discussing the email one, but I also need to know where in your CP/CPS you verify domain control before issuing a certificate for a website.

Thanks,

Gerv
(Reporter)

Comment 17

11 years ago
Gerv,

The following responses have been provided to me by our PKI policy counsel:

Gerv Markham wrote, "Are you saying that the email address for business identity certificates is confirmed because you first confirm that the business controls the domain, and then only put email addresses at that domain in the certificate, and issue the cert to individuals approved by and related to the business? If so, that might be acceptable for that class of certificates."  

IdenTrust: Yes, that is generally how we do it.

For personal/individual certificates, Gerv Markham wrote, "if the person is on holiday, or the email gets spam-filtered, then the cert will be issued without the permission of the owner of the address. And if a fraudster was trying it on, I suspect they'd be sure to do it when the owner of the email address they were targetting was actually on holiday."

IdenTrust:  We appreciate your concerns regarding the issuance of personal certificates containing e-mail address in the subject alt name, viz., that a certificate might be issued while a person was on holiday.  If fraud were to occur, law enforcement would be able to identify and arrest the individual because our certificates are identity certificates-through special proprietary databases and algorithms, we tie an individual's identity to his or her legal name and mailing address prior to approval of certificate issuance.  However, we are considering your comments and possible solutions that would address your concerns.  

Gerv Markham wrote, "I also need to know where in your CP/CPS you verify domain control before issuing a certificate for a website."

IdenTrust:  Section 2.4 of our TrustID CPS states, "TrustID server certificates require, as a minimum prerequisite to certificate issuance, the verification of the organization's name and address and, if applicable, registration of the designated domain name."  Sections 1.3.2.3.1, 3.1.1.4, 3.1.2.5 and 3.1.9.4 of both the ACES CPS and the ACES CP require that the subject CN for a server be the authenticated registered domain name of the server agency application.  IdenTrust has documented and auditable procedures to verify domain control, e.g., the authority of the person requesting the server certificate.  While not available to the public, we might be able to provide you with excerpts of these documents under a non-disclosure agreement.  However, in summary, the procedures are as follows:  (1) "WHOIS" is used to identify the domain registrant, (2) the registrant is contacted and asked whether the requester is authorized to obtain a certificate, (3) the employment of the requester is verified through the registrant’s HR department, (4) the requester is contacted by phone and asked to confirm the certificate request and provide details about the request that are known only to the requester, and (5) upon confirmation of the foregoing, an activation code is provided to the requester via out-of-band (postal mail or voice) communication. 

Thanks Gerv,
-Travis

(In reply to comment #16)
> Travis,
> 
> Thanks for your detailed explanation of your procedures. 
> 
> As I understand it, you are applying for the "email trust bit" to be set for
> your certificates. This means that, regardless of the intended use of your
> certs, any certificate you issue can be used to send mail "as" the email
> address embedded in it, and Thunderbird will recognise it. Therefore I'm sure
> you will understand that it is vital that the possibility of issuing a cert to
> a person when they don't control the respective email address is minimised.
> 
> I'm trying to follow your argument. Are you saying that the email address for
> business identity certificates is confirmed because you first confirm that the
> business controls the domain, and then only put email addresses at that domain
> in the certificate, and issue the cert to individuals approved by and related
> to the business? If so, that might be acceptable for that class of
> certificates.
> 
> In terms of personal certificates, I am not saying that you should _just_
> verify email address control, merely that it is a necessary step. I agree
> anyone can get a gmail account - but if a CA issues a certificate with that
> account name embedded in it, it needs to issue it only to the person
> controlling that account. This may not give you absolute identity, but it does
> give you relative identity (repeatability), and that's valuable for some
> applications.
> 
> I understand that email is sent during the certificate life cycle. I contend
> that email sent at any time other than certificate issuance is irrelevant -
> because the aim is to stop the bad guy getting the cert in the first place. I
> see you also send an email during issuance, but it's a "stop us if you object"
> email, not a "please authorise this" email - so if the person is on holiday, or
> the email gets spam-filtered, then the cert will be issued without the
> permission of the owner of the address. And if a fraudster was trying it on, I
> suspect they'd be sure to do it when the owner of the email address they were
> targetting was actually on holiday.
> 
> Of course, if the purpose of certificates issued by IdenTrust is for
> authenticating clients to servers, then perhaps you don't need the email trust
> bit?
> 
> Also, I apologise if this wasn't clear, but section 7 has three bullets. The
> third one (code signing) doesn't apply in this case, and we are discussing the
> email one, but I also need to know where in your CP/CPS you verify domain
> control before issuing a certificate for a website.
> 
> Thanks,
> 
> Gerv
> 

I spoke to an IdenTrust representative at the recent CA/Browser Forum meeting to clarify the situation. As I understand it, the ball is currently in their court. I await further comments from them in this bug.

Gerv
More questions:

- Do you have a certificate hierarchy diagram?

- Your X3 CRL currently seems to be issued at yearly intervals, and X6 at monthly! Any plans to make these a bit more timely?

Gerv
(Reporter)

Comment 20

11 years ago
Hi Gerv,
We have modified our offline DST Root CA X3 CRL lifetime to 30 days to match our DST ACES CA X6 CRL lifetime. 
All Sub CA's CRL's are issued with 24 hour lifetimes for DST Root CA X3, 
and 12 hour lifetimes for DST ACES CA X6.  I've sent a Hierarchy 
diagram directly to you, because I was unable to upload it to the bug report.  The digagram key is red representing offline trust anchors, yellow for Sub 
CA's, and blue for end entity certs.  Thanks much,
-Travis

(

In reply to comment #19)
> More questions:
> 
> - Do you have a certificate hierarchy diagram?
> 
> - Your X3 CRL currently seems to be issued at yearly intervals, and X6 at
> monthly! Any plans to make these a bit more timely?
> 
> Gerv
> 

OK great, thanks. Now all I'm looking for is a version of your CP/CPS which meets the requirements of section 7 of our policy with regard to email and SSL certificates (as discussed with Marty at the CABForum meeting).

Gerv

Comment 22

11 years ago
Gerv,
I think at this time that IdenTrust will forego trying to get the e-mail bit enabled, even though our individual certificates are true identity certificates--given the thorough identity vetting that we perform prior to issuance.  Section 7 of your Certificate Policy provides, "for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf."  We are unclear as to why this is still an open issue, given that we have always verified domain control, as we described in the documentation we have previously cited. Please clarify what is still left to remediate or clarify.  Otherwise, please acknowledge that we satisfy the requirements for SSL certificate issuance and we can consider this bug closed. Thanks.
Sincerely yours,
Ben  
(In reply to comment #22)
> I think at this time that IdenTrust will forego trying to get the e-mail bit
> enabled, even though our individual certificates are true identity
> certificates--given the thorough identity vetting that we perform prior to
> issuance.  

I have no quibbles with the level of your identity vetting; my point is a strictly limited one - you need to verify that the applicant controls the email address in question before issuing them a certificate for it.

Anyway, I have removed the email part of the request. So this is no longer an issue.

> Section 7 of your Certificate Policy provides, "for a certificate to
> be used for SSL-enabled servers, the CA takes reasonable measures to verify
> that the entity submitting the certificate signing request has registered the
> domain(s) referenced in the certificate or has been authorized by the domain
> registrant to act on the registrant's behalf."  We are unclear as to why this
> is still an open issue, given that we have always verified domain control, as
> we described in the documentation we have previously cited. 

The references given in comment #17 are not sufficient. For example, 3.1.1.4:

"Additionally, the distinguished name shall assert the registered fully qualified domain name of the server."

Well, of course it will. But that says nothing about whether you've bothered to check that the applicant actually owns the domain name they are applying for a certificate for.

On 17th May, Marty Osten emailed me a draft of a new CPS dated 20070514 (version 2.2) which had language in it which explicitly confirmed that domain control was verified by communicating with the WHOIS contact. I confirmed that the new language was acceptable, and said I looked forward to it being published. I think this CPS related to root X6, but I wasn't sure - I asked, but never got a reply. Regardless, a similar update for root X3 would be needed.

I have not heard anything since. From my point of view, I am still waiting for that draft CPS to be published - and probably for similar language to be added to the other one.

I can forward you copies of the relevant mails if required.

Gerv

Comment 24

11 years ago
Gerv,
Thank you for the clarification.  I thought we had pointed to that version of the CPS, now on our web site (URL below).  The TrustID CPS actually applies to X3 (which replaces X1, currently in Mozilla, for key rollover purposes), not X6.  Section 2.4 of our TrustID CPS located at
https://secure.identrust.com/certificates/policy/ts/identrust_trustid_cps_v2.2_20070514.pdf states, “TrustID server certificates require, as a minimum prerequisite to certificate issuance, the verification of the organization's name and address, registration of the designated domain name and control and authorization of the applicant over the domain. This is performed by contacting the domain registrant or administrator listed in WHOIS and verifying that the applicant for the certificate has authorization to administer the website.”  This should close the issue on X3.

However, X6 is operated for the U.S. federal government under the ACES CPS, which does not have this language, although we use the same procedures when issuing server certificates to federal agencies.  We appreciate your concern that our current ACES CPS will need to have a similar update to reflect the practices we use to issue server certificates under our root X3, and we have submitted a CPS to the Federal PKI Policy Authority containing such language.  However, the time frame for finalizing that CPS is dependent on approval processes of the General Services Administration and the Federal PKI Policy Authority. So, whatever language is in the CPS currently will have to suffice.  However, if Mozilla were to trust the Federal Bridge Root CA (available at ldap://fpkia.gsa.gov:389/ou = FBCA,o = U.S. Government,c=US), then our issue with getting X6 trusted by Mozilla might be considered resolved.
Thanks,
Ben Wilson

Comment 25

11 years ago
Gerv,
Thank you for the clarification.  I thought we had pointed to that version of the CPS, now on our web site (URL below).  The TrustID CPS actually applies to X3 (which replaces X1, currently in Mozilla, for key rollover purposes), not X6.  Section 2.4 of our TrustID CPS located at
https://secure.identrust.com/certificates/policy/ts/identrust_trustid_cps_v2.2_20070514.pdf states, “TrustID server certificates require, as a minimum prerequisite to certificate issuance, the verification of the organization's name and address, registration of the designated domain name and control and authorization of the applicant over the domain. This is performed by contacting the domain registrant or administrator listed in WHOIS and verifying that the applicant for the certificate has authorization to administer the website.”  This should close the issue on X3.

However, X6 is operated for the U.S. federal government under the ACES CPS, which does not have this language, although we use the same procedures when issuing server certificates to federal agencies.  We appreciate your concern that our current ACES CPS will need to have a similar update to reflect the practices we use to issue server certificates under our root X3, and we have submitted a CPS to the Federal PKI Policy Authority containing such language.  However, the time frame for finalizing that CPS is dependent on approval processes of the General Services Administration and the Federal PKI Policy Authority. So, whatever language is in the CPS currently will have to suffice.  However, if Mozilla were to trust the Federal Bridge Root CA (available at ldap://fpkia.gsa.gov:389/ou = FBCA,o = U.S. Government,c=US), then our issue with getting X6 trusted by Mozilla might be considered resolved.
Thanks,
Ben Wilson
I'm afraid I'm on holiday for the next two weeks, so no more will happen here until after that. My apologies :-(

Gerv

Comment 27

11 years ago
Thanks for the update.  When you get back could you put X3 as a high priority?  This needs to be implemented VERY soon because Root X1 is about to expire and beginning in November we will have to inform our users that Mozilla will no longer work for SSL/TLS encryption. Thanks.
I have evaluated this request, as per sections 1, 5 and 15 of the official CA policy at: http://www.mozilla.org/projects/security/certs/policy/ .

Here follows my assessment. If anyone sees any factual errors, please point them out.

Section 4 [Technical]. I'm not aware of any technical issues with certificates issued by IdenTrust, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. IdenTrust appears to provide a service relevant to Mozilla users: they are a commercial CA offering products to government, businesses and individuals. Policies are documented in the documents published on their website and listed in the entry on the pending applications list.

Section 7 [Validation]. IdenTrust appears to meet the minimum requirements for subscriber verification, as follows:

* Email: IdenTrust is not applying for permission to issue Email Certificates.

* SSL: For certificates with the TLS Web Server Authentication EKU (1.3.6.1.5.5.7.3.1), IdenTrust verifies domain control by communicating with the Administrative Contact listed in WHOIS. (See section 2.4 of DST CPS v2.2 for root X3 and section 3.1.2.5 of ACES CPS v4.1 for root X6. Note that additional assurances have also been given for root X6, and a CPS update is in progress.)

* Code: IdenTrust is not applying for permission to issue Code Signing Certificates.

Section 8-10 [Audit]. IdenTrust has successfully completed an audit using the WebTrust for CAs criteria. The auditors were Ernst & Young. The audit is valid until at least the end of June 2007, plus a WebTrust reauditing grace period.

Section 13 [Certificate Hierarchy]. IdenTrust has two intermediate CAs under the X3 root (1 email, 1 SSL) and four under the X6 root (3 email, 1 SSL).

Other: IdenTrust issues CRLs (on a 24 hour schedule for root X3 and a 12 hour schedule for root X6) and also has an OCSP responder.

I am therefore minded to approve the application. Before I do, I'm opening up a period of public discussion of this request. I'll post in the news://news.mozilla.org/mozilla.dev.tech.crypto newsgroup to allow people to make comments. The normal comment period, unless discussion continues beyond that time, is two weeks.

Gerv
Travis: is there an HTTP download URL for the X6 root?

And are you able to configure your webserver to serve the X3 and X6 certs with the correct MIME type (application/x-x509-ca-cert)? Currently, it uses text/plain.

Thanks,

Gerv
Gerv, the two roots are now attached to this bug in http downloadable form 
with the expected MIME content types.  I have confirmed that they have the
same SHA1 hash "fingerprints" as listed in 
http://www.mozilla.org/projects/security/certs/pending/#IdenTrust
I think this should suffice for testing purposes until the roots are in NSS.
No objections have been raised. Bug 394733 has been filed to track inclusion of these roots.

Gerv
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 34

3 years ago
Created attachment 8668177 [details]
IdenTrust-Audit-RootCertInfo2015.pdf

Received directly from auditor.

Updated

a year ago
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.