Open Bug 1435691 Opened 2 years ago Updated 1 month ago

Add "BYTE Root Certification Authority" root certificate to NSS

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: skollias, Assigned: kwilson)

Details

(Whiteboard: [ca-verifying] - KW Comment #9 2018-11-27 - Email trust bit only)

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180128191252
CA Owner Name: 
BYTE Computer S.A.

Organizational Type :
Private Company

Geographic Focus:
Greece, Cyprus, Easteran Europe

Services Provided:
1) Qualified Certificates for Electronic Signatures
2) Qualified Certificates for Electronic Seals
3) Qualified Electronic Time Stamps

Primary Market, Customer base:
1) Any Citizen capable of holding Qualified Signature Certificate or Qualified Seal Certificate
2) Greek Healthcare Sector

Impact to Mozilla Users:
Users using Thunderbird will be able to send and receive digital signed emails. The Intermediate CA's for issuing qualified certificates are:
1) BYTE General Qualified Sub-CA
- CPS: https://www.byte.gr/pki/repository/general/BYTE%20QC%20General%20CA%20CPS_1.004_en.pdf
- CP: https://www.byte.gr/pki/repository/general/BYTE%20QC%20General%20CA%20CP_1.004_en.pdf
- PDS: https://www.byte.gr/pki/repository/general/BYTE_GeneralPDS_1.001_en.pdf
- Certificate: https://www.byte.gr/pki/repository/general/BYTEGeneral.cer
- CRL: http://pki.byte.gr/crl/crl_general.crl
- OCSP: http://pki.byte.gr/ocsp

2) BYTE ePrescription Qualified Sub-CA
- CPS: https://www.byte.gr/pki/repository/ePrescription/BYTE%20QC%20ePrescription%20CA%20CPS_1.004_en.pdf
- CP: https://www.byte.gr/pki/repository/ePrescription/BYTE%20QC%20ePrescription%20CA%20CP_1.004_en.pdf
- PDS: https://www.byte.gr/pki/repository/ePrescription/BYTE_ePrescriptionPDS_1.001_en.pdf
- Certificate: https://www.byte.gr/pki/repository/ePrescription/BYTEePrescription.cer
- CRL: http://pki.byte.gr/crl/crl_ePrescription.crl
- OCSP: http://pki.byte.gr/ocsp

Recommended Practices:
I have reviewed Mozilla's lists of Required and Recommended Practises, and confirm that we follow those practices

Potentially Problematic Practices:
I have reviewed Mozilla's lists of Forbidden and Potentially Problematic Practices, and confirm that we do not do those practices

Company Website:
https://www.byte.gr

BYTE Root CA CPS:
https://www.byte.gr/pki/repository/root/BYTE%20Root_CPS_1.005_en.pdf

BYTE Root CA CP:
https://www.byte.gr/pki/repository/root/BYTE%20Root_CP_1.005_en.pdf

BYTE Root CA Certificate:
https://www.byte.gr/pki/repository/root/BYTERoot.cer

Byte Root CRL:
http://pki.byte.gr/crl/crl_root.crl

OCSP
http://pki.byte.gr/ocsp

Auditor Name: EZU

Auditor Website: http://ezu.cz

Auditor Qualifications: Accredited by national accreditation body (NAB): Czech Accreditation Institue

Standard Audit URL: Attached

Standard Audit Type: ETSI 319-411

Standard Audit Statement Date: Attached

Mozilla Trust Bits:
Email
We do not issue SSL Certificates of any kind

Email Address Verification Procedures:
3.2.3 of General CPS (https://www.byte.gr/pki/repository/general/BYTE%20QC%20General%20CA%20CPS_1.004_en.pdf)

Current CA Hierarchy:
1) BYTE Root Certification Authority 001 : Root of whole certificate hierarchy
    - BYTE ePrescription Certification Authority 001: Sub-CA issuing Qualified Certificates for Signing to Greek Healthcare Sector (Doctors, Pharmacists, etc.)
    - BYTE Services Certification Authority 001: Sub-CA issuing Certificates for Client Authentication to Greek Healthcare Sector (Doctors, Pharmacists, etc.)
    - Byte General Certification Authority 001: Sub-CA issuing Qualified Certificates for Signing
    - Byte General Services Certification Authority 001: Sub-CA issuing Certificates for Client Authentication
Attached file Conformity Assessment Report (obsolete) —
Acknowledging receipt of this root inclusion request. 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 begin information verification of this request as per step #2 of our process:
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-verifying] - Email trust bit only
I am concerned because I see confidentiality warnings in the CP and CPS documents, and in the conformity assessment report that was attached to this bug. (should that attachment be deleted?)

All of Mozilla's root inclusion process and root store maintenance is public-facing, and all of the information in this Bugzilla Bug is publicly available. Therefore, we cannot accept documents that are marked as Confidential.

References:

https://wiki.mozilla.org/CA/Application_Process#Process_Overview
"All information provided by the CA MUST be publicly available."

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#public-audit-information
Section 3.1.4: "The publicly-available documentation relating to each audit MUST contain at least the following clearly-labelled information: ..."
Section 3.3: "We rely on publicly disclosed documentation (e.g., in a Certificate Policy and Certification Practice Statement) to ascertain that our requirements are met. Therefore, the following MUST be true: ..."

~~

If you are able to resolve the confidentiality issue, there are a couple more things that will need to be resolved before continuing with this request:

1) Mozilla requires period-of-time audits. The attached audit appears to be a point-in-time audit.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#audit-parameters
"Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually. Successive audits MUST be contiguous (no gaps)."

2) It is not clear if the attached audit statement is according to one of the approved audit criteria.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#etsi
Whiteboard: [ca-verifying] - Email trust bit only → [ca-verifying] - KW Comment #5 2018-05-22 - Email trust bit only
Attachment #8948361 - Attachment is obsolete: true
Kathleen,

Indeed the Report is confidential and I deleted it.

We are a Trust Service Provider according to 910/2014 EU Regulation (https://webgate.ec.europa.eu/tl-browser/#/tl/EL/3). 

1)According to eIDAS Regulation, the audits are every 24 months with a surveillance audit every 12 months.
2)The report (the one I have deleted) stated exactly that the audit is according ETSI EN 319 411-2.

Should we mention the audit period in CPS as well?
Should we mention the ETSI EN 319 411-2 to our CPS as well?

Regarding the "... I see confidentiality warnings in the CP and CPS documents ...", I will try to find the confidentiality warnings. It doesn't make any sense to be have confidential things there as those documents are also in our web site.
(In reply to Spyros Kollias from comment #6)

> 1)According to eIDAS Regulation, the audits are every 24 months with a
> surveillance audit every 12 months.

That does not meet Mozilla's requirements. This request will not move forward in the inclusion process until we believe that the requirements of Mozilla's Root Store Policy are met.

Reference: 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#audit-parameters


> 2)The report (the one I have deleted) stated exactly that the audit is
> according ETSI EN 319 411-2.
> 
> Should we mention the audit period in CPS as well?
> Should we mention the ETSI EN 319 411-2 to our CPS as well?

It would be good for the CPS to clarify which audit criteria are used, and the frequency of audits.

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Audit_Criteria

> 
> Regarding the "... I see confidentiality warnings in the CP and CPS
> documents ...", I will try to find the confidentiality warnings. It doesn't
> make any sense to be have confidential things there as those documents are
> also in our web site.

https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS
(In reply to Kathleen Wilson from comment #7)
> (In reply to Spyros Kollias from comment #6)
> 
> > 1)According to eIDAS Regulation, the audits are every 24 months with a
> > surveillance audit every 12 months.
> 
> That does not meet Mozilla's requirements. This request will not move
> forward in the inclusion process until we believe that the requirements of
> Mozilla's Root Store Policy are met.
> 
> Reference: 
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> policy/#audit-parameters
> 
> 
> > 2)The report (the one I have deleted) stated exactly that the audit is
> > according ETSI EN 319 411-2.
> > 
> > Should we mention the audit period in CPS as well?
> > Should we mention the ETSI EN 319 411-2 to our CPS as well?
> 
> It would be good for the CPS to clarify which audit criteria are used, and
> the frequency of audits.
> 
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Audit_Criteria
> 
> > 
> > Regarding the "... I see confidentiality warnings in the CP and CPS
> > documents ...", I will try to find the confidentiality warnings. It doesn't
> > make any sense to be have confidential things there as those documents are
> > also in our web site.
> 
> https://wiki.mozilla.org/CA/
> Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS

Dear Kathleen,
We updated the CPS documents, in which is clarified the audit criteria as well as the frequency.
You can see them below:

https://www.byte.gr/pki/repository/root/BYTE%20Root_CPS_1.006_en.pdf
https://www.byte.gr/pki/repository/ePrescription/BYTE%20QC%20ePrescription%20CA%20CPS_1.005_en.pdf
https://www.byte.gr/pki/repository/general/BYTE%20QC%20General%20CA%20CPS_1.005_en.pdf

Best Regards,
Spyros
The following link shows the information that has been verified. Search for "NEED" to see where further clarification is needed.

https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000259

In particular, please:

1) Provide public-facing, non-confidential audit statements.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#3122-etsi
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Complete_Audit_History


2) Update the CPS corresponding to each subCA that can issue S/MIME certs to describe how it is verified that the email address is owned/controlled by the certificate subscriber. 
In the GC General CPS it says:
"We perform a challenge-response procedure for verifying email using a unique, unpredictable link connected with the applicant of the issuing certificate. The procedure is as follows:
1) A unique unpredictable link is created
2) The link is being sent to the email declared by the applicant
3) The applicant must click the link in 24-hours of generation"

But I did not find that information in the other three subCA CPS documents.


3) Provide instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, or any other matter related to certificates. Preference is an email address that the CA closely monitors
QA Contact: kwilson
Whiteboard: [ca-verifying] - KW Comment #5 2018-05-22 - Email trust bit only → [ca-verifying] - KW Comment #9 2018-11-27 - Email trust bit only
You need to log in before you can comment on or make changes to this bug.