Open Bug 1602415 Opened 1 year ago Updated 6 days ago

Add PostSignum Root QCA 4 to Root Store

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: vyvoj.postsignum, Assigned: bwilson)

References

()

Details

(Whiteboard: [ca-verifying] - BW 2020-08-27 - Comment #2)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Product: NSS
Component: CA Certificate Root Program
Severity: enhancement
Summary: CA PostSignum by Ceska posta, s.p. (Czech Post)
root certificate: http://www.postsignum.cz/crt/psrootqca4.crt

Assignee: nobody → kwilson
Component: Untriaged → CA Certificate Root Program
Product: Firefox → NSS
QA Contact: kwilson
Summary: CA Certificate Root Program → CA PostSignum by Ceska posta, s.p. (Czech Post)
Version: 70 Branch → other

The information for this request is here:

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

Dear CA, Please add another comment to this bug after you have completed steps 5 through 8 of
https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case

If you will be requesting the Websites (SSL/TLS) trust bit, then please also complete a BR Self Assessment.
https://wiki.mozilla.org/CA/BR_Self-Assessment

Status: UNCONFIRMED → ASSIGNED
Type: enhancement → task
Ever confirmed: true
Whiteboard: [ca-verifying] - KW 2019-12-11 - Comment #1

Initially, two items have been identified during our Mozilla audit verification process.
1 - Postsignum's audit report needs to be hosted on the TayllorCox website/domain.
2 - The NAB accreditation for TayllorCox (https://www.cai.cz/OA/pdf/P91_2020_EN.pdf) needs to state, in addition to EN 319-403, that TayllorCox is accredited to perform audits conforming to EN 319-401, EN 319-411-1, and EN 319-411-2. See https://wiki.mozilla.org/CA/Audit_Statements#Standard_Check

Assignee: kwilson → bwilson
Flags: needinfo?(vyvoj.postsignum)
Whiteboard: [ca-verifying] - KW 2019-12-11 - Comment #1 → [ca-verifying] - BW 2020-08-27 - Comment #2

Hello, The auditor has been requested to add the items. We are waiting for his answer. I will let you know when it has been done.

Flags: needinfo?(vyvoj.postsignum)

Hello,

  1. We are waiting for approval.

  2. Auditor's statement:

„ The rules for the accreditation of trusted services are set for the Czech Republic by the Ministry of Interior and are fixed. The link to ETSI standards is in the mentioned DKP document (Annotation in the section 4. Abbreviations). The link to DKP is here:

https://www.mvcr.cz/soubor/dkp-v3-0-en.aspx
https://www.mvcr.cz/docDetail.aspx?docid=22021695&doctype=ART&

To clarify, I would like to add that none of the accredited certification bodies in the Czech Republic has separately stated ETSI standards in the scope of accreditation. These standards are not offered by the national accreditation body for accreditation within the framework of certification schemes. Other platforms have accepted the form of accreditation in the Czech Republic.“
Please let us know if the auditor's statement is acceptable.

Flags: needinfo?(bwilson)

We will need something provided by the NAB. See this as an example - https://bugzilla.mozilla.org/attachment.cgi?id=9178797

Hello, we are providing the required document from the NAB.

Flags: needinfo?(bwilson)

The text of the attached Czech NAB Confirmation of TayllorCox reads as follows:

Czech Institute for Accreditation, o.p.s..
„Accredo – I give trust“
Un Prague on 14. 10. 2020
Čj: 006806/20/ČIA/100_001
Case: Request for confirmation
Dear Mr Engineer,
Czech Institute for Accreditation o.p.s. (ČIA) was issued for TAYLLORCOX s.r.o. based in Na Florenci 1055/35, 110 00 Prague 1 for its certification body No. 3239 TAYLLORCOX PCEB accreditation certificate No. 91/2020 valid from 13.02.2020 to 13.02.2025 regarding the qualification to perform product certification according to ČSN EN ISO / IEC 17065: 2013 - provision of trust services according to the eIDAS Regulation in the scope of accredited activities listed in the Annex to this certificate. The Certification schemes for eIDAS stated in the Certificate (ČSN ETSI EN 319403 V2.2.2 in conjunction with DKP version 2) contain, among other things, the requirements of the following technical standards ETSI EN 319 403, ETSI EN 319 401, ETSI EN 319 411-1 and ETSI EN 319 411 -2.
Kind regards
Mgr. Dušan Vácha
Director of the Department of Certification and Inspection Bodies
electronically signed
Ing. Radek Nedvěd
TAYLLORCOX s.r.o.
Na Florenci 1055/35
110 00 Praha 1

I have updated TayllorCox accreditation. (Audit letters will also need to be retrievable from TayllorCox's website.)
I am assuming that Ceska posta wants to enable the websites trust bit, so now it needs to provide a BR self-assessment and an updated CP/CPS.
The BR self assessment is located here: https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing
Other information is available here: https://wiki.mozilla.org/CA/BR_Self-Assessment

(In reply to Ben Wilson from comment #8)

I have updated TayllorCox accreditation. (Audit letters will also need to be retrievable from TayllorCox's website.)
I am assuming that Ceska posta wants to enable the websites trust bit, so now it needs to provide a BR self-assessment and an updated CP/CPS.
The BR self assessment is located here: https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing
Other information is available here: https://wiki.mozilla.org/CA/BR_Self-Assessment

Hello,

Audit letters are published on the auditor's website. Link: https://pceb.tayllorcox.cz/Documents.html
Your assume is correct, we are working on BR self-assessment and an update CP/CPS. I will update you when it is done.

Thank you and regards.

Thanks. I've updated your record in the CCADB - https://ccadb.force.com/5001J00000oRJk1QAG

Summary: CA PostSignum by Ceska posta, s.p. (Czech Post) → Add PostSignum Root QCA 4 to Root Store

Please review your issuance records for TLS server certificates (EKU = TLS Web Server Authentication) under the PostSignum Public CA 5 and correct the errors by revoking and replacing the certificates:

(1) SANs containing email addresses - 452 certificates
(2) Organization name too long (>64 characters) - 14 certificates
(3) OU field too long (>64 characters) - 3 certificates
(4) Common name not contained as one of the SANs - 32 certificates
(5) Internal server name as a SAN (https://crt.sh/?id=3442908887) - 1 certificate
(6) Certificate lifetime > 397 days - 352 certificates

And look into the following CABlint and Zlint errors:
CABlint
Unknown TLD in SAN (2 certificates)
DNSName is not in preferred syntax (2 certificates)
Constraint failure in X520OrganizationName: ASN.1 constraint check failed: UTF8String: constraint failed (14 certificates)
Constraint failure in X520OrganizationalUnitName: ASN.1 constraint check failed: UTF8String: constraint failed (3 certificates)
Zlint
Characters in labels of DNSNames MUST be alphanumeric, - , _ or * (28 certificates)
DNSNames must have a valid TLD. (30 certificates)
DNSNames should not have an empty label. (4 certificates)

Flags: needinfo?(vyvoj.postsignum)

OCSP Errors
When I run an OCSP check of the test website, https://www.postsignum.eu:8443, I receive the following warnings (W) and errors (E):

W - content-Type in response is set 'application/x-pkcs7-crl' and should be replaced with 'application/pkix-crl' (RFC 5280, section 4.2.1.13)
W - Last-Modified header is not the same as ThisUpdate (RFC 5019, section 6.2)
W - Expires cache header not set (RFC 5019, section 6.2)
E - OCSP response must be valid for at least 8 hours
E - OCSP response must be available at least 8 hours before the current period expires or at ½ the validity if valid for more than 16 hours
E - NextUpdate not set (RFC 5019, section 2.2.4)

(In reply to Ben Wilson from comment #12)

OCSP Errors
When I run an OCSP check of the test website, https://www.postsignum.eu:8443, I receive the following warnings (W) and errors (E):

W - content-Type in response is set 'application/x-pkcs7-crl' and should be replaced with 'application/pkix-crl' (RFC 5280, section 4.2.1.13)
W - Last-Modified header is not the same as ThisUpdate (RFC 5019, section 6.2)
W - Expires cache header not set (RFC 5019, section 6.2)
E - OCSP response must be valid for at least 8 hours
E - OCSP response must be available at least 8 hours before the current period expires or at ½ the validity if valid for more than 16 hours
E - NextUpdate not set (RFC 5019, section 2.2.4)

Hello,
Our CA provides the OCSP service according to RFC 6960. There is no data caching, so we do not have the NextUpdate item listed. OCSP responses are always online.

Flags: needinfo?(vyvoj.postsignum) → needinfo?(bwilson)

(In reply to Ben Wilson from comment #11)

Please review your issuance records for TLS server certificates (EKU = TLS Web Server Authentication) under the PostSignum Public CA 5 and correct the errors by revoking and replacing the certificates:

(1) SANs containing email addresses - 452 certificates
(2) Organization name too long (>64 characters) - 14 certificates
(3) OU field too long (>64 characters) - 3 certificates
(4) Common name not contained as one of the SANs - 32 certificates
(5) Internal server name as a SAN (https://crt.sh/?id=3442908887) - 1 certificate
(6) Certificate lifetime > 397 days - 352 certificates

And look into the following CABlint and Zlint errors:
CABlint
Unknown TLD in SAN (2 certificates)
DNSName is not in preferred syntax (2 certificates)
Constraint failure in X520OrganizationName: ASN.1 constraint check failed: UTF8String: constraint failed (14 certificates)
Constraint failure in X520OrganizationalUnitName: ASN.1 constraint check failed: UTF8String: constraint failed (3 certificates)
Zlint
Characters in labels of DNSNames MUST be alphanumeric, - , _ or * (28 certificates)
DNSNames must have a valid TLD. (30 certificates)
DNSNames should not have an empty label. (4 certificates)

  1. We are currently working on it and the certificates are being replaced gradually. We accepted measures in 09/2020 when the error was discovered.
  2. and 3) If we understand this correctly, RFC 5280 allows more characters if the item is encoded as PrintableString (up to 128 characters) or UTF8String (up to 256 characters).
  3. We deal with it, the certificates will be replaced and revoked. Action has been taken.
  4. The certificate was revoked. This was an operator error.
  5. Our certificates are valid for exactly 397 days. Could you please specify what is the problem?
Flags: needinfo?(bwilson)
You need to log in before you can comment on or make changes to this bug.