1407921 - Add ATHEX Root CA G2

Status: RESOLVED WONTFIX

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

Description

[Stamatis Vamvakeris]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Comment 1

[Stamatis Vamvakeris]

Attachment: ATHEX - Conformity Assessment Reports.zip

Comment 2

[Stamatis Vamvakeris]

Attachment: AthexRootCAG2.zip

Comment 3

[Stamatis Vamvakeris]

Dear Mrs Wilson & all,

We contact you from Athens Stock Exchange (ATHEX), as we interested to participate in Mozilla Root CA Certificate Program, with our Root CA “ATHEX Root CA G2” and according to Mozilla Root Store Policy (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) you have been appointed as the CA Certificate module owner in order to evaluate new CA requests. 

Since Mozilla manages its root program using the common CA Database (CCADB) and bounded by the Common CCADB Policy, we attach the relevant links and documents accordingly. More specifically :

•	Certificate Policy (CP) http://www.athexgroup.gr/web/guest/digital-certificates-pki-regulations
•	Certificate Practice Statement (CPS) http://www.athexgroup.gr/web/guest/digital-certificates-pki-regulations
•	Standard audit (ETSI)  (see ATHEX Conformity assessment Reports attached )
•	Baseline Requirements (BR) audit (if the certificate is capable of issuing TLS/SSL server certificates)  (see ATHEX Conformity assessment Reports attached)


Certificates and Certificate Revocation Lists are in: http://www.athexgroup.gr/digital-certificates-repository.
If you have any question, or if you need any additional information, please contact us.
We look forward to hearing from you at your earliest convenience.

Kind Regards

Comment 4

[Stamatis Vamvakeris]

Athens Stock Exchange is a major player in Greece's financial as well as public sector, providing a full range of certificates for use by individuals and companies. 
Our Digital signing, Web SSL certificates are already used in governmental and private sector companies as well as in Greek & international citizens. Soon we will be providing e-Seal and Timestamping services (already took Conformity Assessment report for timestamping services – see attached docs), as well.

We are also already listed in the national & European Trusted Lists of Trusted Service Providers ( see https://webgate.ec.europa.eu/tl-browser/#/tl/E )

Comment 5

[Stamatis Vamvakeris]

Please Find below correct Link concerning European Trusted Lists of Trusted Service Providers :

https://webgate.ec.europa.eu/tl-browser/#/tl/EL

Comment 6

[Stamatis Vamvakeris]

Please Find below Test Web Sites SSL EV : 


https://certdemo-valid.athexgroup.gr/
https://certdemo-Revoked.athexgroup.gr/
https://certdemo-Expired.athexgroup.gr/

Comment 7

[Kathleen Wilson]

A few questions...

1) Does ATHEX issue the majority of TLS/SSL certificates to organizations other than ATHEX?
(please explain)

2) What prevents ATHEX from being a subordinate CA of an already-included CA?
Could something be changed to enable that?
(please explain)

3) How is ATHEX as a CA related (or not) to the HARICA CA, which has the following included root certificates:

Hellenic Academic and Research Institutions ECC RootCA 2015	
SHA-256 Fingerprint: 44:B5:45:AA:8A:25:E6:5A:73:CA:15:DC:27:FC:36:D2:4C:1C:B9:95:3A:06:65:39:B1:15:82:DC:48:7B:48:33

Hellenic Academic and Research Institutions RootCA 2011
SHA-256 Fingerprint: BC:10:4F:15:A4:8B:E7:09:DC:A5:42:A7:E1:D4:B9:DF:6F:05:45:27:E8:02:EA:A9:2D:59:54:44:25:8A:FE:71

Hellenic Academic and Research Institutions RootCA 2015
SHA-256 Fingerprint: A0:40:92:9A:02:CE:53:B4:AC:F4:F2:FF:C6:98:1C:E4:49:6F:75:5E:6D:45:FE:0B:2A:69:2B:CD:52:52:3F:36

Comment 8

[Stamatis Vamvakeris]

(In reply to Kathleen Wilson from comment #7)
> A few questions...
> 
> 1) Does ATHEX issue the majority of TLS/SSL certificates to organizations
> other than ATHEX?

Yes this is part of our Corporate Business goals and Policy and of course this is why we proceeded to be certified for QWAC certificates according to eIDAS (910/2014) Regulation - see European Trusted List of TSPs for details https://webgate.ec.europa.eu/tl-browser/#/tl/EL

> (please explain)
> 
> 2) What prevents ATHEX from being a subordinate CA of an already-included CA?
> Could something be changed to enable that?
> (please explain)

Dear Kathleen, after your last e-mail regarding implementation of cross-signed root CA, we have investigated this possibility we 2-3 Root CAs that are already included in Mozilla RCP (between them was the solution of HARICA that is a Greek CA).

Unfortunately, finally we concluded that we can't proceed to implement such a solution (i.e. cross-signed with an already included Root CA), due to our strict Policy we have as organization (we are the Athens Stock Exchange the Operator of Greek Stock, Bonds & Derivatives markets) and especially on issues (on our products & services) concerning Trust & Confidentiality that we prohibited (from our Top Management) to have them outsourced.

So we have to continue following your procedure to register ATHEX Root CA G2 in Mozilla RCP according to your guidelines and methodology.

> 
> 3) How is ATHEX as a CA related (or not) to the HARICA CA, which has the
> following included root certificates:
> 

ATHEX is completely different organization from HARICA (Hellenic Academic & Research Institute CA) that is hosted by GUnet - Greek Universities net (more details you can get from Dimitris Zacharopoulos - technical responsible from HARICA cc'd in this Bug-id).

Athens Stock Exchange (ATHEX)is the Operator of the Greek Cash, Bonds & Derivatives market, a completely private Company, listed in the main Stock Market from 2001 (see www.athexgroup.gr for details)

ATHEX CA is a Qualified Certification Authority from 2002 according to PD 150/2001 now eIDAS compliant according to 910/2014 Regulation

> Hellenic Academic and Research Institutions ECC RootCA 2015	
> SHA-256 Fingerprint:
> 44:B5:45:AA:8A:25:E6:5A:73:CA:15:DC:27:FC:36:D2:4C:1C:B9:95:3A:06:65:39:B1:
> 15:82:DC:48:7B:48:33
> 
> Hellenic Academic and Research Institutions RootCA 2011
> SHA-256 Fingerprint:
> BC:10:4F:15:A4:8B:E7:09:DC:A5:42:A7:E1:D4:B9:DF:6F:05:45:27:E8:02:EA:A9:2D:
> 59:54:44:25:8A:FE:71
> 
> Hellenic Academic and Research Institutions RootCA 2015
> SHA-256 Fingerprint:
> A0:40:92:9A:02:CE:53:B4:AC:F4:F2:FF:C6:98:1C:E4:49:6F:75:5E:6D:45:FE:0B:2A:
> 69:2B:CD:52:52:3F:36

Comment 9

[Kathleen Wilson]

OK, then please provide all of the information listed here:
https://wiki.mozilla.org/CA/Information_Checklist

Comment 10

[Dimitris Zacharopoulos]

I confirm that currently HARICA has no business relationship with Athens Stock Exchange. We had a discussion about cross-signing but HARICA decided not to proceed.

Comment 11

[John Balafas]

It doesn't make any sense, but in fact we didn't proceed to implement cross-signed with Externally Operated Subordinate CA due to our strict Policy not to permit such services to be outsourced

Comment 12

[Stamatis Vamvakeris]

(In reply to Kathleen Wilson from comment #9)
> OK, then please provide all of the information listed here:
> https://wiki.mozilla.org/CA/Information_Checklist

Hi Kathleen ,

Please find attached the document with General and Technical information about ATHEX Root CA G2 according to
https://wiki.mozilla.org/CA/Information_Checklist.

Best Regards,

Comment 13

[Stamatis Vamvakeris]

Attachment: General & Technical information about the ATHEX

Hi Kathleen ,

Please find attached the document with General and Technical information about ATHEX Root CA G2 according to
https://wiki.mozilla.org/CA/Information_Checklist.

Best Regards,

Comment 14

[Aaron Wu]

Hi Stamatis,

Thanks to provide CA information as Comment#13.

Please also 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.

Thank you so much!


Kind Regards,
Aaron

Comment 15

[Firefox Bug Husbandry Bot]

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

Comment 16

[Stamatis Vamvakeris]

Attachment: BR_Self_Assessment

please find attached our BR Self Assesment

Comment 17

[Kathleen Wilson]

Attachment: AthexRootCAG2.cer

Comment 18

[Kathleen Wilson]

Attachment: AthexRootCA.cer

Comment 19

[Kathleen Wilson]

Attachment: 1407921-CA-Information-April12-2018.pdf

The attached document shows the information that has been verified, and what additional information the CA needs to provide -- search for "NEED".

Comment 20

[Ryan Sleevi]

To save time on public discussion, it would also be good to understand the relationship of this root to the current ATHEX root trusted by Microsoft, which appears to be operating under the same CP/CPS as this proposed root, but is actively misissuing.

https://crt.sh/?id=8563443 is the root
http://www.athexgroup.gr/web/guest/digital-certificates-pki-regulations is the disclosed CP/CPS links in CCADB for that current certificate

https://crt.sh/?id=331831678&opt=cablint is an example of misissuance

I also don't think Comment #8 sufficiently explains the answer to your question - since being a subordinate CA doesn't outsource operations. However, since a subordinate CA has all the functional capabilities of a root, but arguably less supervision, it's probably good that they're proceeding with a root inclusion request, unless/until such a time as cross-signatures for new intermediate organizations are prohibited unless they've gone through the same public review process that roots :)

Comment 21

[Stamatis Vamvakeris]

Attachment: 1407921-CA-Information.pdf

Dear kathleen,

Please find attached

1. The  CA - information document with our additional clarifications for the NEED response isuues.
2. Athex - Webtrust for CA Attestation Report. (Standard,BR Audit  )
3. Athex WebTrust EV SSL Attestation Report

Please note that the CP/CPS that we refer to is publicly available in : http://www.athexgroup.gr/documents/10180/681762/WebAuthCP-CPS_EN_1.1+Final/a0c9ce95-d8cf-4533-bf3d-1f433d44760e

Comment 22

[Stamatis Vamvakeris]

Attachment: Athex - WebTrust for CA Attestation Report 2018.pdf

Dear kathleen,

Please find attached


2. Athex - Webtrust for CA Attestation Report. (Standard,BR Audit  )

Comment 23

[Stamatis Vamvakeris]

Attachment: Athex WebTrust EV SSL Attestation Report_2018.pdf

Dear kathleen,

Please find attached


3. Athex WebTrust EV SSL Attestation Report

Comment 24

[Stamatis Vamvakeris]

Dear kathleen,

Please find attached

1. The  CA - information document with our additional clarifications for the NEED response isuues.
2. Athex - Webtrust for CA Attestation Report. (Standard,BR Audit  )
3. Athex WebTrust EV SSL Attestation Report

Please note that the CP/CPS that we refer to is publicly available in : http://www.athexgroup.gr/documents/10180/681762/WebAuthCP-CPS_EN_1.1+Final/a0c9ce95-d8cf-4533-bf3d-1f433d44760e

Comment 25

[Wayne Thayer]

Noting a few other potential issues with this request:
- The website authentication conformity assessment report date 14-August 2017 in the .zip archive attached to this bug lists "CA Root private key is online", categorizing it as a "Minor non-conformity"
- Time stamping certificate issued directly from the root: https://crt.sh/?id=253143304
- Apparent EV test certificates with fake/inconsistent Subject:serialNumber: https://crt.sh/?Identity=certdemo%25&iCAID=62434

Also, the audit report attached to comment #22 is not a BR report.

Comment 26

[Rob Stradling]

Two certs issued by ATHEX that each contain a malformed EKU OID:

https://crt.sh/?id=785610428&opt=cablint,x509lint,zlint
https://crt.sh/?id=783857635&opt=cablint,x509lint,zlint

Comment 27

[Stamatis Vamvakeris]

(In reply to Rob Stradling from comment #26)
> Two certs issued by ATHEX that each contain a malformed EKU OID:
> 
> https://crt.sh/?id=785610428&opt=cablint,x509lint,zlint
> https://crt.sh/?id=783857635&opt=cablint,x509lint,zlint

Dear Mr. Rob Stradling,
 
First of all thank you for your comment. Let us clarify why we suppose the malformed EKU OID came up in the certificate in concern. (actually it’s only one certificate in both cases,
https://crt.sh/?id=785610428&opt=cablint,x509lint,zlint
https://crt.sh/?id=783857635&opt=cablint,x509lint,zlint
as it can be verified by the  X509v3 Subject Key Identifier: 49:BA:DD:AC:B5:A9:64:35
                
In our attempt to implement the Certificate Transparency (CT) for the certificate and with our OCSP Mechanism  facing temporary Technical issues at the specific time(2018-09-14  10:29:38 UTC) of issuance the Precertificate the error took place.
After recovering from the temporary issue in our OCSP Mechanism   the error has been eliminated, as it can been seen in crt.sh cases: 
 
https://crt.sh/?id=774778619 
https://crt.sh/?id=804360841 
 
We are at your disposal for any further information you may request.

Comment 28

[Rob Stradling]

Stamatis, thanks for confirming that you've fixed this bug.

BTW, it was more than just 1 cert affected:
https://crt.sh/?cablint=1172&iCAID=62434&minNotBefore=2018-01-01

Comment 29

[Stamatis Vamvakeris]

(In reply to Rob Stradling from comment #28)
> Stamatis, thanks for confirming that you've fixed this bug.
> 
> BTW, it was more than just 1 cert affected:
> https://crt.sh/?cablint=1172&iCAID=62434&minNotBefore=2018-01-01

Dear Mr. Rob Stradling ,
 
Yes you are right , but have in mind that, unfortunately at that time we have tried multiple times issuing a certificate for     “CN=test-athex-sign.athexgroup.gr” for testing purposes. 
And as we can assume the different 34 error records come up from the different logs servers. 

And now as you can see the service operates. 

We are at your disposal for any further information you may request.

Comment 30

[Rob Stradling]

(In reply to Stamatis Vamvakeris from comment #29)
<snip>
> And as we can assume the different 34 error records come up from the
> different logs servers. 

It's 34 distinct certificates that all exhibit the same problem.

Comment 31

[Kathleen Wilson]

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#71-inclusions
"Before being included, CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements."

As noted so far in this bug:
1) The CA Root private key is online
2) No BR audit statement provided yet
3) Several cert mis-issuances

Also, I'm still not finding the root level CP/CPS documentation.

I will leave this bug open a bit longer, in case I'm missing something. But my inclination is that this CA should create a new root certificate that is BR-compliant from private key creation. And that the CA may request inclusion of the new root certificate (by filing a new Bugzilla Bug) after full CP/CPS documentation for that root and it's hierarchy is available, and after sufficient audits have taken place (as per the BRs and Mozilla's root store policy).

Comment 32

[John Balafas]

Dear Kathleen & all,

First of all thanks for your message !

Kathleen may I introduce you Panagiotis Papagiannakopoulos, who is Associate Partner from our Consultant E&Y.

Regarding the points you mentioned in your comment (#31), Panagiotis will take part in the e-discussion in order to conclude to a mutual agreed outcome and proceed with what we have to follow for the completion of ATHEX subscription in Mozilla RCP.

Also with respect to point 3, could you please clarify what exactly you mean with the phrase “Several cert mis-issuances”? The only input that that we have as an error from cr.sh tool is the message “CA certificates must set keyUsage extension as critical”. Is there anything else ? 

Regarding root level CP/CPS doc please visit the following url (although i think we have already sent you this documentation in the past)

https://www.athexgroup.gr/web/guest/digital-certificates-pki-regulations

Also plase find our WebTrust seal in the following link:

https://www.athexgroup.gr/digital-certificates


Best Regards
John

Comment 33

[Kathleen Wilson]

(In reply to John Balafas from comment #32)
> Dear Kathleen & all,
> 
> First of all thanks for your message !
> 
> Kathleen may I introduce you Panagiotis Papagiannakopoulos, who is Associate
> Partner from our Consultant E&Y.
> 
> Regarding the points you mentioned in your comment (#31), Panagiotis will
> take part in the e-discussion in order to conclude to a mutual agreed
> outcome and proceed with what we have to follow for the completion of ATHEX
> subscription in Mozilla RCP.

The main thing is that we need complete audit history, per
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Complete_Audit_History

Which includes BR audits as per the BR Requirements.

Please attach the missing audits to this bug.

> 
> Also with respect to point 3, could you please clarify what exactly you mean
> with the phrase “Several cert mis-issuances”? The only input that that we
> have as an error from cr.sh tool is the message “CA certificates must set
> keyUsage extension as critical”. Is there anything else ? 

Here's what I see regarding mis-issuances.

https://crt.sh/?caid=62434&opt=cablint,zlint,x509lint&minNotBefore=2016-03-14
Constraint failure - 34 certs -- Comments #27, #29
commonName in BR cert must be from SAN entries - 4 certs
BR certs must have subject alt name - 3 certs

How are SSL certs getting issued with no SAN?

Also reported in this bug:
https://crt.sh/?id=331831678&opt=cablint - ERROR: BR certificates must include certificatePolicies


> 
> Regarding root level CP/CPS doc please visit the following url (although i
> think we have already sent you this documentation in the past)
> 
> https://www.athexgroup.gr/web/guest/digital-certificates-pki-regulations

Of course, I have seen that website, but what I find there is CP and CPS documents based on the type of certs being issued, such as: 

Certificate Policy of Qualified Certificates "Smart-Sign (dual key) - Class 2" (version 1.2, 01/06/2017)
Certification Practice Statement of EU Qualified Certificates (version 1.2, 01/06/2017)
Certificate Policy/Certificate Practice Statement of EU Qualified certificates for website authentication and EV Certificates (version 1.1, 01/03/2018)

Where is the binding between the "ATHEX Root CA G2" root (and all of the subCAs in its hierarchy) and these CPS documents?

Where is the document describing things like protection of the root's private key and network security controls? (e.g. usually in section 6 of the root's CP/CPS)


> 
> Also plase find our WebTrust seal in the following link:
> 
> https://www.athexgroup.gr/digital-certificates

I have seen that WebTrust CA audit.

Where's the WebTrust BR audit?

Comment 34

[John Balafas]

>The main thing is that we need complete audit history, per >https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Complete_Audit_History Which includes BR audits as per the BR >Requirements. Please attach the missing audits to this bug.
 
As per Mozilla’s Root Store Policy, and specifically section 3. Documentation, Paragraph 3.1.2 Required Audits, we understand that the requirement is to provide Mozilla, a WebTrust for CAs attestation report along with the WebTrust for CAs – EV SSL, given that we issue EV certificates. As such, could you please elaborate on what the requirement of the BR audit is? 
 
 
>Here's what I see regarding mis-issuances. https://crt.sh/?caid=62434&opt=cablint,zlint,x509lint&minNotBefore=2016-03-14 >Constraint failure - 34 certs -- Comments #27, #29 commonName in BR cert must be from SAN entries - 4 certs BR certs must have >subject alt name - 3 certs How are SSL certs getting issued with no SAN? Also reported in this bug: https://crt.sh/??>id=331831678&opt=cablint - ERROR: BR certificates must include certificatePolicies 
 
Regarding the “Several cert mis-issuances” bugs, remediation actions have been engaged , and as can be seen below for each mis-issuance  bug an action took place i.e 
Concerning this bug https://crt.sh/?id=331831678&opt=cablint remediation actions took place and as can be seen in https://crt.sh/?id=884227990&opt=cablint,x509lint,zlint  all mis-issuance bugs treated. 

Consequently relevant remediations actions have already took place for the remaining mis issunace bugs and feedback will be sent by tomorrow.
 

>Of course, I have seen that website, but what I find there is CP and CPS documents based on the type of certs being issued, >such as: Certificate Policy of Qualified Certificates "Smart-Sign (dual key) - Class 2" (version 1.2, 01/06/2017) Certification >Practice Statement of EU Qualified Certificates (version 1.2, 01/06/2017) Certificate Policy/Certificate Practice Statement of >EU Qualified certificates for website authentication and EV Certificates (version 1.1, 01/03/2018) Where is the binding between >the "ATHEX Root CA G2" root (and all of the subCAs in its hierarchy) and these CPS documents? Where is the document describing >things like protection of the root's private key and network security controls? (e.g. usually in section 6 of the root's >CP/CPS) 

Following the WebTrust seal in http://www.athexgroup.gr/digital-certificates   in the Audit Report and Management’s Assertions link  the CA Identifying Information includes all the identification info regarding "ATHEX Root CA G2" root
 
In the public available CP/CPs that can be found here: http://www.athexgroup.gr/documents/10180/681762/WebAuthCP-CPS_EN_1.1+Final/a0c9ce95-d8cf-4533-bf3d-1f433d44760e in section 6.4.4 the Network Security controls as well as protection of the root private key have already been addressed.  
 
>I have seen that WebTrust CA audit. Where's the WebTrust BR audit?
 
Similarly to our first point could you please elaborate on what the requirement for the BR audit is? As per Mozilla’s Root Store Policy, and specifically section 3. Documentation, Paragraph 3.1.2 Required Audits, we understand that the requirement is to provide Mozilla, a WebTrust for CAs attestation report along with the WebTrust for CAs – EV SSL, given that we issue EV certificates. Both WebTrust Attestation reports have been already been provided.

Comment 35

[Kathleen Wilson]

(In reply to John Balafas from comment #34)
> As per Mozilla’s Root Store Policy, and specifically section 3.
> Documentation, Paragraph 3.1.2 Required Audits, we understand that the
> requirement is to provide Mozilla, a WebTrust for CAs attestation report
> along with the WebTrust for CAs – EV SSL, given that we issue EV
> certificates. As such, could you please elaborate on what the requirement of
> the BR audit is? 


https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#312-required-audits
"For the SSL trust bit, a CA and all subordinate CAs technically capable of issuing server certificates must have all of the following audits:
- WebTrust for CAs
- WebTrust for CAs - SSL Baseline with Network Security
- WebTrust for CAs - EV SSL (if issuing EV certificates)"

When I say BR audit, I am referring to the "WebTrust for CAs - SSL Baseline with Network Security" audit criteria, for example: http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf

Section 3.1.2 means that for roots with the SSL trust bit enabled, both the WebTrust for CAs and BR audits are required. If EV treatment is also requested, then the WebTrust EV audit is also required.

Comment 36

[Stamatis Vamvakeris]

Referring to Comment 34 and regarding :

>consequently relevant remediation actions have already took place for the remaining mis issunace bugs and feedback will be sent by tomorrow".

https://crt.sh/?id=887385564&opt=cablint,zlint,x509lint
https://crt.sh/?id=887341951&opt=cablint,x509lint,zlint

Comment 37

[John Balafas]

Dear Kathleen,

just to inform you also about the following: Given that the SSL service is new, we have acquired a point in time “WebTrust for CAs – EV SSL” attestation report. Taken into consideration that the point in time attestation reports cannot be provided as seals, we have not proceeded with obtaining a “WebTrust for CA - SSL BR w/ Network Security”, which is a prerequisite for issuing a seal on “WebTrust for CAs – EV SSL”. 

We are currently discussing with the auditor in order to obtain both those attestation reports in a short period of time from now on, to accommodate your request. 

Kind Regards,
John

Comment 38

[John Balafas]

Dear kathleen,

i'd like to give you an update from our previous status and where exactly we are.

More specifically, after having:

• analyzed the current status of our application
• considered your valuable feedback
• conducted an independent pre-assessment under the ETSI regime
• considered our auditors opinion

we evaluated our options and finally decided that the best course of actions is to:

1. Create a new root certificate and new intermediate certificates using strict specifications and procedures from the moment private key is created, so that we reassure all stakeholders that ATHEX is fully committed in delivering fully compliant CA services
2. Verify that the new hierarchy is fully compliant against all applicable requirements using updated tools (e.g. linters) and methods (checklists, manual inspections)
3. Review our CP/CPS documentation and practices (internal audit) and make all the necessary adjustments to ensure it is fully compliant with any new/updated requirements (BR, EV, MRSP, eIDAS Regulation and ETSI standards)
4. Conduct the necessary independent audits by a competent (accredited) CAB
5. Request inclusion of the new root certificate in the Mozilla Root Store by submitting the new Conformity Assessment Report (CAR)

The first two (2) bullets from the above steps have already taken place, with new the Root Key Ceremony being witnessed by our auditor.

Our plan is to complete no.3 in April and no.4 in May, so that we are able to submit the CAR in June 2019.

Having transparency in mind, we plan to keep you informed about the progress of this schedule.

Kind Regards
John

Comment 39

[Kathleen Wilson]

(In reply to John Balafas from comment #38)

i'd like to give you an update from our previous status and where exactly we are.

Hi John, Thank you for the update.

decided that the best course of actions is to:

1. Create a new root certificate ...

My recommendation is that we close this particular root inclusion request as "Request Withdrawn by CA", and then open a new request when you are ready.

Please note that our process has changed, and you will be able to enter the required information directly into a Root Inclusion Case in the CCADB, as described here:
https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case
(Be sure to follow step 9 to provide the information in a Bugzilla Bug when you are ready for me to review your Case.)

Comment 40

[John Balafas]

Hi Kathleen

thank you for your promptly response!

We agree to follow your new procedures and guidelines.

Please be so kind to review this Root Inclusion Case in the CCADB as an existing one with high priority, taking into account the total age of the case (beyond 2 years).

Best Regards
John

Comment 41

[Kathleen Wilson]

(In reply to John Balafas from comment #40)

Please be so kind to review this Root Inclusion Case in the CCADB as an existing one

The information for this request is here:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000242

John, Please do the following:

1. Find your root inclusion case in the CCADB
   https://ccadb.force.com/5001J00000YZUgf

2. Click on the "Add/Update Root Cases" button

3. Click on the "Add PEM Info" button and follow the instructions from there.

This will cause a new root cert record to be created, as well as a new root case for it.

Then update the case and root case as the information becomes available.
Be sure to add a comment to this Bugzilla Bug whenever you would like me to review the updated information.
Reference:
https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case

Comment 42

[Ben Wilson]

There are a number of actions that should have been done to update the inclusion request in the CCADB, and there has been a long period of inaction by the CA in this matter. So I intend to close this root inclusion case on or about 10-Sept-2020 unless Athex can "provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements." We currently lack any evidence that Athex has maintained a continuous series of audits.

Comment 43

[John Balafas]

(In reply to Ben Wilson from comment #42)

Hi Ben,

regarding your message, please refer to my e-mail reply to your's.

Thanks
BR,
John

Comment 44

[Ben Wilson]

CA indicates that we will see additional progress on this root inclusion request by/in November/December timeframe. Therefore, I will set an next update for December 1, 2020.

Comment 45

[Ben Wilson]

Status update is needed.

Comment 46

[John Balafas]

Hi Ben,

i just sent it through e-mail.

Thanks

BR,
John

Comment 47

[Ben Wilson]

Sent email requesting status on submission of new root certificates and associated documentation.

Comment 48

[Ben Wilson]

Closing this. The CA operator can reapply at some point in the future.