643398 - Add PostSignum root certificate

Status: RESOLVED WONTFIX

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

Description

[Pavel Plachý]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Build Identifier: Other

General information about the CA’s associated organization
CA Company Name:	Ceska posta s.p.
Website URL:	        http://www.postsignum.cz
Organizational type:	
The PostSignum certification authority is a governmental certification authority (national government) operated by Ceska posta s.p. (Czech Post). 

PostSignum is an accredited provider of certification services in the Czech Republic (accreditation by the Ministry of the Interior of the Czech Republic). 

Qualified certification authorities from the PostSignum PKI hierarchy operate under Czech government regulations and must fulfil mandatory audit requirements stipulated in EU and Czech law.

Primark Market / Customer Base:	
The certification services of PostSignum are designated for the following groups of customers:
•	Organizations; and 
•	Individuals (Natural persons).

PostSignum does specialize in any particular market segment.

PostSignum operates in the Czech Republic market. Certificates issued by PostSignum CAs are recognized in Czech republic and in other EU countries.
Impact to Mozilla Users	Mozilla users will typically encounter the root certificate of PostSignum when sending/receiving S/MIME emails and also while web browsing (HTTPS servers doing SSL)

CA Contact Information	CA 
Email Alias:            [e-mail]
CA Phone Number:        [phone]
Title / Department:     Manager CA


Technical information about each root certificate
Certificate Name:	PostSignum Root QCA 2
Certificate Issuer Field:	
CN = PostSignum Root QCA 2
O = Česká pošta, s.p. [IČ 47114983]
C = CZ

Certificate Summary:	
A self-signed certificate of root certification authority PostSignum Root QCA 2. The root certification authority PostSignum Root QCA 2 issues system certificates for its subordinate certification authorities:
•	PostSignum Qualified CA 2
•	PostSignum Public CA 2
Root Cert URL:	http://www.postsignum.cz/crt/psrootqca2.crt
SHA1 Fingerprint:	
a0 f8 db 3f 0b f4 17 69 3b 28 2e b7 4a 6a d8 6d f9 d4 48 a3
Valid From:    2010-01-19
Valid To:      2025-01-19
Certificate Version:    x.509 v3
Certificate Signature Algorithm:    sha256RSA
Signing key parameters:	2048 bits

Test Website URL (SSL)Example Certificate (non-SSL)	

Test website URL: https://www.postsignum.cz/index.php?lang=en

Example of certificates:
PostSignum Qualified CA 2 (qualified certificates):
Certificate of an individual: 

http://www2.postsignum.cz/icz_szng_pcu/vss?VSS_SERV=ZCU003001&VSS_FORM=DATA&VSS_DAT1=1146095&content=DER&qualified=QCA

System certificate: 
http://www2.postsignum.cz/icz_szng_pcu/vss?VSS_SERV=ZCU003001&VSS_FORM=DATA&VSS_DAT1=1036211&content=DER&qualified=QCA

PostSignum Public CA 2 (non-qualified certificates):
Certificate of an individual: 
http://www2.postsignum.cz/icz_szng_pcu/vss?VSS_SERV=ZCU003001&VSS_FORM=DATA&VSS_DAT1=534030&content=DER&qualified=VCA

Server certificate: 
http://www2.postsignum.cz/icz_szng_pcu/vss?VSS_SERV=ZCU003001&VSS_FORM=DATA&VSS_DAT1=516719&content=DER&qualified=VCA

CRL URL	Certificate revocation lists might be obtained from the following URLs:

PostSignum Root QCA 2
http://www.postsignum.cz/crl/psrootqca2.crl
http://www2.postsignum.cz/crl/psrootqca2.crl
http://postsignum.ttc.cz/crl/psrootqca2.crl

PostSignum Qualified CA 2:
http://www.postsignum.cz/crl/psqualifiedca2.crl
http://www2.postsignum.cz/crl/psqualifiedca2.crl
http://postsignum.ttc.cz/crl/psqualifiedca2.crl

PostSignum Public CA 2:
http://www.postsignum.cz/crl/pspublicca2.crl
http://www2.postsignum.cz/crl/pspublicca2.crl
http://postsignum.ttc.cz/crl/pspublicca2.crl

The period for updating CRL for end-entity certificates is set to 12 hours (NextUpdate field in CRL). The requirement for updating CRLs for end-entity certificates is stated in the Certification Policies and CPS in the section 2.3.

OCSP URL:	
The verification of the validity of the end user or CA certificates via the OSCP protocol is not currently available. 

Requested Trust Bits:	Websites (SSL/TLS), Email (S/MIME)
SSL Validation Type:	OV
EV Policy OID(s):	Not applicable. EV certificates are not issued.

CA Hierarchy information for each root certificate

CA Hierarchy	PostSignum Root QCA 2 is a root certification authority that issues qualified system certificates to subordinate certification authorities:
•	PostSignum Qualified CA 2 issuing qualified certificates to the end users; and
•	PostSignum Public CA 2 issuing commercial (non-qualified) certificates to the end users.
 
Both intermediate CAs (PostSignum Qualified CA 2 and PostSignum Public CA 2) are operated internally.

Certificates of intermediate CAs:
http://www.postsignum.cz/crt/psqualifiedca2.crt (PostSignum Qualified CA 2)
http://www.postsignum.cz/crt/pspublicca2.crt (PostSignum Public CA 2)

Externally Operated SubCAs:	
Not applicable. The root certification authority PostSignum Root QCA 2 does not sign any subordinate CAs operated by third parties. Both subordinate CAs (PostSignum Qualified CA 2 and PostSignum Public CA 2) are operated by the same subject as the root CA (Ceska Posta s.p.).

Cross-Signing:	
Not applicable. PostSignum Root QCA 2 has not issued any cross-signing certificates.


Verification Policies and Practices Policy Documentation:	
Language(s) that the documents are in:
CP: Czech
CPS: Czech
•	Relying Party Agreement: Czech

Certification policies
PostSignum Root QCA 2:
•	http://www.postsignum.cz/files/politiky/QCA_cp_QCARoot_v_2_0.pdf (PostSignum certification authorities)

PostSignum Qualified CA 2:
•	http://www.postsignum.cz/files/politiky/QCA_osobni_crt_v2-0.pdf (personal certificates)
•	http://www.postsignum.cz/files/politiky/QCA_systemove_crt_v2-0.pdf (systems certificates)

PostSignum Public CA 2:
•	http://www.postsignum.cz/files/politiky/VCA_osobni_crt_v2-0.pdf (personal certificates)
•	http://www.postsignum.cz/files/politiky/VCA_serverove_crt_v2-0.pdf (server certificates)

Certification Practice Statement 
•	A Certification Practice Statement (CPS) exists, but it is not publicly available to subscribers.

Relying Party Agreement
•	http://www.postsignum.cz/files/smlouvy/PO_PFO_smlouva.doc (organization) 
•	http://www.postsignum.cz/files/smlouvy/FO_smlouva.doc (natural person)Audits	Audit Type: Audit of full PostSignum PKI infrastructure (ETSI TS 101 456, ETSI TS 102 042)

Auditor: Deloitte Advisory s.r.o.

Auditor Website: http://www.deloitte.com/view/en_CZ/cz/index.htm

URL to Audit Report and Management’s Assertions: Audit equivalency statement will be provided directly by the auditor (contact Mr. Vlastimil Cerveny, CIA, CISA; [e-mail])

Date of completion of last audit: February 26, 2010 (Microsoft Root Certification Program). PostSignum will be re-audited on or before March 2012.

SSL Verification Procedures:	
PostSignum requests to enable the Websites (SSL/TLS) trust bit.

Note: SSL/TLS certificates are only issued by the public certification authority PostSignum Public CA 2 that issues server certificates. The qualified certification authority PostSignum Qualified CA 2 does not issue this type of certificates.

The procedures for verifying that the domain name referenced in a server certificate (SSL/TLS) is owned/controlled by the subscriber is stated in the Certification Policy - Section 4.1.2.4 . Note that the CP is currently available only in Czech. 

http://www.postsignum.cz/files/politiky/VCA_serverove_crt_v2-0.pdf
This procedure is also stated in CPS (Note: CPS is not currently available to the public).

PostSignum Public CA 2 uses OV type verification when issuing server certificates. The procedure for verifying identity,  existence, and authority of the organization to request the certificate is described in the 
Certification Policy – Section 4.2.1. Note that the CP is currently available only in Czech language. 

http://www.postsignum.cz/files/politiky/VCA_serverove_crt_v2-0.pdf
This procedure is also stated in CPS (Note: CPS is not currently available to the public).

Email Address Verification Procedures:	
PostSignum requests to enable the Email (S/MIME) trust bit.

The current practice of PostSignum is that the email address of the subscriber is not verified. This is in accordance with the Czech legislative requirements and with PostSignum’s certification policies and CPS. 
http://www.postsignum.cz/files/politiky/QCA_osobni_crt_v2-0.pdf
http://www.postsignum.cz/files/politiky/VCA_osobni_crt_v2-0.pdf

The subscriber’s identity is verified against valid legal documents (valid ID card, passport, etc.), which are specified in the certification policies. The procedure for verifying the identity and authority of the certificate subscriber is described in the Certification Policy – Section 4.2.1 Note that the CP is currently available only in Czech language.
http://www.postsignum.cz/files/politiky/QCA_osobni_crt_v2-0.pdf (PostSignum Qualified CA 2)
http://www.postsignum.cz/files/politiky/VCA_osobni_crt_v2-0.pdf (PostSignum Public CA 2)
This procedure is also stated in CPS (CPS is not currently available to the public).
Code Signing Subscriber Verification Procedures	Not applicable. PostSignum does not request to enable the Code Signing Trust Bit.


Response to Mozilla's CA Recommended Practices (https://wiki.mozilla.org/CA:Recommended_Practices)
Publicly Available CP and CPS:	
Certification policies (CP) are publicly available on PostSignum’s official web site. A Certification Practice Statement (CPS) exists, but it is not publicly available to subscribers. All documents are currently not available in English.

PostSignum Root QCA 2
http://www.postsignum.cz/files/politiky/QCA_cp_QCARoot_v_2_0.pdf (PostSignum certification authorities)

PostSignum Qualified CA 2
http://www.postsignum.cz/files/politiky/QCA_osobni_crt_v2-0.pdf (personal certificates)
http://www.postsignum.cz/files/politiky/QCA_systemove_crt_v2-0.pdf (systems certificates)

PostSignum Public CA 2
http://www.postsignum.cz/files/politiky/VCA_osobni_crt_v2-0.pdf (personal certificates)
http://www.postsignum.cz/files/politiky/VCA_serverove_crt_v2-0.pdf (server certificates)

CA Hierarchy:
PostSignum PKI hierarchy consists of a single root CA with subordinate certification authorities. PostSignum wishes to supply a certificate of the single top-level root CA for Mozilla's root list (certificates of the subordinate authorities will not be submitted for Mozilla’s root list).

Audit Criteria:
PostSignum PKI hierarchy has been audited by an independent auditor. The most recent audit report is from February 2010. This audit was conducted by Deloitte and covered the full PKI hierarchy PostSignum (root and subordinate CAs). This audit was conducted against the following standards:
•	ETSI TS 101 456 (qualified CAs – PostSignum Root QCA 2, PostSignum Qualified CA 2)
•	ETSI TS 102 042 (public CA - PostSignum Public CA 2)
The audit equivalency statement is available upon request from the auditor. 
Auditor’s contact: Mr. Vlastimil Cerveny, CIA, CISA; Manager; Deloitte Advisory; [e-mail]

Document Handling of IDNs in CP/CPS:	
Currently it is not against the PostSignum’s certificate policy to use IDNs in issued certificates. PostSignum will address this issue in the next version of the Certification Policy for server certificates.

Revocation of Compromised Certificates:
Revocation of compromised certificates or certificates for which verification of subscriber information is known to be invalid is incorporated into PostSignum’s common practices (this issue is addressed in CP and CPS). Manager CA has the authority to revoke such certificates.

Verifying Domain Name Ownership:	
During the registration process the subscriber must present the verification of the legal identity together with an affidavit of ownership of the domain name. This procedure is described in the certification policy for server certificates.

Verifying Email Address Control:	
The current practice of PostSignum is that the email address of the subscriber is not verified. This is in accordance with the Czech legislative requirements and with PostSignum’s certification policies. The subscriber’s identity is verified against valid legal documents (valid ID card, passport, etc.), which are specified in the particular certification policy.

Verifying Identity of Code Signing Certificate Subscriber:	
Not applicable. PostSignum certification authorities do not issue code signing certificates.

DNS names go in SAN:	
Server certificates that are issued by PostSignum Public CA 2 contain primary DNS name in the Subject Common Name field of certificate.

Domain owned by a Natural Person:	
If the domain is owned by a natural person, the server certificate issued by PostSignum Public CA 2 will have the following fields:
•	CN = DNS
•	OU= identifier of a natural person (internal identification code)
Note: Field “O” is not used in server certificates for natural persons.

OCSP:	
Not applicable. The verification of the validity of the end user or CA certificates via the OSCP protocol is not currently available in PostSignum.

Response to Mozilla's list of potentially problematic practices (https://wiki.mozilla.org/CA:Problematic_Practices)

Long-lived DV certificates:	
No long-lived DV certificates exist, PostSignum only issues OV server certificates (SSL/TLS). The expiration period of the server certificates that are issued by PostSignum Public CA 2 is 1 year.

Wildcard DV SSL certificates:	
Currently it is not against the certification policy to use wildcards in server certificates (SSL/TLS) that are issued by PostSignum Public CA 2. PostSignum will address this issue in the next version of the Certification Policy for server certificates. Note that the server certificates that are issued by PostSignum Public CA 2 are OV type as the legal identity of the subscriber is always verified prior to issuing the certificate.

Email Address Prefixes for DV Certs:	
Not applicable. PostSignum Public CA 2 does not issue domain validating (DV) server certificates (SSL/TLS) that would use an email address to verify the domain ownership. The ownership of the domain name is verified by verifying the legal identity together with an affidavit of ownership of the domain name. This procedure is described in the certification policy for server certificates.

Delegation of Domain / Email Validation to Third Parties:	
PostSignum does not delegate the validation of the subscriber’s identity or domain/email ownership to third parties. Validation is performed by Registration Authorities that are operated by Ceska Posta s.p. Practices of Registration Authorities are audited together with the issuing of certification authorities.

Issuing End Entity Certificates Directly from Roots:	
The root certification authority PostSignum Root QCA 2 only issues certificates to its subordinate certification authorities (PostSignum Qualified CA 2 and PostSignum Public CA 2). The root authority is in off-line mode. The end entity certificates are issued only by these subordinate (or issuing) certification authorities.

Allowing External Entities to Operate Subordinate CAs:	
Not applicable. Both subordinate CAs (PostSignum Qualified CA 2 and PostSignum Public CA 2) are operated by the same subject as the root CA (Ceska Posta s.p.).

Distributing Generated Private Keys in PKCS#12 Files:	
Not applicable. PostSignum CAs do not generate the key pairs for their subscribers. PostSignum CAs do not have any control over subscriber’s private keys. The subscribers generate their own key pairs.

Certificates Referencing Hostnames or Private IP Addresses:	
Currently it is not against the certification policy to issue server certificates that contain public DNS or private IP addresses. PostSignum will address this issue in the next version of the certification policy.

Issuing SSL Certificates for Internal Domains:	
PostSignum Public CA 2 currently does not apply any restriction against using non-existent .int domain names in issuing certificates. This issue will be addressed in the next version of the certification policy for server certificates. A list of domain names of issued server certificates will be internally reviewed in order to verify that there are no certificates with .int domain names.

OCSP Responses Signed by a Certificate under a Different Root:	
Not applicable. The verification of the validity of the end user or CA certificates via the OSCP protocol is not currently available in PostSignum.

CRL with Critical CIDP Extension:	
Not applicable. “CRL Issuing Distribution Point” (CIDP) extensions in the CRLs of PostSignum CAs are not flagged as critical.

Generic Names for CAs:	
Generic names for CAs are not used. All certification authorities within PostSignum PKI hierarchy have meaningful names:
•	PostSignum Root QCA 2,
•	PostSignum Qualified CA 2,
•	PostSignum Public CA 2.
Additionally, the issuer and subject information in the PostSignum Root QCA 2 certificate also provides a clear indication 

about who owns or operates the certificate. 
•	CN = PostSignum Root QCA 2
•	O = Česká pošta, s.p. [IČ 47114983]
•	C = CZ

Lack of Communication With End Users:	
Subscribers and relying parties can contact PostSignum CA via:
•	Phone: [phone], or
•	E-mail: [e-mail]
Also, PostSignum is willing to answer any questions from the Mozilla community regarding the process of admission into the 

Mozilla root program. The contact person is Manager CA: ([e-mail])



Reproducible: Always

Comment 1

[Pavel Plachý]

Attachment: CA PostSignum details

Comment 2

[Pavel Plachý]

Attachment: Audit equivalency statement

Comment 3

[Kathleen Wilson]

Starting the information verification phase for this request, as per
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Comment 4

[Kathleen Wilson]

Here are my findings so far...

> Audit
> Audit equivalency statement will be provided directly by the 
> auditor (contact Mr. Vlastimil Cerveny, CIA, CISA; [e-mail])

Please obtain an appropriate, public-facing statement from an auditor and post it in this bug.

> Domain Name Verification
> The procedures for verifying that the domain name referenced in a server 
> certificate (SSL/TLS) is owned/controlled by the subscriber is stated in the 
> Certification Policy - Section 4.1.2.4 . 

I did a Google Translation of the section, and it seems to be stating what the certificate subscriber must provide. It doesn't appear to state what the RA must do to use an independent source to verify that the domain name is owned/controlled by the certificate subscriber.

It looks like the CP for public server certs will need to be updated to meet the requirements of the Mozilla CA Certificate Policy. In particular, see the second bullet in section 6, and the third bullet in section 7 of 
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
More info/recommendations may be found here:
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership

> Organization Verification Procedures
> The procedure for verifying identity, existence, and authority of the 
> organization to request the certificate is described in the Certification 
> Policy – Section 4.2.1

Please provide the English translation of this section, and any other relevant sections that describe the actions that the RA must take to confirm the authenticity of the information that is provided by the certificate subscriber.

> Email Address Verification Procedures
> The current practice of PostSignum is that the email address of the 
> subscriber is not verified. This is in accordance with the Czech legislative 
> requirements and with PostSignum’s certification policies and CPS.

This will be a problem for us.
See the first and second bullet points of section 7 of
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
According to our policy, if the ownership/control of the email address is not verified, then it cannot be included in the certificate, and the email trust bit cannot be enabled.

> Server certificates that are issued by PostSignum Public CA 2 contain 
> primary DNS name in the Subject Common Name field of certificate.

Does that mean that you don't put the DNS name in the SAN? If yes, that's a problem for us.


> Items to address in next version of the CP
> IDNs
> Wildcard SSL certs
> certs referencing hostnames or private IP addresses
> internal domains (such as .int)

OK

Comment 5

[Pavel Plachý]

Reply to comment #4

1)Audit - Audit equivalency statement will be provided directly by the auditor (contact Mr. Vlastimil Cerveny, CIA, CISA; [e-mail])

Please obtain an appropriate, public-facing statement from an auditor and post it in this bug.

Answer: The audit equivalency statement is included in this bug, see attachment https://bugzilla.mozilla.org/attachment.cgi?id=520622

2)Domain Name Verification - The procedures for verifying that the domain name referenced in a server certificate (SSL/TLS) is owned/controlled by the subscriber is stated in the Certification Policy - Section 4.1.2.4

Mozilla CA Certificate Policy
Section 7/3
• for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;

Answer: Currently, all certificate applicants must provide affidavit that they are authorized to use a domain name in the certificate request. Some of the PostSignum’s Registration Authorities (“OM RAs”) are already performing the verification of Domain Name ownership using information provided by regional domain registrant for the .cz domain (https://www.nic.cz/). This process is currently described only in the internal procedures for RAs. A description of this process will be added to the new version of the Certificate Practice Statement. 

3)Mozilla CA Certificate Policy
Section 6/2
• publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement);

Answer: The next version of PostSignum’s Certificate Practice Statement will be publicly available to all subscribers.

4)Organization Verification Procedures
 English translation of section 4.2.1 in CP

4.2.1 Identification and Authentication
The applicant for the certificate shall appear at the registration authority and submit the following: 
•	One document of personal identification in the case of employees of an organization or self-employed individuals, or
•	One personal ID and a supplementary personal ID in the case of individuals who are not self-employed.

Furthermore, the applicant shall provide the employee of the registration authority with an electronic application in PKCS#10 format including a public key, either on a medium or other means as specified on the website of PostSignum QCA.

During the registration, the certificate applicant also submits a password which will be used for superseding the certificate if needed. The employee of the registration authority shall check the personal ID of the certificate applicant and create and save copies thereof. He/she will verify in the list of applicants that the relevant person is actually entitled to apply for the certificate pursuant to the relevant certification policy and check whether the data in the electronic application correspond with the data in the list of applicants. 

5)Email Address Verification Procedures
Mozilla CA Certificate Policy
Section 7/1,2
•	all information that is supplied by the certificate subscriber must be verified by using an independent source of information or an alternative communication channel before it is included in the certificate; 
•	messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf;

Answer: The following controls are currently in place for e-mail address verification:
• For employee certificates: an authorized employee of an organization (subscriber) must provide RA with a list of employees (including names and e-mail addresses) that are authorized to request certificates on behalf of the organization. Information in the employee certificate (including e-mail address) is based on the information provided in the authorized list of employees.
• Correctness of an e-mail address must be reviewed by a certificate applicant prior to the certificate being issued.
• The e-mail address in a certificate is used as a contact e-mail address for sending information about issued certificates.

6) Server certificates that are issued by PostSignum Public CA 2 contain 
primary DNS name in the Subject Common Name field of certificate.

Answer: According to the new version of PostSignum’s Certification Policy, the subscribers will be able to include a limited number of DNS into SAN. Primary DNS will still be in CN.

Comment 6

[Kathleen Wilson]

(In reply to comment #5)
> Reply to comment #4
> 
> 1)Audit - Audit equivalency statement will be provided directly by the auditor
> (contact Mr. Vlastimil Cerveny, CIA, CISA; [e-mail])
> 
> Please obtain an appropriate, public-facing statement from an auditor and post
> it in this bug.
> 
> Answer: The audit equivalency statement is included in this bug, see attachment
> https://bugzilla.mozilla.org/attachment.cgi?id=520622
> 

In this statement is: "In accordance with the Czech legislation, PostSignum will be re-audited on or before March 2012 (four-year audit cycle)."

Please see our requirement for annual audits in section 4 of
http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html

Other CAs have ETSI certificates that are valid for 3 year, but they also have annual audits performed.

I see the statement about the audit that was conducted in 2010. Was that a one-time thing? Or do you plan to have annual audits?  If you plan to have annual audits, is that documented in your CP/CPS?

Comment 7

[Kathleen Wilson]

(In reply to comment #5)

> 2)Domain Name Verification
> Answer: Currently, all certificate applicants must provide affidavit that they
> are authorized to use a domain name in the certificate request. Some of the
> PostSignum’s Registration Authorities (“OM RAs”) are already performing the
> verification of Domain Name ownership using information provided by regional
> domain registrant for the .cz domain (https://www.nic.cz/). This process is
> currently described only in the internal procedures for RAs. A description of
> this process will be added to the new version of the Certificate Practice
> Statement. 

When you update the CPS, please refer to:
https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership

Also, there has been (and will be more) discussion in mozilla.dev.security.policy regarding the role of RAs versus CAs, especially regarding domain and email validation. 

Please post a comment in this bug when the document has been updated.

>  
> Answer: The next version of PostSignum’s Certificate Practice Statement will 
> be publicly available to all subscribers.

Please post a comment here when that happens.

> 
> 4)Organization Verification Procedures
>  English translation of section 4.2.1 in CP
> ...
> He/she will verify in the list of
> applicants that the relevant person is actually entitled to apply for the
> certificate pursuant to the relevant certification policy and check whether 
> the data in the electronic application correspond with the data in the list of
> applicants. 

What is the list of applicants? Who creates it? How is it a valid third-party source for checking data?

> 5)Email Address Verification Procedures
> Answer: The following controls are currently in place for e-mail address
> verification:
> • For employee certificates: an authorized employee of an organization
> (subscriber) must provide RA with a list of employees (including names and
> e-mail addresses) that are authorized to request certificates on behalf of the
> organization. Information in the employee certificate (including e-mail
> address) is based on the information provided in the authorized list of
> employees.
> • Correctness of an e-mail address must be reviewed by a certificate applicant
> prior to the certificate being issued.
> • The e-mail address in a certificate is used as a contact e-mail address for
> sending information about issued certificates.

Do the email addresses all have to be within the same domain? And has that domain been verified as belonging to that organization?

Again, all such controls have to be documented in a public-facing and audited document, such as a CP or CPS.


> 6) Server certificates that are issued by PostSignum Public CA 2 contain 
> primary DNS name in the Subject Common Name field of certificate.
> 
> Answer: According to the new version of PostSignum’s Certification Policy, the
> subscribers will be able to include a limited number of DNS into SAN. Primary
> DNS will still be in CN.

Does this mean that the primary DNS will only be in the CN, and not in the SAN?

Please see
https://wiki.mozilla.org/CA:Problematic_Practices#DNS_names_in_SANs

Comment 8

[Kathleen Wilson]

Closing, since no response from CA since 2011.

Comment 9

[vhaisman]

Would it be possible to restart the process of or reconsider the addition of PostSignum certificate? I am not sure if this helps, but here is link to "PostSignum CA Certification Policy applicable to
qualified certificates for electronic signature" document: http://www.postsignum.cz/files/politiky/QCA_elsign_v1_0_ENG.pdf

These certificates are used by Czech Republic government agencies and ministries.

Comment 10

[Kathleen Wilson]

(In reply to vhaisman from comment #9)
> Would it be possible to restart the process of or reconsider the addition of
> PostSignum certificate?

In order to move forward with this request, a Primary Point of Contact** representing the CA will need to file a new bug as described here:
https://wiki.mozilla.org/CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request

And provide all of the information listed here: https://wiki.mozilla.org/CA:Information_checklist

** https://wiki.mozilla.org/CA:Information_checklist#CA_Primary_Point_of_Contact_.28POC.29