1602415 - Add PostSignum Root QCA 4 to Root Store

Status: ASSIGNED

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

Description

[CA PostSignum]

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

Comment 1

[Kathleen Wilson]

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

Comment 2

[Ben Wilson]

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

Comment 3

[CA PostSignum]

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.

Comment 4

[CA 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.

Comment 5

[Ben Wilson]

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

Comment 6

[CA PostSignum]

Attachment: Confirmation - Czech Institute for Accreditation.pdf

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

Comment 7

[Ben Wilson]

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

Comment 8

[Ben Wilson]

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

Comment 9

[CA PostSignum]

(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.

Comment 10

[Ben Wilson]

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

Comment 11

[Ben Wilson]

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)

Comment 12

[Ben Wilson]

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)

Comment 13

[CA PostSignum]

(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.

Comment 14

[CA PostSignum]

(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?

Comment 15

[Ben Wilson]

A Compliance Self-Assessment needs to be completed and uploaded as an attachment to this bug. See https://wiki.mozilla.org/CA/Compliance_Self-Assessment. Also, according to subparagraph 4. of section 3.3 of the Mozilla Root Store Policy (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses), the CPS needs to be updated at least on an annual basis - "CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements." In other words, a CPS needs to be submitted that complies with all requirements highlighted in the Compliance Self-Assessment template - https://docs.google.com/spreadsheets/d/1ExZE6PWIBM8rV9c6p6fFxOWmZyvf6X4ucMQRv7usHEk/

Comment 16

[CA PostSignum]

(In reply to Ben Wilson from comment #15)

Hello, we are still waiting for your comments on these issues:

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. Our certificates are valid for exactly 397 days. Could you please specify what is the problem?

• according to the answers, new versions will be published and self-assessment uploaded.
  Thank you in advance.

Comment 17

[Ben Wilson]

I have read (https://www.mail-archive.com/[e-mail]/msg10622.html) that, despite the footnote, the following language in RFC 5280 limits the length of the field to 64 characters regardless of the data type:

-- Naming attributes of type X520OrganizationName

id-at-organizationName AttributeType ::= { id-at 10 }

-- Naming attributes of type X520OrganizationName:
-- X520OrganizationName ::=
-- DirectoryName (SIZE (1..ub-organization-name))

-- Expanded to avoid parameterized type:
X520OrganizationName ::= CHOICE {
teletexString TeletexString
(SIZE (1..ub-organization-name)),
printableString PrintableString
(SIZE (1..ub-organization-name)),
universalString UniversalString
(SIZE (1..ub-organization-name)),
utf8String UTF8String
(SIZE (1..ub-organization-name)),
bmpString BMPString
(SIZE (1..ub-organization-name)) }

If your certificates are valid for only 397 days, then I do not see a problem. However, many CAs have encountered a problem when an additional second is actually part of the certificate's validity period. Are you sure that those 352 certificates did not have an extra second?

Comment 18

[CA PostSignum]

(In reply to Ben Wilson from comment #17)

ad is the length of the organizationName
Please could you comment on the note on page 123 of RFC5280:

• Note - upper bounds on string types, such as TeletexString, are measured in characters. Excepting PrintableString or IA5String, a significantly greater number of octets will be required to hold such a value. As a minimum, 16 octets, or twice the specified upper bound, whichever is the larger, should be allowed for TeletexString. For UTF8String or UniversalString at least four times the upper bound should be allowed.

ad validity 397 days
Yes, we are sure, because the leap second was last on 31.12.2016. The validity period is therefore 397 days with an accuracy of the second.

Comment 19

[Ben Wilson]

The limitation is 64 characters, regardless of character set. (256 characters is not allowed) I'll take another look at these 14 certificates and get back to you.

Comment 20

[Ben Wilson]

The issue in Comments 16 though 19 is only the number of octets needed to represent the character, not the number of characters, which is greater than 64 in the O field. There are actually now 20 certificates with more than 64 characters in the O field. These certificates will need to be revoked. There are other issues that still need to be resolved in your CA system. See the results of this query:
https://cachecker-dot-ccadb-231121.appspot.com/summary/108558?max_depth=-1&start=2018-07-26&end=2021-09-27&z_lint=on&cab_lint=on&x509_lint=on

Severity	Lint	Issue	Affected Certs
W	x509	Duplicate SAN entry	5
E	x509	organizationName too long	20
E	x509	organizationalUnitName too long	4
E	CAB	commonNames in BR certificates must be from SAN entries	32
W	CAB	Underscore should not appear in DNS names	4
E	CAB	Unknown TLD in SAN	2
E	CAB	BR certificates must not contain rfc822Name type alternative name	456
W	CAB	Name has unknown attribute 2.5.4.97	5
E	CAB	Unqualified domain name in SAN	1
E	CAB	DNSName is not in preferred syntax	2
E	CAB	Constraint failure in X520OrganizationName: ASN.1 constraint check failed: UTF8String: constraint failed (X520OrganizationName.c:174)	20
E	CAB	Constraint failure in X520OrganizationalUnitName: ASN.1 constraint check failed: UTF8String: constraint failed (X520OrganizationalUnitName.c:174)	4
W	CAB	Duplicate SAN entry	5
W	CAB	BR certificates should be 397 days in validity or less	605
E	Z	Characters in labels of DNSNames MUST be alphanumeric, - , _ or *	28
E	Z	DNSNames must have a valid TLD.	30
E	Z	The common name field in subscriber certificates must include only names from the SAN extension	32
E	Z	The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types.	456
W	Z	DNSName should not have an underscore in labels left of the ETLD+1	4
E	Z	DNSNames should not have an empty label.	4
E	Z	The 'Organizational Unit Name' field of the subject MUST be less than 65 characters	4
E	Z	The 'Organization Name' field of the subject MUST be less than 65 characters	20
W	Z	TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC should not have a validity period greater than 397 days	605

Comment 21

[Ben Wilson]

Regarding the 397-day certificates - your certificates are actually 397 days PLUS one second, but you don't have to correct that because the 397-day limit in Section 6.3.2 of the Baseline Requirements is a "should." That section says, "[Certificates] MUST NOT have a Validity Period greater than 398 days."

Comment 22

[CA PostSignum]

(In reply to Ben Wilson from comment #21)

Is this a current test? There are a expired certificates also in the test, could you please tell us why are they appeared?

The 'Organization Name' field of the subject MUST be less than 65 characters

• we take the name from the official register of entities, it cannot be changed

Unknown TLD in SAN

• Certificates have expired and cannot be revoked

DNSName is not in preferred syntax

• Certificates have expired and cannot be revoked

DNSNames should not have an empty label.

• Certificates have expired and cannot be revoked

No OCSP over HTTP
The certificate is valid for longer than 60 months
"Subject with organizationName, givenName or surname but without stateOrProvince or localityName"

• these are not certificates issued in accordance with the CAB, we do not know why they are part of the inspection, these are certificates of TSU units of the TSA system

Comment 23

[CA PostSignum]

(In reply to CA PostSignum from comment #22)

Hello Ben,
could you please reply on the comment below # 21?
Thank you for your help in this matter.

(In reply to Ben Wilson from comment #21)

Is this a current test? There are a expired certificates also in the test, could you please tell us why are they appeared?

The 'Organization Name' field of the subject MUST be less than 65 characters

• we take the name from the official register of entities, it cannot be changed

Unknown TLD in SAN

• Certificates have expired and cannot be revoked

DNSName is not in preferred syntax

• Certificates have expired and cannot be revoked

DNSNames should not have an empty label.

• Certificates have expired and cannot be revoked

No OCSP over HTTP
The certificate is valid for longer than 60 months
"Subject with organizationName, givenName or surname but without stateOrProvince or localityName"

• these are not certificates issued in accordance with the CAB, we do not know why they are part of the inspection, these are certificates of TSU units of the TSA system

Comment 24

[Ben Wilson]

Thank you for your responses in Comment #22. I believe those are satisfactory explanations. I am upgrading your Priority Level to P3.

Comment 25

[CA PostSignum]

Attachment: CA PostSignum Compliance Self Assessment

Comment 26

[CA PostSignum]

Comment on attachment 9291102 [details]
CA PostSignum Compliance Self Assessment

Attaching a self-assessment based on Mozilla's last Template for Compliance Self-Assessment version 2.8.

Comment 27

[CA PostSignum]

CA PostSignum CP/CPS has been published to https://www.postsignum.cz/certifikacni_politiky_vca.html

Comment 28

[CA PostSignum]

Attachment: qvalue_PostSignum.pdf

Comment 29

[Ben Wilson]

Attachment: PostSignum-CP-Evaluation.xlsx

Comment 30

[CA PostSignum]

Attachment: PostSignum-CP-Evaluation_comments.xlsx

Comment 31

[Ben Wilson]

Here are some additional comments.

Review of PostSignum CA CPS v. 5.0.2, dated August 15, 2023

General Issues

• Terminology:

• • Consider replacing "Certification Policy" with "Certificate Policy" or "Certification Practices Statement" throughout the document.
  • Consider replacing "SSL" with "TLS" throughout the document.
  • Consider replacing the word "chapter" with "section" throughout the CPS.
  • Are there other documents called the "individual certification policies," or are they a subset within this document?
  • How many certification policies exist? How many of these are expected to be created? Does this need to be done when this CP addresses a limited scope / only applies to TLS certificates that are governed by the Baseline Requirements and root store programs?

1. Introduction

• CAs Identified:

• • Observation: Good.

• Section 1.2:

• • Observation: The CPS states that it complies with the current version of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates and includes a statement: "In the event of a conflict between this Certification Policy and [CA/B], the provisions of [CA/B] shall apply."
  • Rating: Good.
  • Recommendation: Ensure that references reflect the current title of the BRs: "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates."

2. Publication and Repository Responsibilities

• Section 2.4:

• • Observation: "The certification service provider does not allow unauthorized access to issued certificates for which the subscriber has not given consent to publication."

  • Comments:

  • • What is the intent of this provision? These are publicly trusted TLS certificates and should be made available - would this provision allow the creation/issuance of MITM certificates without disclosing them? What about logging pre-certificates in Certificate Transparency?
    • Czech Post needs to ensure that certificate profiles are consistent with the newly updated profiles in section 7.1 of the Baseline Requirements.

3. Identification and Authentication

• Naming:

• • Section 3.1.6:

  • • Observation: "The customer is responsible for the use of trademarks or registered trademarks in certificate fields which are not verified by the PostSignum PCA (see chapter 3.2.4)."
    • Recommendation: This statement slightly contradicts section 3.2.4, below. All information in the certificate must be verified.

• Non-verified Subscriber Information:

• • Section 3.2.4:

  • • Observation: The CPS states, "A Certificate contains only verified information by the certification authority."
    • Rating: Good.
    • Recommendation: Note that the OU field is now prohibited by the CABF Baseline Requirements.

• Wildcard Domain Verification:

• • Section 3.2.2.6:

  • • Observation: "Wildcard domains are allowed at second and higher levels. Verification be carried out in accordance with Chapter 3.2.2.4."
    • Recommendation: This is not enough detail. More explanation is needed.

4. Certificate Life-Cycle Operational Requirements

• Revocation Reasons:

• • Section 4.9.1:

  • • Recommendation: Revocation reasons should mirror sections 4.9.1.1 and 4.9.1.2 of the CABF Baseline Requirements.

• Revocation Requests:

• • Section 4.9.2:

  • • Observation: Anyone with the private key should be able to request revocation.
    • Recommendation: Update to allow revocation requests from any third party with proof of key compromise.

• Methods to Demonstrate Private Key Compromise:

• • Section 4.9.12:

  • • Observation: The process for third parties to demonstrate key compromise is not clear.
    • Recommendation: Specify the methods that PostSignum uses to receive notifications of key compromise and what will be accepted as proof/evidence.

5. Management, Operational, and Physical Controls

• Key Compromise Notification:

• • Section 5.7.3:

  • • Observation: "If there is a suspicion that the private key of PostSignum Public CA has been compromised, all certificate subscribers, the supervisory body, and subjects who have concluded a contract directly related to the provision of certification services will be informed electronically about the fact that this authority will no longer provide its activities. …."
    • Recommendation: Maintain a policy of informing root store operators of the compromise and the best estimate of the date of compromise.

• Section 5.7.2:

• • Observation: The section title “Computing resources, software, and/or data are corrupted” runs inside the paragraph.
  • Recommendation: Correct the formatting to clearly separate the section title from the paragraph.

6. Technical Security Controls

• Network Security Controls:

• • Section 6.7:

  • • Observation: The CPS references “CA/B”.
    • Recommendation: Amend to reference the most current version of the NCSSRs (Network and Certificate Systems Security Requirements), not “CA/B”. Also, please be aware of amendments by Ballot NS-003 and the upcoming Ballot NS-004.

• Certificate Serial Numbers:

• • Section 7.1:

  • • Observation: Serial numbers of end-entity certificates shouldn't be sequential and therefore predictable.
    • Recommendation: They should be pseudo-random-generated using a CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). Serial numbers must have 64 bits of entropy and be generated by a CSPRNG.

• EKU for Subordinate CAs:

• • Observation: Subordinate CAs that will issue TLS end-entity certificates must contain the id-kp-serverAuth EKU.
  • Recommendation: Ensure that the EKU for subordinate CAs is correctly configured.

9. Other Business and Legal Matters

• Subscriber Representations and Warranties:

• • Section 9.6.3:

  • • Recommendation: Should point by cross-reference to sections 4.1.2.3 and 4.1.2.5 of the CP.

Comment 32

[CA PostSignum]

(In reply to Ben Wilson from comment #31)

General Issues

• Terminology:
• Replaced.
• There are other certificate policies within other Subordinate Authorities, not related to TLS issuance.
• There are 10 CPs in total, they are Subordinate to the CP and extend the conditions for issuing individual types of certificates and TSA. There is only one CP for TLS. All CPs are subject to existing terms and conditions incl. EU Regulations and any changes are applied in them. Only the policy for TLS and Root is governed according to the MRSP.

1. Introduction
Edited.

2. Publication and Repository Responsibilities
TLS certificates are always published as part of the pre-certificate in Certificate Transparency. The choice not to publish the certificate refers to the search list on our website.

3. Identification and Authentication

• Edited.
• The applicant is not allowed to enter this item.
• Section 3.2.2.4 has been expanded.

4. Certificate Life-Cycle Operational Requirements

• The requirements are detailed in the section.
• In the event of a key compromise, the legitimacy of such a request will be investigated even in the case of a third party request.
• We will evaluate that this is a legitimate request based on the description of the event.

5. Management, Operational, and Physical Controls

• They would be informed immediately within 24 hours.
• Deleted.

6. Technical Security Controls
Edited.

• • Section 7.1:
• We will use this recommendation in a future release of the subordinate authority.
• It is set correctly, it is a mandatory item. The subordinate CA does not have this purpose set, as it was created in 2018. We expect this for the future CA.

9. Other Business and Legal Matters
Edited.

All changes are listed in the CP draft v. 5.1.1 in repository: https://www.postsignum.cz/certifikacni_politiky_vca.html

Comment 33

[CA PostSignum]

Attachment: PostSignum CCADB Self-Assessment 2024