Closed Bug 543639 Opened 10 years ago Closed 8 years ago

Add AffirmTrust root certificates

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: khall, Assigned: kwilson)

References

Details

(Whiteboard: EV - Included in FF6.0, EV treatment in FF6.0)

Attachments

(15 files, 3 obsolete files)

848 bytes, application/x-x509-ca-cert
Details
848 bytes, application/x-x509-ca-cert
Details
1.32 KB, application/x-x509-ca-cert
Details
514 bytes, application/x-x509-ca-cert
Details
28.12 KB, application/pdf
Details
588.78 KB, application/pdf
Details
633.34 KB, application/pdf
Details
19.90 KB, application/pdf
Details
34.19 KB, application/pdf
Details
121.28 KB, application/pdf
Details
137.66 KB, application/pdf
Details
912.90 KB, application/pdf
Details
1.49 MB, application/pdf
Details
891.45 KB, application/pdf
Details
57.42 KB, image/png
Details
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB6.4; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: 

AffirmTrust is seeking to have the four new root certificates included in Mozilla’s trusted root store: AffirmTrust Commercial, AffirmTrust Networking, AffirmTrust Premium, and AffirmTrust ECC.

Reproducible: Always
Status: UNCONFIRMED → NEW
Ever confirmed: true
I will begin the Information Gathering and Verification phase when the CP/CPS and certs are provided.
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification
Status: NEW → ASSIGNED
Whiteboard: Information incomplete
Attached file AffirmTrust CPS v1.0 (1-23-2010) (obsolete) —
This is AffirmTrust's CPS, applicable to all four root certificates.  As stated at CPS Section VII.A, AffirmTrust does not support a Certificate Policy (CP).
The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.
We attach our WebTrust Audit Report by our auditors IS Partners, LLC, dated January 31, 2010.
We attach our EV WebTrust Audit Report by our auditors IS Partners, LLC, dated January 31, 2010.
Attached file AffirmTrust CPS v1.0 (2-22-10) (obsolete) —
We attach our revised CPS for all four roots dated 2-22-2010.
Attachment #425517 - Attachment is obsolete: true
Our website is at www.affirmtrust.com.  
We have a number of documents and other resources at http://www.affirmtrust.com/resources/  
We have set up test sites for each of the four roots as follows.  To use the test sites, import our four roots into Mozilla Firefox first.

AffirmTrust Commercial - https://commercial.affirmtrust.com/
AffirmTrust Networking - https://networking.affirmtrust.com:4431/
AffirmTrust Premium - https://premium.affirmtrust.com:4432/
AffirmTrust Premium ECC – https://premiumecc.affirmtrust.com:4433/
We have assigned the following EV OIDs as markers of Extended Validation authentication in our end-entity certificates, as listed in our CPS at pages 23-26.  Please note that we use a different EV OID for each root:

ROOT:
AffirmTrust Commercial – EV OID is 1.3.6.1.4.1.34697.2.1
AffirmTrust Networking - EV OID is 1.3.6.1.4.1.34697.2.2
AffirmTrust Premium - EV OID is 1.3.6.1.4.1.34697.2.3
AffirmTrust Premium ECC - EV OID is 1.3.6.1.4.1.34697.2.4
Here are the SHA certificate hashes for the four certificates:
AffirmTrust Commercial
f9 b5 b6 32 45 5f 9c be ec 57 5f 80 dc e9 6e 2c c7 b2 78 b7

AffirmTrust Networking
29 36 21 02 8b 20 ed 02 f5 66 c5 32 d1 d6 ed 90 9f 45 00 2f

AffirmTrust Premium
d8 a6 33 2c e0 03 6f b1 85 f6 63 4f 7d 6a 06 65 26 32 28 27

AffirmTrust Premium ECC
b8 23 6b 00 2f 1d 16 86 53 01 55 6c 11 a4 37 ca eb ff c3 bb
Our CRLs can all be viewed at our Resources page, http://www.affirmtrust.com/resources/.  You can also see the CDPs pointing to our CRLs inside the end-entity certs that are securing our test pages above.
AffirmTrust is in compliance with all Mozilla CA Recommended Practices as listed at https://wiki.mozilla.org/CA:Recommended_Practices.  See attached pdf.
AffirmTrust is in compliance with (i.e., is not engaging in) all Mozilla Potentially Problematic CA Practices as listed at https://wiki.mozilla.org/CA:Problematic_Practices.  See attached pdf.
I have received email from the auditor confirming the authenticity of the attached audit reports:
"We did indeed perform the audits you have inquired about. If you go to the Webtrust website, you will find us as an approved provider to perform WebTrust and SysTrust."
AffirmTrust’s test pages for our four root certificates can be viewed at:

AffirmTrust Commercial root: https://commercial.affirmtrust.com/
AffirmTrust Networking root: https://networking.affirmtrust.com:4431
AffirmTrust Premium root: https://premium.affirmtrust.com:4432/
AffirmTrust Premium ECC root: https://premiumecc.affirmtrust.com:4433/

To view the test pages, import the four roots from our public Resources page into Mozilla Firefox, then go to the URLs listed above.  

http://www.affirmtrust.com/resources/

The roots have not yet been marked for Extended Validation use by Mozilla, so you will only see the regular display for an SSL-secured page in the Firefox user interface, not the EV display.
This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about one week. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may sit in the discussion for
weeks. When there are not enough people contributing to the discussions ahead
of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion
Whiteboard: Information incomplete → EV - Information confirmed complete
This request is near the top of the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

As such, I am re-reviewing the information to ensure it is current.

I see that OCSP is now supported, as is required now for EV enablement.

Please post an update in this bug when there is a new version of the CPS which includes information about the OCSP support. Also, please provide information about the maximum time until OCSP responders updated to reflect end-entity revocation
http://www.cabforum.org/EV_Certificate_Guidelines_V11.pdf Section 26(b):
“If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.”


I am able to browse to three of the test websites within my Firefox browser with OCSP enforced.  

One of the websites, https://premiumecc.affirmtrust.com:4433/, 
results in the error code ssl_error_no_cypher_overlap.

Please see: https://wiki.mozilla.org/CA:Recommended_Practices#OCSP
and let me know when I should try to browse to the test website again.

Also, we have recently begun to ask CAs to perform the following testing in regards to EV, to ensure that OCSP works correctly up the chain.
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
Note: We don't currently postpone public discussion in regards to this particular testing item. It just needs to be done before I can create the PSM bug to do the actual EV enablement.
Attachment #428777 - Attachment is obsolete: true
We attach our revised CPS for all four roots dated 12-23-2010 (v1.1), which has been revised to reflect our support of OCSP.  See CPS Sections II.I and VI.C.  

Consistent with Mozilla recommendations and CA-Browser Forum EV Guidelines (v1.3) Section 11.1.1, AffirmTrust will provide revocation information for end-entity
EV Certificates via an OCSP service that is updated at least every four days, and OCSP responses from this service will have a maximum expiration time of ten days.

The test URLs for the four root certificates can be found at: 

Root 1 - AffirmTrust Commercial
https://commercial.affirmtrust.com/

Root 2 - AffirmTrust Networking
https://networking.affirmtrust.com:4431/

Root 3 - AffirmTrust Premium
https://premium.affirmtrust.com:4432/

Root 4 - AffirmTrust Premium ECC
https://premiumecc.affirmtrust.com:4433/
>> we have recently begun to ask CAs to perform the following testing in
>> regards to EV, to ensure that OCSP works correctly up the chain.
>> https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version

Email from Kirk: I'm pleased to report that our team completed the EV
Testing Easy Version, and all four of our roots (Commercial, Networking,
Premium, and Premium ECC) worked in the test environment, giving us the
green Mozilla UI indicating the test certificates from the four roots
all displayed as Extended Validation certs.
Attachment #429557 - Attachment is obsolete: true
I am now opening the first public discussion period for this request from AffirmTrust to add 4 root certificates and enable the Websites trust bit for all of them. The request is also to enable EV for all 4 roots. The root certificates under consideration are: AffirmTrust Commercial, AffirmTrust Networking, AffirmTrust Premium, and AffirmTrust Premium ECC.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “AffirmTrust Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of AffirmTrust must promptly respond directly in the discussion thread to all questions that are posted.
Whiteboard: EV - Information confirmed complete → EV - In Public Discussion
This request has been evaluated as per the Mozilla CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request from AffirmTrust to add 4 root certificates and enable the Websites trust bit for all of them. The request is also to enable EV for all 4 roots.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by AffirmTrust, 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]. AffirmTrust appears to provide a service relevant to Mozilla users: It is a new commercial CA based in the US which plans to offer certificates for web-based and mobile applications including microbanking, debit cards and smartcards, mobile phone applications, new media, cloud computing, social networking, etc.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main documents of interest are the CPS and Relying Party Agreement, which are in English. 

CPS: http://www.affirmtrust.com/repo/AffirmTrust_CPS_v1.1_12-23-2010.pdf
Relying Party Agreement: http://www.affirmtrust.com/repo/AffirmTrust_Relying_Party_Agreement_v1.1_12-23-2010.pdf

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

* SSL: According to section II.D of the CPS, for EV certificates AffirmTrust verifies the legal existence of the organization requesting the certificate, the identity and authorization of the certificate subscriber, and that the certificate subscriber has the exclusive right to use the domain name(s) to be listed in the certificate. 

** AffirmTrust does not currently issue non-EV certificates, but there is provision for this in the future as documented in Appendix A of the CPS. In Appendix A, section 3.2, AffirmTrust states that whenever an organization name is to be included in the certificate (e.g. for OV certs), AffirmTrust will verify the legal existence of the organization and the validity of the organization through a trusted third party data source. In Appendix A, section 3.3, AffirmTrust states that for OV SSL certificates, AffirmTrust will use a relevant domain name registrar to confirm that the certificate subscriber holds the domain name registration or is authorized to use the domain name to be included in the certificate. Appendix A, section 3.3, also states that for DV certificates AffirmTrust will use an email challenge-response mechanism to confirm that the certificate subscriber has control over the domain name (the details are provided in the CPS, and are in accordance with Version 2.0 of the Mozilla CA Certificate Policy).

* Email: Not Applicable. AffirmTrust is not requesting the Email trust bit at this time.

* Code: Not Applicable. AffirmTrust is not requesting the Code Signing trust bit at this time.

* EV Policy OIDs
** AffirmTrust Commercial: 1.3.6.1.4.1.34697.2.1 
** AffirmTrust Networking: 1.3.6.1.4.1.34697.2.2 
** AffirmTrust Premium: 1.3.6.1.4.1.34697.2.3 
** AffirmTrust Premium ECC: 1.3.6.1.4.1.34697.2.4

Section 13 [Certificate Hierarchy]. 
* The 4 new root certificates may be downloaded from here: http://www.affirmtrust.com/resources/
** AffirmTrust Commercial
** AffirmTrust Networking
** AffirmTrust Premium
** AffirmTrust Premium ECC

* Each root signs internally-operated sub-CAs which sign end-entity certificates. Currently each root has one subordinate CA, for issuing EV SSL certificates.  AffirmTrust initially plans to only issue EV SSL certificates, but may in the future create additional sub-CAs to issue DV SSL, OV SSL, email (S/MIME), and code signing certificates under different sub-CAs of each root.


Other: 
* AffirmTrust issues CRLs with NextUpdate 7 days for end-entity certs.
* OCSP is provided.
** CPS Section II.I: AffirmTrust shall provide revocation information for end-entity EV Certificates via an OCSP service that is updated at least every four days, and OCSP responses from this service will have a maximum expiration time of ten days.

Section 8-10 [Audit]. 
AffirmTrust is audited annually according to the WebTrust CA and WebTrust EV criteria. The 2010 audit statements were from IS Partners, LLC, which is part of Interactive Solutions, LLC (http://www.ispartnersllc.com, http://www.interactivesolutionsllc.com/). The audit reports were attached to the bug, and I exchanged email with a representative of Interactive Solutions to confirm the authenticity of the audit reports.
** WebTrust CA: https://bugzilla.mozilla.org/attachment.cgi?id=428774 
** WebTrust EV: https://bugzilla.mozilla.org/attachment.cgi?id=428776 

Based on this assessment I intend to approve this request from AffirmTrust to add 4 root certificates, turn on the Websites trust bit for all of them, and enable EV for all 4 roots.
Whiteboard: EV - In Public Discussion → EV - Pending Approval
To the representatives of AffirmTrust: Thank you for your cooperation and your
patience.

To all others who have commented on this bug or participated in the public
discussion: Thank you for volunteering your time to assist in reviewing this CA
request.

As per the summary in Comment #28, and on behalf of the Mozilla project I
approve this request from AffirmTrust to include the following root certificates
in Mozilla:

** AffirmTrust Commercial (websites), enable EV.

** AffirmTrust Networking (websites), enable EV.

** AffirmTrust Premium (websites), enable EV.

** AffirmTrust Premium ECC (websites), enable EV.

I will file the NSS and PSM bugs to effect the approved changes.
Whiteboard: EV - Pending Approval → EV - Approved - awaiting NSS and PSM
Depends on: 633546
Depends on: 633552
I have filed bug 633546 against NSS and bug 633552 against PSM for the actual changes.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Whiteboard: EV - Approved - awaiting NSS and PSM → EV - Included in FF6.0, EV treatment in FF6.0
On Monday, February 7, 2011 at 5:54:40 PM UTC, Kathleen Wilson wrote[1]:
> This concludes the public discussion about AffirmTrust's request to add 
> 4 root certificates, turn on the websites trust bit for them, and enable EV.
> 
> I will post my recommendation for approval of this request in the bug.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=543639
> 
> All follow-up on this request should be posted directly in the bug.

I have a follow-up question, and I am posting it here according to Kathleen's request above.

My question is: in the Authorities tab in the Certificate Manager of my Firefox instance, three of the four certificates covered by this bug are listed as Builtin Object Tokens:

* AffirmTrust Networking
* AffirmTrust Premium
* AffirmTrust Premium ECC

However, the fourth certificate covered by this bug is instead listed as a Software Security Device:

* AffirmTrust Commercial.

Is that intended? If so, why is this certificate treated differently to the other three?

Thanks.

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/W2G5HYrGdWY/w4ImxSFi09oJ
(In reply to Sam Pablo Kuper from comment #34)

Would you please attach a screen shot to this bug?

For me, all of the AffirmTrust roots show as Builtin Object Tokens.

However, the Affirm Trust root certs were cross-signed by SwissSign. So, you may have browsed to a website that served up the intermediate cert version of the 'AffirmTrust Commercial' certificate. But then I would expect that you would see the 'AffirmTrust Commercial' cert listed twice -- once as BuiltIn (for the root cert), and once as Software Security Device (for the intermediate cert signed by SwissSign).
(In reply to Kathleen Wilson from comment #35)
> Would you please attach a screen shot to this bug?

Done.

> For me, all of the AffirmTrust roots show as Builtin Object Tokens.

They don't for me, I'm afraid.

> However, the Affirm Trust root certs were cross-signed by SwissSign. So, you
> may have browsed to a website that served up the intermediate cert version
> of the 'AffirmTrust Commercial' certificate. But then I would expect that
> you would see the 'AffirmTrust Commercial' cert listed twice -- once as
> BuiltIn (for the root cert), and once as Software Security Device (for the
> intermediate cert signed by SwissSign).

Understood, but no, that's not what I'm experiencing.

This is using Firefox ESR 45.5.1, from the Debian Jessie 64-bit repository.
P.S. In case it is useful, here is an example of a website whose HTTPS certificate chain rests upon the AffirmTrust Commercial root certificate: https://www.cs.ox.ac.uk/isg/tools/RDFox/
This likely has the same root cause as bug 1322751, so any further discussion can happen here.
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.