848766 - Add OATI's Root CA Certificate to Mozilla's trusted root list

Status: RESOLVED WONTFIX

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

Description

[Corey Rasmussen]

Please include the OATI webCARES CA certificate in Mozilla's trusted root list.

SSL Validation Type: Domain Validated (DV) Certificates.

Requested Trust Bits:
Websites (SSL/TLS) Yes
Email (S/MIME) Yes


SHA1 Fingerprint:
‎4b 6b d2 d3 88 4e 46 c8 0c e2 b9 62 bc 59 8c d9 d5 d8 40 13

Valid From: 2008-06-03
Valid To: 2038-06-03

Certificate Signature Algorithm: sha1RSA

Signing key parameters: RSA (4096 Bits)


Subject:
CN = OATI WebCARES Root CA
O = Open Access Technology International Inc
L = Minneapolis
S = MN
C = US

basicConstraints: CA: true

Key Usage: Non-Repudiation, Certificate Signing, Off-line CRL Signing, CRL Signing (46)

CRL Distribution Point:
URL=http://certs.oaticerts.com/repository/OATICA2.crl

I have attached the root certificate and it can also be downloaded from http://www.oaticerts.com/repository/OATICA2.crt.

Test Website URL (SSL): https://www.oaticerts.com/

CPS: http://www.oaticerts.com/repository/OATI-webCARES-CPS.pdf

Please email [e-mail] if you have any questions.

Thank you,

Patirck Tronnier
Principal Security Architect
Open Access Technology International, Inc.
3660 Technology Drive NE
Minneapolis, MN 55418
Phone: [phone]

Comment 1

[Corey Rasmussen]

Attachment: OATI Application for the Mozilla Root Certificate Program

We appreciate you reviewing our application and look forward to providing any additional information you may need.

Comment 2

[Corey Rasmussen]

Attachment: OATI Root Certificate

Attaching our Root Cert again as it doesn't appear to be attached from my initial bug submission.

Comment 3

[Corey Rasmussen]

Attachment: OATI Root Certificate Base64

OATI Root Certificate Base64 format

Comment 4

[Corey Rasmussen]

Attachment: Dump of OATI Root Certificate

Dump of OATI Root Certificate to view fields and extensions

Comment 6

[Kathleen Wilson]

I am accepting this bug, and will work on it as soon as possible, but I have a large backlog.
https://wiki.mozilla.org/CA:Schedule#Requests_in_the_Information_Gathering_and_Verification_Phase

I will update this bug when I begin the Information Verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 7

[Corey Rasmussen]

Kathleen, we are monitoring requests in the queue before us to make sure you have all the information you need. In the process we noticed a comment by you referring to "Effective 1 January 2013, the CA SHALL support an OCSP capability using the GET method for Certificates issued in accordance with these Requirements."

My understanding was it is common practice to implement CRL's or OCSP but not both. 

1. Is OCSP mandatory for us before you will add our Root Cert. to your root store? If not is there anything we need to provide to avoid this requirment?

2. If OCSP is required is required on the Root, Issuing or End Subscriber certs?

3. If OCSP is required on the Subscriber certs only we can add it but it will take two years for all certs to be renewed with the OCSP support. Is that OK?

I know you are swamped so I appreciate any guidance you can give me.

Comment 8

[Kathleen Wilson]

(In reply to Patrick Tronnier from comment #7)

For the SSL trust bit to be enabled, the CA hierarchy and operations will have to be in compliance with the CA/Browser Forum's Baseline Requirements.
https://www.cabforum.org/documents.html

> 1. Is OCSP mandatory for us before you will add our Root Cert. to your root
> store? 

Yes. See BR 13.2.2 and BR 13.2.5.

> If not is there anything we need to provide to avoid this requirment?

Not really... BR 13.2.1.

> 2. If OCSP is required is required on the Root, Issuing or End Subscriber
> certs?

See Appendix B of the Baseline Requirements document. Intermediate and end-entity certs must have OCSP URI in the AIA. Root cert does not.


> 3. If OCSP is required on the Subscriber certs only we can add it but it
> will take two years for all certs to be renewed with the OCSP support. Is
> that OK?


In general, the already-issued end-entity certs may be allowed to expire and then be renewed in compliance with the BRs. 

For example...
BR 9.1: "An Issuing CA SHALL populate the issuer field of each Certificate issued after the adoption of these Requirements in accordance with the following subsections."

Comment 9

[Kathleen Wilson]

If the OATI certs are only used for identity authentication, then I don't see why this root needs to be included in Mozilla products.

I've reviewed the CPS, and it appears that OATI only issues certificates to be used for identity authentication purposes. I do not see anything in the CPS about issuing certificates to customers to be used in their webservers for SSL/TLS. Then, the websites (SSL/TLS) trust bit does not need to be enabled for this root cert, so the Baseline Requirements (Comment #7 and Comment #8) do not apply.

Do the OATI certificates get used regularly for email (S/MIME)?

Comment 10

[Corey Rasmussen]

OATI issues certificates to be used for identity authentication purposes for S/MIME and within an SSL/TLS session for both Server Authentication and the optional Client Side Authentication. As described below the main scope of use is Client Authentication SSL/TLS certificates used to add additional authentication (beyond usernames and passwords) to web servers, browser clients, network devices, mobile users and devices, and Smart Grid users and devices.

The scope of OATI’s root certificate coverage can be broken down into three user communities; Wholesale Energy, Retail Energy/Smart Grid, and Amateur Sports. OATI sees massive growth in each of these user communities spurred by; 1) expansion from desktop to mobile devices/tablets, 2) explosion of Smart Grid standards and the resulting devices requiring client certificates, and 3) a critical mass of users frustrated with username/password limitations and thus whole industries switching to two factor authentication using client certificates.

Comment 11

[Corey Rasmussen]

Hi Kathleen, I sent an email which included the summary in Comment 10 and additional details. Now that you know that OATI certificates are used for TLS (Server and Client) and email (S/MIME) do you need anything else in order to proceed on our request? Thanks.

Comment 12

[Corey Rasmussen]

Hi Kathleen, do you need anything else from OATI in order to proceed with the approval of our application? Thanks.

Comment 13

[Kathleen Wilson]

Attachment: Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 14

[Corey Rasmussen]

Attachment: OATI's response to questions on OATI's Application for the Mozilla Root Certificate Program

Attached is OATI's response to questions on our original application. Please review and let us know if there is any additional information you need from OATI. Thank you. Patrick Tronnier, Principal Security Architect & Sr. Director of Quality Assurance

Comment 15

[Corey Rasmussen]

Hi Kathleen, per our emails on 2/27/14 and earlier(Subject: Re: [Bug 848766] Please Add OATI's Root CA Certificate to Mozilla's trusted root list) we would like to request the code signing trust bit be enabled. Thank you. Patrick Tronnier, Principal Security Architect & Sr. Director of Quality Assurance

Comment 16

[Kathleen Wilson]

The test website I have is: https://www.oaticerts.com/ 
The SSL cert does not have an OCSP URI in the AIA.

Please either update this site with a new SSL cert, or provide another site that is using an updated SSL cert that has the OCSP URI in the AIA.

Comment 17

[Kathleen Wilson]

Attachment: Updated CA Information Document

Please see the items highlighted in yellow in the attached document.

Comment 18

[Kathleen Wilson]

Attachment: Updated CA Information Document

Comment 19

[Corey Rasmussen]

Please use this as our test SSL site: https://svs.psem.oati.com. The SSL cert has an OCSP URI in the AIA.

Comment 20

[Kathleen Wilson]

Here's the current status of the Information Verification phase of this request:

Test Websites:
https://www.oaticerts.com/ --  The SSL cert does not have an OCSP URI in the AIA.
https://svs.psem.oati.com -- The connection to this website is not fully secure because it contains unencrypted elements.

Need current audit statement.

Need BR audit statement.

Questions about LRAs (see Comment #18)

If Code Signing trust bit is to be enabled, need further information (see Comment #18)

Comment 21

[Corey Rasmussen]

Kathleen, I am anxious to move this forward and offer my sincere apology for the delayed response to your requests/questions.

Test Websites: 

Confirmed https://www.oaticerts.com/ has an OCSP URI in the AIA for both SSL and Issuing CA certificates. Do not use previously submitted test site https://svs.psem.oati.com due to unencrypted elements (mixed content).
   [3]Authority Info Access
      Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
      Alternative Name:
          URL=http://ocsp.oaticerts.com/ocsp


Current Audit Statements: 

WebTrust: https://cert.webtrust.org/SealFile?seal=1802&file=pdf
CAB Forum BR's: Submitted as an attachment.

Questions about LRA's: 

1.  How does the webCARES System validate the request [by the LRA for a certificate]? Is there some software that automatically checks certain things? If yes, what exactly does the software check?  

A.  Via a secure web interface the PKCS10 certificate request fields (Distinguished Name) are prepopulated with previously vetted information for the LRA’s entity and thus only a Common Name and email address must be entered. When the PKCS10 Certificate Request is received validations are done by a custom policy module which include: validate the digital signature, confirm only supported algorithms were used, make sure all dates are valid and all extended certificate attributes (if present) are expected and correct. Before the request is submitted the webCARES application code also validates the Common Name and email address entered are appropriate for the entity submitting the request. 

Code Signing trust bit:

The Code Signing trust bit is not needed at this point and was not meant to be part of this application.


Please let us know if there is any additional details you need. 

With kind regards,
Patrick Tronnier

Comment 22

[Corey Rasmussen]

Attachment: CAB Forum Baseline Requirements Audit Report

Comment 23

[Corey Rasmussen]

Hi Kathleen, Is there anything else you need from OATI to complete the Information Verification phase of this request? Thank you. With kind regards, Patrick Tronnier, Principal Security Architect.

Comment 24

[Kathleen Wilson]

Attachment: 848766-CAInformation.pdf

I have entered the information for this request into Salesforce.

Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information (search for NEED in the pdf).

Comment 25

[Corey Rasmussen]

Hi Kathleen, my apologies, the webTrust Auditor we used, Schellman & Company, LLC, was formerly "BrightLine CPAs and Associates, Inc." and is listed on the following page:

"http://www.webtrust.org/licensed-webtrust-practitions-international/item64419.aspx#UnitedStates"

We will immediately address the "The Cache-Control max-age header outlives NextUpdate" issue. Thanks.

Comment 26

[Corey Rasmussen]

Hi Kathleen, we have addressed the "The Cache-Control max-age header outlives NextUpdate" issue and thus have addressed all of the "Need Response From CA" items listed in your attached document (848766-CAInformation.pdf). 

Please let us know if there anything else you need from OATI to complete the next phase of this request? Thank you. With kind regards, Patrick Tronnier, Principal Security Architect.

Comment 27

[Corey Rasmussen]

Attachment: CRL & OCSP report for www.oaticerts.com

"CRL & OCSP report for www.oaticerts.com" is attached to show the issue "The Cache-Control max-age header outlives NextUpdate" was properly addressed.

Comment 28

[Kathleen Wilson]

https://certificate.revocationcheck.com/www.oaticerts.com
is still showing errors when I try it:
http://ocsp.oaticerts.com/ocsp (GET)
- Certificate status is 'Server failed'
- OCSP service returned 'Malformed'
- ThisUpdate not set (RFC 5019, section 6.2)
- NextUpdate not set (RFC 5019, section 2.2.4)

Comment 29

[Corey Rasmussen]

Additional errors identified in previous comment (28) have been addressed. Please see attached "CRL & OCSP report for www.oaticerts.com" for confirmation.

Comment 30

[Corey Rasmussen]

Attachment: CRL & OCSP report for www.oaticerts.com.htm

Comment 31

[Kathleen Wilson]

Attachment: 848766-CAInformation-Complete.pdf

Comment 32

[Kathleen Wilson]

This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.

In the meantime, please add a comment to the bug when the new audit statements are available.

Comment 33

[Kathleen Wilson]

We recently added two additional tests that CAs must perform and resolve errors for...

Test 1) Browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link. All errors must be resolved/fixed. Warnings should also be either resolved or explained.

Output for Test1:
FATAL: ASN.1 Error in UserNotice 
 WARNING: Cowardly refusing to run CAB check due to previous errors 
 WARNING: Extension should be critical for KeyUsage 
 WARNING: Microsoft extension 1.3.6.1.4.1.311.20.2 treated as opaque extension 
 WARNING: Microsoft extension 1.3.6.1.4.1.311.21.1 treated as opaque extension 

Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test website and click on the 'Browse' button to provide the PEM file for the root certificate. Then click on 'run certlint'. All errors must be resolved/fixed. Warnings should also be either resolved or explained. 

Output for Test 2:
Using certificate chain from 'https://www.oaticerts.com/'
Using certificate from local file 'OATIWebCARESRootCA.cert'
Warning
    Microsoft extension 1.3.6.1.4.1.311.21.1 treated as opaque extension
    Cowardly refusing to run CAB check due to previous errors


~~

Please add a comment in this bug when the problems have been resolved, so that the CAB checks run and complete without error.

Comment 34

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #33)
> Test 2) Browse to http://cert-checker.allizom.org:3001/ and enter the test

Test 2 moved to https://cert-checker.allizom.org/

Comment 35

[Corey Rasmussen]

Here are the messages received when we run the first test (https://crt.sh/) and OATI’s responses. 


ERROR: CA certificates must set keyUsage extension as critical 
WARNING: Extension should be critical for KeyUsage 
WARNING: CA certificates should not have a validity period greater than 25 years

1.	OATI understands the importance of setting KeyUsage as critical and plans to implement this when we reissue our Root Certificate. 
2.	According to CABF BR’s and Mozilla’s “CA:TestErrors” (https://wiki.mozilla.org/CA:TestErrors) this requirement applies to all CA certs that are created after the first BR Effective Date of 01-Jul-2012. Our root certificate was issued on ‎‎June ‎03, ‎2008.
3.	99.9% of the certificates issued from our root are Client Authentication certificates (i.e. do not include the Server Authentication key usage).
4.	Our root conformed to both existing and expected Energy Industry standards at the time of issue.
5.	We have no third party subordinate CA’s and thus tightly constrain and control who our certificates are issued to.
6.	Other root certificates are included in the Mozilla Root Program which have validity periods greater than 25 years.


ERROR: Constraint failure in UserNotice: ASN.1 constraint check failed: BMPString: constraint failed (DisplayText.c:127) 

1.	This warning refers to our “Certificate Policy” extension (see below).
2.	OATI believes this error to be caused by either special characters in our DisplayText text or its overall length (see below for our DisplayText).
3.	OATI plans to eliminate this error when we reissue our Root Certificate. 
4.	OATI has not been able to find any risk associated with this error.
5.	In 15 years of issuing certificates OATI has not experienced any problem with our Certificate Policy extension or it’s DisplayText.

[1]Certificate Policy:
     Policy Identifier=1.2.840.114278.11.1
     [1,1]Policy Qualifier Info:
          Policy Qualifier Id=User Notice
          Qualifier:
               Notice Text=For more information regarding OATI certificates and the OATI webCARES System, please see the OATI Certification Practice Statement (CPS) at the following location: http://www.oaticerts.com/repository.  If you have specific questions that cannot be answered by the OATI CPS or would like OATI webCARES product information, please e-mail your requests to OATI at the following address: [e-mail].


WARNING: Microsoft extension 1.3.6.1.4.1.311.20.2 treated as opaque extension 

1.	This warning refers to the Microsoft specific “Certificate Template Name” extension (see below).
2.	OATI agrees this extension is opaque in a sense that the TSL protocol does not directly interpret it.
3.	Although not directly defined by any RFC or other Internet standard this extension, and its associated OID, are well understood and commonly used in Microsoft PKI implementations (https://support.microsoft.com/en-us/help/287547/object-ids-associated-with-microsoft-cryptography).
4.	OATI plans to eliminate this extension when we reissue our Root Certificate.
5.	OATI has not been able to find any risk associated with this warning.
6.	In 15 years of issuing certificates OATI has not experienced any problem with this extension.

    1.3.6.1.4.1.311.20.2: Flags = 0, Length = 6
    Certificate Template Name (Certificate Type)
        CA


WARNING: Microsoft extension 1.3.6.1.4.1.311.21.1 treated as opaque extension

1.	This warning refers to the Microsoft specific “CA Version” extension (see below).
7.	OATI agrees this extension is opaque in a sense that the TSL protocol does not directly interpret it.
2.	Although not directly defined by any RFC or other Internet standard this extension, and its associated OID, are well understood and commonly used in Microsoft PKI implementations (https://support.microsoft.com/en-us/help/287547/object-ids-associated-with-microsoft-cryptography).
3.	OATI plans to eliminate this extension when we reissue our Root Certificate. 
4.	OATI has not been able to find any risk associated with this warning.
5.	In 15 years of issuing certificates OATI has not experienced any problem with this extension.

    1.3.6.1.4.1.311.21.1: Flags = 0, Length = 3
    CA Version
        V0.0


We have attempted to run the second test (https://cert-checker.allizom.org/) over the past few weeks and it always gives a "This page can't be displayed message".

This page can’t be displayed

•Make sure the web address https://cert-checker.allizom.org is correct.
•Look for the page with your search engine.
•Refresh the page in a few minutes.

Comment 36

[Ryan Sleevi]

(In reply to Patrick Tronnier from comment #35)
> ERROR: Constraint failure in UserNotice: ASN.1 constraint check failed:
> BMPString: constraint failed (DisplayText.c:127) 
> 
> 1.	This warning refers to our “Certificate Policy” extension (see below).
> 2.	OATI believes this error to be caused by either special characters in our
> DisplayText text or its overall length (see below for our DisplayText).
> 3.	OATI plans to eliminate this error when we reissue our Root Certificate. 
> 4.	OATI has not been able to find any risk associated with this error.
> 5.	In 15 years of issuing certificates OATI has not experienced any problem
> with our Certificate Policy extension or it’s DisplayText.

This is a violation of RFC 2459/3280/5280, which sets explicit length limits on this field.

UserNotice ::= SEQUENCE {
     noticeRef        NoticeReference OPTIONAL,
     explicitText     DisplayText OPTIONAL}

NoticeReference ::= SEQUENCE {
     organization     DisplayText,
     noticeNumbers    SEQUENCE OF INTEGER }

DisplayText ::= CHOICE {
     visibleString    VisibleString  (SIZE (1..200)),
     bmpString        BMPString      (SIZE (1..200)),
     utf8String       UTF8String     (SIZE (1..200)) }

The 'risk' is that a conforming client of RFC 5280 MAY reject such a certificate as non-compliant to the specified profile and/or reject such certificates during validation.

Comment 37

[Corey Rasmussen]

"The 'risk' is that a conforming client of RFC 5280 MAY reject such a certificate as non-compliant to the specified profile and/or reject such certificates during validation."

1. OATI appreciates the comment and agrees with the risk of our certificates being rejected by RFC 5280 conforming clients.
2. Our initial comment would be more accurate as "OATI has not been able to find any SECURITY risk associated with this error".
3. OATI plans to be compliant with RFC 5280 when we reissue our Root Certificate. 
4. In 15 years of issuing certificates OATI has not experienced any problem with of our certificates being rejected by conforming clients.

Comment 38

[Corey Rasmussen]

As required by the Mozilla's Trusted Root Program, OATI has completed its annual third party examination of the AICPA/CICA WebTrust Services Principles and Criteria for Certification Authorities Version 2.0 and AICPA/CPA Canada WebTrust for Certification Authorities – SSL Baseline Requirements Audit Criteria. 

The links to the WebTrust Seals can be found at the following URLs as well as on OATI’s website: https://cert.webtrust.org/ViewSeal?id=2200 and https://cert.webtrust.org/ViewSeal?id=2199.
 
Please let us know if you have any additional questions.

Comment 39

[Kathleen Wilson]

Patrick, Please perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ
In particular, note:
+ For the CAs currently in the queue for discussion, I would ask them to perform this BR Self Assessment before I would start their discussion.

Comment 40

[Corey Rasmussen]

Attachment: Mozilla CA's BR Self Assessment 0511 2017.pdf

BR Self Assessment completed

Comment 41

[Corey Rasmussen]

Hi Kathleen, OATI has performed the BR Self Assessment and attached it to this bug as attachment 8866959 [details]. 

We hope this satisfies the requirements for the Information Verification phase and eagerly look forward to our public discussion. 

We hope our extra efforts to include not only the CPS Section, but the relevant text from within each CPS section, makes the task of reviewing our BR Self Assessment easier for those providing public review. 

With kind regards, Patrick.

Comment 42

[Kathleen Wilson]

Aaron, please review the BR Self Assessment.

Comment 43

[Corey Rasmussen]

Hi Aaron, please let me know if there is any additional information OATI can provide to assist in your review of our BR Self Assessment. 

With kind regards, Patrick.

Comment 44

[Aaron Wu]

Hi Patrick,

I am verifying your root certificate and BR Self Assessment, there are several items need your clarify and update:

1. Test Websites
There are 3 test websites as Valid, Revoked and Expired which you provided in BR Self Assessment, Valid website is verified with success, but Revoked and Expired are not accessible 
 - Revoked website : Server not found
 - Expired website : Server not found

2. CA/Browser Forum Lint Test
There are 3 errors occurred  as following:

 - ERROR 1: CA certificates must set keyUsage extension as critical 
   - Meaning : The Baseline Requirements say that the keyUsage extension MUST be present and MUST be marked critical.
   - Recommended Solution : This requirement applies to all CA certs that are created after the first BR Effective Date of 01-Jul-2012. In general, CAs should not be requesting inclusion of CA certs created before that date.	
 - ERROR 2: Constraint failure in UserNotice: ASN.1 constraint check failed: BMPString: constraint failed (DisplayText.c:127) 
 - ERROR 3: Invalid display text length

Note : To do the CA/Browser Forum Lint Test, you can browse to https://crt.sh/ and enter the SHA-1 Fingerprint for the root certificate. Then click on the 'Search' button. Then click on the 'Run cablint' link and ‘Run x509Lint’. All errors must be resolved/fixed.

Please help to provide the correct test websites, and get the errors for lint test fixed test above.

Thank you so much!


Kind regards,
Aaron

Comment 45

[Corey Rasmussen]

Hi Aaron, thank you for taking the time to verify our root certificate and BR Self Assessment and our request forward.

1. The test websites have been fixed.
      https://revoked.oaticerts.com
      https://expired.oaticerts.com

2. The 3 errors from the CA/Browser Forum Lint Test cannot be fixed without reissuing our Root Certificate. If there is no way forward without reissuing our Root Certificate please let me know as circumstances prevent us from doing that within the next few years.

In Comment 35 and Comment 37 I attempted to address the errors by 1.) Promising to fix them when we reissue our Root Certificate, 2.) Giving explanations as to why the errors occurred and 3.) Addressing any risk related to the errors. I summarize those comments again for your review and consideration. 

 - ERROR 1: CA certificates must set keyUsage extension as critical 

1.	OATI plans to implement this when we reissue our Root Certificate. 
2.	According to CA/Browser Forum BR's, and your recommended solution, this requirement applies to all CA certs that are created after the first BR Effective Date of 01-Jul-2012. Our root certificate was issued on ‎‎June ‎03, ‎2008.
3.	99.9% of the certificates issued are Client Authentication certificates (i.e. do not include the Server Authentication key usage) and thus pose significantly less risk for relying parties.
4.	Non-critical keyUsage conformed to both existing and expected Energy Industry standards at the time of issue.
5.	We have no third party subordinate CA’s and thus tightly constrain and control who our certificates are issued to.
6.	It appears as other root certificates are included in the Mozilla Root Program which have keyUsage as non-critical.
7.      (New) Our single Issuing CA certificate enforces keyUsage as critical which enforces it on all subscriber certificates.


 - ERROR 2: Constraint failure in UserNotice: ASN.1 constraint check failed: BMPString: constraint failed (DisplayText.c:127) 
 - ERROR 3: Invalid display text length

1.      OATI agrees with the risk of our certificates being rejected by RFC 5280 conforming clients.
2.      OATI has not been able to find any SECURITY risk associated with this error.
3.      OATI plans to implement this when we reissue our Root Certificate. 
4.      In 15 years of issuing certificates OATI has not experienced any problem with of our certificates being rejected by conforming clients.

Comment 46

[Aaron Wu]

(In reply to Patrick Tronnier from comment #45)
> Hi Aaron, thank you for taking the time to verify our root certificate and
> BR Self Assessment and our request forward.
> 
> 1. The test websites have been fixed.
>       https://revoked.oaticerts.com
>       https://expired.oaticerts.com

Thanks for making these websites fixed! expired website has verified. However, revoked website should display security connection failure and show an error message as SEC_ERROR_REVOKED_CERTIFICATE. Could you double check revoked one? 
> 
> 2. The 3 errors from the CA/Browser Forum Lint Test cannot be fixed without
> reissuing our Root Certificate. If there is no way forward without reissuing
> our Root Certificate please let me know as circumstances prevent us from
> doing that within the next few years.
> 
> In Comment 35 and Comment 37 I attempted to address the errors by 1.)
> Promising to fix them when we reissue our Root Certificate, 2.) Giving
> explanations as to why the errors occurred and 3.) Addressing any risk
> related to the errors. I summarize those comments again for your review and
> consideration. 
> 
>  - ERROR 1: CA certificates must set keyUsage extension as critical 
> 
> 1.	OATI plans to implement this when we reissue our Root Certificate. 
> 2.	According to CA/Browser Forum BR's, and your recommended solution, this
> requirement applies to all CA certs that are created after the first BR
> Effective Date of 01-Jul-2012. Our root certificate was issued on ‎‎June
> ‎03, ‎2008.
> 3.	99.9% of the certificates issued are Client Authentication certificates
> (i.e. do not include the Server Authentication key usage) and thus pose
> significantly less risk for relying parties.
> 4.	Non-critical keyUsage conformed to both existing and expected Energy
> Industry standards at the time of issue.
> 5.	We have no third party subordinate CA’s and thus tightly constrain and
> control who our certificates are issued to.
> 6.	It appears as other root certificates are included in the Mozilla Root
> Program which have keyUsage as non-critical.
> 7.      (New) Our single Issuing CA certificate enforces keyUsage as
> critical which enforces it on all subscriber certificates.
> 
> 
>  - ERROR 2: Constraint failure in UserNotice: ASN.1 constraint check failed:
> BMPString: constraint failed (DisplayText.c:127) 
>  - ERROR 3: Invalid display text length
> 
> 1.      OATI agrees with the risk of our certificates being rejected by RFC
> 5280 conforming clients.
> 2.      OATI has not been able to find any SECURITY risk associated with
> this error.
> 3.      OATI plans to implement this when we reissue our Root Certificate. 
> 4.      In 15 years of issuing certificates OATI has not experienced any
> problem with of our certificates being rejected by conforming clients.

According to the error and your descriptions above, we suggest that you can generate a new root certificate which compliant with our requirements and BRs. That will speed up the process of your root inclusion request.

Thank you so much!

Kind regards,
Aaron

Comment 47

[Aaron Wu]

Hi Patrick,

We have considered the lint test errors and determined that these are not security concerns and we do not consider these to be show-stoppers. Therefore, since the root cert was issued before the BRs became effective we will proceed with the process, and ignore these errors.

Kind regards,
Aaron

Comment 48

[David E. Ross]

(In reply to Aaron Wu from comment #47)
> Hi Patrick,
> 
> We have considered the lint test errors and determined that these are not
> security concerns and we do not consider these to be show-stoppers.
> Therefore, since the root cert was issued before the BRs became effective we
> will proceed with the process, and ignore these errors.
> 
> Kind regards,
> Aaron

Is it appropriate to include a root certificate in NSS that is not in compliance with Section 2.3 of the "Mozilla Root Store Policy" Version 2.5 merely because the certificate was issued prior to the BRs becoming effective?  After all, this is a request to add a root that does not currently exist in NSS.  Yes, I know this request is now four years old; but so is comment #8, which cited the BRs.

Comment 49

[Aaron Wu]

Hi David,

I think it is a good point that we should continue to require new root certificate inclusion request to be for certificate that comply with RFC5280.

From https://wiki.mozilla.org/CA:TestErrors
"This requirement applies to all CA certs that are created after the first BR Effective Date of 01-Jul-2012. In general, CAs should not be requesting inclusion of CA certs created before that date. "

We've been considering the possibility of moving forward with this request to include the old root certificate because the problems noted do not seem to be security related, but as David and Ryan have pointed out, it is not a good idea to include root certificates that were created before the first BR Effective date that do not comply with RFC 5280.

The problems with the old root certificate are not within the Subject or the subjectPublicKeyInfo, so OATI should be able to safely issue a new self-signed certificate for inclusion in the Mozilla store that doesn't suffer from the RFC 5280 violations. Path building should be able to find both the old and the new root certificate -- so in the other root stores path building will find the old root certificate, but if OATI generates a new root certificate that is included in NSS, the path building using the NSS root store would find the new root certificate.

Another option that many CAs use is to have your root certificate cross-signed by an already-included root certificate, until your root certificate is directly included.

Thanks,
Aaron

Comment 50

[Corey Rasmussen]

Aaron, David, Kathleen, & All,

OATI strongly believes that Mozilla should accept the OATI webCARES root certificate when the non-compliance identified, addressed by OATI, and reviewed by Mozilla does not cause genuine security concerns and when the OATI webCARES certificate is otherwise consistent with the RFC 5280 and the CAB Forum Baseline Requirements. 

Policies are generally not applied retroactively unless absolutely necessary. In the past 15 years, OATI certificates have had no issues with being rejected by RFC 5280 conforming clients. Retroactive application is inappropriate where there is no adverse impact. The OATI webCARES root certificate has been thoroughly examined by Mozilla as posing no security concerns and is safe for inclusion into the Mozilla program. Therefore, OATI requests inclusion on this case-by-case exception rather than being required to comply with a retroactive requirement that corrects no significant issue. 
 
OATI strongly believes the webCARES root certificate should be allowed into the Mozilla root store based on the following additional reasons:  
 
1.  Nearly 99.9% of OATI certificates issued externally are for Client Authentication and do not include Server Authentication key usage. 
2.  Non-critical keyUsage conforms to both existing and expected mandatory energy industry standards, including the North American Energy Standards Board (NAESB) standards, and did at the time of issue.   
3.  OATI has no third-party subordinate CA’s and thus tightly constrains and controls to whom OATI webCARES certificates are issued. 
4.  OATI’s single Issuing CA certificate enforces keyUsage as critical which enforces keyUsage on all subscriber certificates it issues.  

OATI understands the complexity and ramifications of this decision and appreciates the time you give moving our request forward.

Comment 51

[Kathleen Wilson]

This has been discussed in the mozilla.dev.security.policy forum, and the decision is stated here:
https://github.com/mozilla/pkipolicy/issues/99
"For new inclusions, require all existing unexpired unrevoked certs in hierarchy to be BR compliant"
This will be officially added to Mozilla's Root Store Policy, but is in effect now.

It is up to the CA requesting inclusion to determine how they will meet the requirement -- it may be achieved by revoking all existing non-BR-compliant certs, or adding certain intermediate certs to OneCRL, or creating a new root cert (which may be cross-signed by the old root cert).

Please update this bug again when you have decided on and implemented the solution.

Comment 52

[Corey Rasmussen]

Hi Kathleen, is it acceptable to submit a new root now and then make the decision to cross-sign it by the old root later in the approval process or after the new root has been fully approved? Thanks, Patrick

Comment 53

[Kathleen Wilson]

(In reply to Patrick Tronnier from comment #52)
> Hi Kathleen, is it acceptable to submit a new root now and then make the
> decision to cross-sign it by the old root later in the approval process or
> after the new root has been fully approved? Thanks, Patrick

Yes. Just provide all the details here in this bug.

Comment 54

[Aaron Wu]

CA will provide more information of new root cert, make change on the status on whiteboard. Once information provided and verified, we will move on to next stage - public discussion.

Thanks,
Aaton

Comment 55

[Corey Rasmussen]

Hi Kathleen, due to the length of the review process I want to make sure I understand your response. 

I asked "is it acceptable to submit a new root now and then make the decision to cross-sign it by the old root later in the approval process or after the new root has been fully approved?". You said "Yes. Just provide all the details here in this bug.". 

Based on this we plan on submitting a new root cert which is identical to the existing root we supplied in this bug (except the Key Usage will be Critical and the Constraint failure in the UserNotice will be fixed).

Several factors, including the length of time for approval, Microsoft's review of the new root, and other business and industry considerations, may dictate the need to cross sign the new root with our existing root. If we cross sign the new root with the existing root do we then need to start the approval process over with the cross signed cert or does the cross signed cert take the place of the new root?

For example if the new root is approved and added to the Mozilla root store can it be replaced automatically by the cross signed cert or do we need to start the approval process over?

Thanks, Patrick

Comment 56

[Ryan Sleevi]

Patrick: It sounds like you're assuming a new, properly encoded root certificate also means generating a new root private key - is that correct?

If so, that's not what is being requested, at least, not for this specific case. Because the keys would be the same, there would also be no need to cross-sign, nor any need to apply to any other stores for updates. Comment #49 tried to make that clear, particularly for skilled PKI practitioners such as publicly trusted CAs, but it would be useful to know what is leading OATI to believe that there needs to be, for example, a review by Microsoft of a new root or a cross-signed cert.

Comment 57

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 58

[Corey Rasmussen]

Hi Kathleen & Ryan, Microsoft's Trusted Root Certificate program's current requirements prohibit reuse of private keys...

"Private Keys and subject names must be unique per root certificate; reuse of private keys or subject names in subsequent root certificates by the same CA may result in random certificate chaining issues. CAs must generate a new key and apply a new subject name when generating a new root certificate prior to distribution by Microsoft."

Our communications with Microsoft have not led to an exemption or change in this policy so our intention is to provide a new root cert (using a new key pair).

Once a conforming new root is submitted are we locked into the CABF requirements which exist at the time of submission or will we be required to submit a new root IF (and I doubt they will) CABF requirements are changed? 

Thanks, Patrick

Comment 59

[Wayne Thayer]

(In reply to Patrick Tronnier from comment #58)
> 
> Once a conforming new root is submitted are we locked into the CABF
> requirements which exist at the time of submission or will we be required to
> submit a new root IF (and I doubt they will) CABF requirements are changed? 
> 
You are not locked in and could be required to submit a new root. As you stated, it is unlikely that CABF requirements for roots will change without some reasonable transition period, but if they do, Mozilla could require roots to comply with the new policy before being included.

Comment 60

[Corey Rasmussen]

Attachment: Replacement Root Cert.

Attached is the replacement cert for the original root cert.

Comment 61

[Corey Rasmussen]

Kathleen, Wayne, Ryan, Devon, all,

I have attached our replacement root cert which addresses ALL of the outstanding issues including:

1. All the errors/warnings from Test1 and Test2 have been fixed. The new results from the replacement cert are below along with the previous results (Kathleen's comment #33).
2. The BR Self Assessment has been done per Kathleen's request in comment #39.
3. The replacement root cert is fully BR Compliant per the new Mozilla policy and Kathleen's comment #51.


Per Aaron (comment #54) I hope we have provided everything you need so you can move us to the next stage - public discussion.

Thanks in advance, Patrick

===========================================================================

New Test Results For Replacement 2018 Root (All are expected)

cablint      NOTICE   CA certificates without Digital Signature do not allow direct signing of OCSP responses
cablint      INFO     CA certificate identified
zlint        NOTICE   Root and Subordinate CA Certificates that wish to use their private key for signing OCSP responses will not be able to without their digital signature set


Previous Test Results For originally submitted Root cert

cablint      ERROR    CA certificates must set keyUsage extension as critical
cablint      ERROR    Constraint failure in UserNotice: ASN.1 constraint check failed: BMPString: constraint failed (DisplayText.c:127)
cablint      WARNING  CA certificates should not have a validity period greater than 25 years
cablint      WARNING  Extension should be critical for KeyUsage
cablint      WARNING  Microsoft extension 1.3.6.1.4.1.311.20.2 treated as opaque extension
cablint      WARNING  Microsoft extension 1.3.6.1.4.1.311.21.1 treated as opaque extension
cablint      NOTICE   CA certificates without Digital Signature do not allow direct signing of OCSP responses
cablint      INFO     CA certificate identified
x509lint     ERROR    Invalid display text length
x509lint     WARNING  explicitText is not using a UTF8String
x509lint     WARNING  Policy information has qualifier other than CPS URI
x509lint     WARNING  RSA public exponent not in range of 2^16+1 to 2^256-1
zlint        ERROR    Root CA certificates MUST have Key Usage Extension marked critical
zlint        WARNING  The keyUsage extension SHOULD be critical

Comment 62

[Corey Rasmussen]

Devon,

I have attached our replacement root cert which addresses ALL of the outstanding issues. I believe per comment #54 we have provided everything you need to move us to the next stage - public discussion.

Thanks in advance, Patrick Tronnier

Comment 63

[Kathleen Wilson]

Acknowledging receipt of the new root cert. I have a huge backlog of CA updates/requests to review, so this has been added to my list. I will update this bug when I continue information verification of this request as per step #2 of our process:
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

Comment 64

[Kathleen Wilson]

Attachment: 848766-CA-Information-Aug21-2018.pdf

Attached is the information that has been verified for this request. Within the document search for "NEED" to find where further information is needed from the CA.

In particular:

1) Both the WebTrust CA and the WebTrust BR Audit Statements fail to specify the SHA256 Fingerprints of the root and intermediate certs that were in scope of the audit. 

Please inform your auditor that all future audit statements must meet the requirements of section 3.1.4 of Mozilla's Root Store Policy.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Also make sure that your next audits include the new root certificate and its CA Hierarchy.

2) Mozilla requires there to be a revision table in the CPS.
Reference:
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Revision_Table

3) There is a Confidentiality statement at the top of the CPS, and additional text about the document being confidential. This is problematic, because Mozilla requires CAs to publicly post non-confidential CP/CPS documents.
Please remove all "CONFIDENTIAL" notices and text from the publicly-posted CPS.

4) Provide three test websites (valid, expired, revoked) whose SSL certs chain up to the new 'webCARES Root CA 2018' root.
Reference: Section 2.2 of the BRs.

Comment 65

[Corey Rasmussen]

Hi Kathleen, thank you for your continued review of our root cert. 

We again informed our auditor to specify the SHA256 Fingerprints of the root and intermediate certs that are in scope of our next audit. We also had informed them back when Microsoft asked us to do so.

We also updated our CPS to include a revision table and removed the Confidentially statement. https://www.oaticerts.com/repository/OATI-webCARES-CPS.pdf

Comment 66

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #64)
> 
> 4) Provide three test websites (valid, expired, revoked) whose SSL certs
> chain up to the new 'webCARES Root CA 2018' root.
> Reference: Section 2.2 of the BRs.

Here's the test websites I am aware of:
Test Website - Valid: https://www.oaticerts.com/
Test Website - Revoked: https://revoked.oaticerts.com 	 
Test Website - Expired: https://expired.oaticerts.com

As far as I can tell, the SSL certs for these websites do not chain up to the root that is the subject of this root inclusion request; i.e.
CN=webCARES Root CA 2018; OU=; O=Open Access Technology International Inc; C=US

In order to proceed, we need the 3 test websites whose SSL certs chain up to this root.

Comment 67

[Ben Wilson]

It appears that this problem is still present - as far as I can tell, it chains to "OATI WebCARES Root CA" and not "webCARES Root CA 2018" as expected. New, separate test websites ought to be set up.

Comment 68

[Ben Wilson]

I need a status update on OATI's efforts to make progress on the tasks required in order for me to move this inclusion request forward.

Comment 69

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Comment 70

[Ben Wilson]

I intend to close this on or about Friday, 13-Jan-2023.

Comment 71

[michelle.coon]

Hi Ben, Thank you for the update. This is fine to close out. We are preparing new material and will submit a new request once ready.