817994 - KIR S.A.'s application for inclusion in Mozilla Root Certificate Program

Status: RESOLVED FIXED

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

Description

[certificates]

Attachment: All the necessary information about CA

Comment 1

[certificates]

Attachment: Example Certificate (non-SSL)

Comment 2

[Kathleen Wilson]

Starting the information verification phase.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Note: Mozilla's CA Certificate Program is for root certificates or trust anchors. Therefore, this request is for inclusion of the "SZAFIR ROOT CA" certificate.

Comment 3

[Kathleen Wilson]

Attachment: Initial CA Information Document

Comment 4

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #3)
> Created attachment 695070 [details]
> Initial CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 5

[certificates]

Attachment: Additional information

additional information to clarify doubts

Comment 6

[Kathleen Wilson]

Attachment: Updated CA Information Document

Highlighted items indicate where further updates/improvements or clarifications are needed in order to comply with Mozilla's CA Certificate Policy and the CA/Browser Forum's Baseline Requirements.

Comment 7

[certificates]

Attachment: Additional explanations

Please, find attached further updates.

Comment 8

[Kathleen Wilson]

Thank you for the additional information.

I understand that implementing CRL and OCSP according to the CA/Browser Forum's Baseline Requirements will take time and effort.

I appreciate that you also plan to update your CPS regarding the commitment to comply with the CA/Browser Forum's Baseline Requirements, and also regarding verification of data to be included certificates even if they are test certificates.

Is the "SZAFIR ROOT CA" root certificate included in any other major browsers? If yes, which? If no, why not? 

Regarding your question:
> Could you please confirm that with this commitment it will be 
> possible to proceed without any delays in Mozilla Root Certificate Program?

I cannot make such a commitment until after public discussion has occurred as per 
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 9

[certificates]

(In reply to Kathleen Wilson from comment #8)

Regarding your question:

Is the "SZAFIR ROOT CA" root certificate included in any other major browsers?
If yes, which? If no, why not?

"SZAFIR ROOT CA" root certificate is not included in any other major browsers. We sent our aplication to most of them immedietly after receiving the WebTrust's seal but the process is ongoing as well as in your program.

Comment 10

[Kathleen Wilson]

Please update this bug when KIR S.A. is in compliance with the CA/Browser Forum's Baseline Requirements (including CRL, OCSP, updated CPS) for new certificate issuance.

Comment 11

[certificates]

Attachment: Additional information

KIR S.A. is in compliance with the CA/Browser Forum's Baseline Requirements (including CRL, OCSP, updated CPS) for new certificate issuance.

Comment 12

[Kathleen Wilson]

Thank you for the update. When I get caught up after the holidays I will re-review the information in this bug.

Comment 13

[Kathleen Wilson]

I have two remaining questions...


When do you expect to have an auditor's statement of compliance with the CA/Browser Forum's Baseline Requirements?


(In reply to certificates from comment #9)
> "SZAFIR ROOT CA" root certificate is not included in any other major
> browsers. We sent our aplication to most of them immedietly after receiving
> the WebTrust's seal but the process is ongoing as well as in your program.

What is the status of inclusion in other browsers?

Comment 14

[certificates]

(In reply to Kathleen Wilson from comment #13)
> I have two remaining questions...
> 
> 
> When do you expect to have an auditor's statement of compliance with the
> CA/Browser Forum's Baseline Requirements?
> 
> 
> (In reply to certificates from comment #9)
> > "SZAFIR ROOT CA" root certificate is not included in any other major
> > browsers. We sent our aplication to most of them immedietly after receiving
> > the WebTrust's seal but the process is ongoing as well as in your program.
> 
> What is the status of inclusion in other browsers?

Answering your questions:

1. When do you expect to have an auditor's statement of compliance with the CA/Browser Forum's Baseline Requirements?

As this requirement is new for our auditor, we wait for his decision if they are ready to make this statement during this audit (it just started). At this moment we received confirmation that they will check our compliance with the CA/Browser Forum's Baseline Requirements during this audit, but in their organisation there is no procedure to making such statements, so it could be a problem to make it now. For sure it will be done during next audit, which will start at the beginnig of next year.

2. What is the status of inclusion in other browsers?

We are near the end of the process in Microsoft. They did not finished distribution in November but they promised to finish it during next root update package distribution. Please find enclosed last e-mail from Microsoft with this topic.

Comment 15

[certificates]

Attachment: Answer from Microsoft.pdf

Comment 16

[certificates]

What's the status of our application in Mozilla Program?

KIR S.A. made all the explanations and done all the improvements. We expect further action from your side as soon as possible.

We would like to confirm that our root certificate is included in Internet Explorer.

Comment 17

[Kathleen Wilson]

(In reply to certificates from comment #14)
> 1. When do you expect to have an auditor's statement of compliance with the
> CA/Browser Forum's Baseline Requirements?
> 
> As this requirement is new for our auditor, we wait for his decision if they
> are ready to make this statement during this audit (it just started). At
> this moment we received confirmation that they will check our compliance
> with the CA/Browser Forum's Baseline Requirements during this audit, but in
> their organisation there is no procedure to making such statements, so it
> could be a problem to make it now. For sure it will be done during next
> audit, which will start at the beginnig of next year.


See:
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Audit_Criteria
https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements

Please update this bug when the BR audit statement is available. 

Note that Mozilla's process and policy require that public-facing audit statements be provided annually, and this includes the BR audit statement.
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/


(In reply to certificates from comment #16)
> What's the status of our application in Mozilla Program?

This request is in steps 2 and 3 of the overall inclusion process as described here: https://wiki.mozilla.org/CA

Will need the BR audit statement before we can proceed to the next step.

Comment 18

[certificates]

We received information from EY, which should be sufficient:

"EY verifies compliance with CA/Browser Forum Guidelines by using "SSL Baseline Requirements Audit Criteria V1.1" workprogram issued by AICPA. When asked by us for possibility of introduction of amendment to the existing WebTrust report confirming explicitly that they verified compliance with CA/Browser Forum Guidelines, they checked such option with the WebTrust task force and as well as with their US practice and came back to us with information that no additional statement can be included in the WebTrust report. The existing wording already confirms such verification. The opinion already states that EY examined and tested management's assertion that they comply with the CAB Forum guidelines which should be sufficient. 

Please note that we have appropriate statement in CPS: 
"KIR S.A. provides certification services in compliance with the requirements of the current version of the Baseline Requirements for the Issuance and Management of Publicly - Trusted Certificates published at www.cabforum.org. In the event of any discrepancies between the CPS and the said document, the document shall prevail over the CPS." 
and EY confirms with their WebTrust report that our CPS is in-line with audited CA processes and environment."

Please find below our friendly links to CPS and CP. You can find there the most recent documents:

http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf
http://elektronicznypodpis.pl/files/doc/certification_policy.pdf

Comment 19

[Erwann Abalea]

The old intermediate CA certificate hasn't been revoked (even if there's no CRLDP/AIA:OCSP, you should revoke it).

(In reply to certificates from comment #18)
> We received information from EY, which should be sufficient:
> 
> "EY verifies compliance with CA/Browser Forum Guidelines by using "SSL
> Baseline Requirements Audit Criteria V1.1" workprogram issued by AICPA. When
> asked by us for possibility of introduction of amendment to the existing
> WebTrust report confirming explicitly that they verified compliance with
> CA/Browser Forum Guidelines, they checked such option with the WebTrust task
> force and as well as with their US practice and came back to us with
> information that no additional statement can be included in the WebTrust
> report. The existing wording already confirms such verification. The opinion
> already states that EY examined and tested management's assertion that they
> comply with the CAB Forum guidelines which should be sufficient. 

I object that your EY auditor verified CABF BR compliance:
the OCSP responder doesn't reply to GET requests, so it's not BR compliant;
the example certificate (ssl.elektronicznypodpis.pl) is also not BR compliant (subject content is wrong, there's no SAN extension).

Comment 20

[Kathleen Wilson]

Przemyslaw, Please revoke the old intermediate certificate, and re-evaluate the SZAFIR ROOT CA in regards to the CA/Browser Forum's Baseline Requirements. Please also have the auditor re-evaluate in terms of the Baseline Requirements, and provide a BR audit statement.

BR audit statements that Ernst & Young has provided for other CAs may be found in the spreadsheet here:
http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/pending/

Comment 21

[certificates]

(In reply to Kathleen Wilson from comment #20)
> Przemyslaw, Please revoke the old intermediate certificate, and re-evaluate
> the SZAFIR ROOT CA in regards to the CA/Browser Forum's Baseline
> Requirements. Please also have the auditor re-evaluate in terms of the
> Baseline Requirements, and provide a BR audit statement.
> 
> BR audit statements that Ernst & Young has provided for other CAs may be
> found in the spreadsheet here:
> http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
> pending/


We filed an application for Mozilla Root Certificate Program in December 2012. When we started to run new ROOT CA, the only Mozilla requirement was to have WebTrust seal and we fulfilled this demand. Preparing our infrastructure we took an example from others existing CAs, which root's certificates were added to Mozilla's browser. After applying we received from you new requirements which were introduced after our application. As we checked not all of CA fulfilled CA/Browser Forum's Baseline Requirements and they still remain added to your browser.

Please let us know when other CA certificates which do not fulfill latest requirements will be revoked. We are not able to revoke our intermediate certificate as another CAs because we issued thousands valid certificates for our clients and we are not able to revoked them without good reason.

In our opinion you do not treat us fair and not on the par with other. We expect you to add us to the browser since we fulfilled all initial requirements, new requirements can be fulfilled at the later time only for new intermediate CA certificate.

Inspite of new versions of CA/Browser Forum's Baseline Requirements (sometimes occurring every two months) we are trying to fulfill them. The main problem was lack of CRL Distribution Point or OCSP URI in the intermediate CA certificate and we solved it by issuing new intermediate CA certificate. We can start to issue clients' certificates by new intermediate CA certificate after your acceptation and old clients' certificates issued by old intermediate CA certificate will expired naturally. After that we will revoke old intermediate CA certificate. Revoking existing intermediate CA certificate now is impossible because of business reasons.

We wolud like to note that our clients' certificates contains extensions  AIA (authorityInfromationAccess) oraz cRLDP (crl DistributionPoints).

Comment 22

[Kathleen Wilson]

(In reply to certificates from comment #21)

> We are not able to revoke our intermediate
> certificate as another CAs because we issued thousands valid certificates
> for our clients and we are not able to revoked them without good reason.

OK. 


> 
> In our opinion you do not treat us fair and not on the par with other. We
> expect you to add us to the browser since we fulfilled all initial
> requirements, new requirements can be fulfilled at the later time only for
> new intermediate CA certificate.


https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy



> 
> Inspite of new versions of CA/Browser Forum's Baseline Requirements
> (sometimes occurring every two months) we are trying to fulfill them. 

http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
"12. CA operations and issuance of certificates to be used for SSL-enabled servers must also conform to version 1.1.5 of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates."


> The
> main problem was lack of CRL Distribution Point or OCSP URI in the
> intermediate CA certificate and we solved it by issuing new intermediate CA
> certificate. We can start to issue clients' certificates by new intermediate
> CA certificate after your acceptation and old clients' certificates issued
> by old intermediate CA certificate will expired naturally. After that we
> will revoke old intermediate CA certificate. Revoking existing intermediate
> CA certificate now is impossible because of business reasons.


So, is your request to let the old certs expire naturally, but all new SSL certs will be compliant with the Baseline Requirements?

From what date forward will all new certs be complaint with Version 1.1.5 of the Baseline Requirements?


> 
> We wolud like to note that our clients' certificates contains extensions 
> AIA (authorityInfromationAccess) oraz cRLDP (crl DistributionPoints).


Are you saying that the OCSP issues per Comment #19 have been resolved?

Comment 23

[certificates]

(In reply to Kathleen Wilson from comment #22)

> So, is your request to let the old certs expire naturally, but all new SSL
> certs will be compliant with the Baseline Requirements?
> 
> From what date forward will all new certs be complaint with Version 1.1.5 of
> the Baseline Requirements?

Yes, all new SSL certs will be compliant with the Baseline Requirements.
We plan to start using new intermediate certificate to issuing SSL certificates for subscribers two weeks after your acceptance for this certificate.

 
> Are you saying that the OCSP issues per Comment #19 have been resolved?

We re-evaluate the SZAFIR ROOT CA in regards to the CA/Browser Forum's Baseline Requirements. We resolved problems with OCSP and changed the example certificate (ssl.elektronicznypodpis.pl). Now it is BR compliant(with SAN extension).

At this moment EY (auditor) is working on our annual audit and it will be done with re-evaluation in terms of the Baseline Requirements (version 1.1.5). We hope it will be finished soon with a BR audit statement.

Comment 24

[Kathleen Wilson]

Great! Please post a comment in this bug with the BR audit statement is available.

Comment 25

[certificates]

(In reply to Kathleen Wilson from comment #24)
> Great! Please post a comment in this bug with the BR audit statement is
> available.

BR audit statement is available here:

https://cert.webtrust.org/ViewSeal?id=1681

Please proceed to the next step as soon as possible.

Comment 26

[certificates]

Please, let us know about the next steps as soon as possible.

Comment 27

[Kathleen Wilson]

Attachment: Completed CA Information Document

Comment 28

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

In the meantime, please update this bug with your responses to the recent CA Communication,
https://wiki.mozilla.org/CA:Communications#May_13.2C_2014

Comment 29

[certificates]

Attachment: Response to CA Comunications (May 13, 2014).pdf

Please, find attached our response to recent CA communications. We are looking forward to start public discussion.

Comment 30

[certificates]

Attachment: SZAFIR_Trusted_CA.crt

Comment 31

[certificates]

Attachment: SZAFIR_Trusted_CA_2014.crt

Comment 32

[certificates]

Could you start our public discussion as soon as possible? We are ready from 2014.05.05.

Comment 33

[Kathleen Wilson]

We are discussing BR audits in the mozilla.dev.security.policy forum, due to problems that were found with the previous two root inclusion requests that are in discussion 
(https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion )

I plan to start the discussion for this request after those discussions are completed. In the meantime, I recommend that you see those discussions and carefully read the following wiki page and review it with your auditor:
https://wiki.mozilla.org/CA:BaselineRequirements

Comment 34

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #33)
>  In the meantime, I recommend that you see those discussions and
> carefully read the following wiki page and review it with your auditor:
> https://wiki.mozilla.org/CA:BaselineRequirements

Did you review that wiki page with your auditor?

Comment 35

[certificates]

In reply to Kathleen Wilson from comment #34)
> (In reply to Kathleen Wilson from comment #33)
> >  In the meantime, I recommend that you see those discussions and
> > carefully read the following wiki page and review it with your auditor:
> > https://wiki.mozilla.org/CA:BaselineRequirements
> 
> Did you review that wiki page with your auditor?

Yes, we did. When are you going to start public discussion?

Comment 36

[Kathleen Wilson]

I am now opening the first public discussion period for this request from KIR S.A. to include the “SZAFIR ROOT CA” root certificate and enable all three trust bits.

For a description of the public discussion phase, see 
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum 
http://www.mozilla.org/about/forums/#dev-security-policy

The discussion thread is called “KIR S.A. Root Inclusion Request”.

Please actively review, respond, and contribute to the discussion.

A representative of KIR S.A. must promptly respond directly in the discussion thread to all questions that are posted.

Comment 37

[Kathleen Wilson]

The following action items resulted from the first discussion.

Action Item #1: Update CPS to:
A) Clarify steps to confirm the certificate subscriber owns/controls the domain name to be included in the certificate.
B) Clarify that the same domain control verification is required for SSL Test Certificates. Or, a preferable solution would be that test certificates are not issued in this CA hierarchy.
C) Remove the text allowing for 4 hour OCSP downtime
D) Don’t allow certificate suspension for SSL certs
E) Clarify the maximum allowed validity for SSL certs. If it is up to 5 years, then add re-verificatin at least every 39 months, and note that after April 1, 2015 the BRs no longer allow for 5 year certs.
F) Clarify that archiving is required for 7 years.
G) Clarify that in SSL certificates the EKU can only have clientAuthentication and serverAuthentication.
H) Clarify plans regarding SHA-1

Action item #2: Update CRL according to one of the following options.
- include a critical IDP in your CRLs to limit their scope, or
- continue to produce full-scope CRLs and make sure that the CRLs produced by "SZAFIR Trusted CA"-2011 AND "SZAFIR Trusted CA"-2014 contain the same revocation information; that is, they both MUST revoke the certificates produced by "SZAFIR Trusted CA"-2011+2014, and take the CRLNumber from the same sequence. 

Please update this bug as you make progress on these action items.

When I have confirmed completion of the action items, I will start the second public discussion period for this request.

Comment 38

[certificates]

All actions were done. The new versions of CPS and CP were published under friendly links:

http://elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf
http://elektronicznypodpis.pl/files/doc/certification_policy.pdf

Action Item #1

A) Clarify steps to confirm the certificate subscriber owns/controls the domain name to be included in the certificate.

It was done in CPS in section 3.2.2 and in CP in section 2.4.
The process includes verification, whether the server or domain are held by the recipient of certification services.

Section 3.2.2
"If a certificate is to contain data on a recipient of certification services other than a natural person, such as a name of the organisation and its address, prior to issuance of a certificate on the basis of information obtained from legal and reliable, publicly available sources, including available registers maintained by public authorities, KIR S.A. shall check if such entity exists if data indicated by a recipient of certification services is compliant with that presented in the register used and if persons acting on behalf of the recipient of certification services are authorised to that. An address of the organisation may also be verified during a visit of an Operator of KIR S.A. at the registered seat of a recipient of certification services.
If a certificate is to provide for security of electronic mail, verification of the electronic mail address shall be done. Verification shall consist in checking if an electronic mail address indicated in the order belongs to the subscriber. Checking may be done by confirming that the subscriber has collected authentication data sent to an electronic mail address given in the order. Checking is to determine that the e-mail address is legally used by the subscriber.
If an SSL certificate and a test certificate is to contain a domain name, checking shall include if a recipient of certification services has the right to use the domain name and if the domain remains under its control. Verification performed by KIR S.A. shall comprise:
- checking in publicly available WHOIS services or directly with entities registering domains, if a recipient of certification services is registered as a domain owner or has the right to use the domain name;
- checking, if a response has been sent to an e-mail sent by KIR to the domain administrator to an e-mail address of the administrator domain containing webmaster, admin, administrator, hostmaster, postmster before @domena or an e-mail address indicated as the address for contacts for a specific domain in the WHOIS service or the register of domains;
- checking, if verification data indicated by KIR S.A. has been placed on a server or in a record such as TXT in DNS;
- in case of Wildcard Certificates checking if in the “public suffix list” (PSL) register http://publicsuffix.org/ (PSL), the sign “*” is not put in the first place on the left-hand side of the suffix of gTLD domains delegated by ICANN. KIR S.A. may issue a Wildcard Certificate for gTLD domains, if the subscriber properly proves its right to manage the entire space of names under the gTLD domain.
To minimise the risk of using inappropriate data KIR S.A. shall use data presented in the WHOIS service in combination with IANA data and the WHOIS data supplied by ICCAN approved entities that register domains.
If the identifier of the subscriber's certificate containing the domain name is to include a name of the country, too, then prior to issuing the certificate KIR S.A. shall verify if the indicated name of the country is connected to the subscriber. Verification shall be performed in accordance with one of the methods described below and consists in checking:
- if a domain IP address indicated in DNS is within the range of IP addresses assigned for a country for entering of which into the subscriber's identifier the recipient of certification services has applied;
- if the name of the country included in the information provided by an authority registering the domain whose name is to be placed in the certificate is compliant with the name of the country for entering of which into the subscriber's identifier the recipient of certification services has applied.
While verifying the name of the country KIR S.A shall check, if the recipient of certification services does not use a proxy server to substitute an IP address from another country in which it is actually located."

Section 2.4
(...)
"In the process of issuing this type of certificates the operator KIR S.A. shall verify the subscriber’s identity and its right to obtain a certificate. The process includes verification, whether the server or domain are held by the recipient of certification services."
(...)

B) Clarify that the same domain control verification is required for SSL Test Certificates. Or, a preferable solution would be that test certificates are not issued in this CA hierarchy.

It was done in CPS in section 3.2.2, 

Section 3.2.2
(...)
"If an SSL certificate and a test certificate is to contain a domain name, checking shall include if a recipient of certification services has the right to use the domain name and if the domain remains under its control. Verification performed by KIR S.A. shall comprise:"
(...)

C) Remove the text allowing for 4 hour OCSP downtime

It was done in section 4.9.9.

D) Don’t allow certificate suspension for SSL certs.

We do not allow suspension for SSL certs, now. We changed sections of our CPS: 4.9. and 4.9.11.

Section 4.9
"Each certificate may be revoked before expiry of its operational period. Certificate suspension is a special case of revocation however, it is not possible to suspend all types of certificates. SSL certificates and test certificates shall not be suspended. A certificate that has been suspended may then be revoked or unsuspended. A suspension period shall be used to clarify doubts concerning conditions for having certificate revoked or unsuspended. "
(...)

Section 4.9.11
"SSL certificates and test certificates shall not be suspended."

E) Clarify the maximum allowed validity for SSL certs. If it is up to 5 years, then add re-verificatin at least every 39 months, and note that after April 1, 2015 the BRs no longer allow for 5 year certs.

Maximum validity period of the certificate is now 3 years. Furthermore  renewal of the certificate may be done after prior identification and authentication of the subscriber and verification of data  using the same methods that were applied at the time of the issuance of the first certificate. It was clarified in table in CPS in section 6.3.2 and in 3.3.1.

Section 6.3.2
(...)Certificate of an Entity	Operational Period
SZAFIR ROOT CA	                   20 years
SZAFIR Trusted CA	           10 years
Subscriber	             maximum 3 years, excluding ELIXIR certificates for which operational period is maximum 2 years 
(...)

Section 3.3.1.

"Verification of data that is to be put in the certificate shall be done as described in Clause 3.2.2 and 3.2.3, for persons who are not natural persons and for natural persons, accordingly. 
Proving the ownership of a private key shall be done as described in Clause 3.2.1.
Before issuing a certificate to the subscriber or a person authorised to collect the certificate, KIR S.A. shall check:
· if it is a person indicated in the order by the recipient of certification services as a subscriber or a person authorised to collect the certificate;
· identity of such person on the basis of the identification document presented by it or on the basis of an electronic signature affixed in the request for certificate renewal verified with the use of a valid certificate issued by KIR S.A."
(...)

F) Clarify that archiving is required for 7 years.

All 5 years periods about archiving was chaneged to 7 years.


G) Clarify that in SSL certificates the EKU can only have clientAuthentication and serverAuthentication.

It was done in CPS in  csection 7.1 in the table in the row with extendedKeyUsage.

Section 7.1.
"extendedKeyUsage
(...) In case of SSL certificates it shall be permitted only as: clientAuthentication and serverAuthentication."


H) Clarify plans regarding SHA-1

Clarified in section 7.1.1.

Section 7.1.1.
(...)
"Certificates of the subscribers shall be issued for RSA keys having the length of 1024 bits or 2048 bits and SHA-1 or SHA-256 hash functions.
Beginning from 1 January 2016 all certificates issued by KIR S.A shall have an SHA-256 function."

Action Item #2

We included a critical IDP in our CRLs to limit their scope.

Comment 39

[Erwann Abalea]

(In reply to certificates from comment #38)
[...]
> Action Item #2
> 
> We included a critical IDP in our CRLs to limit their scope.

You also broke the monotonic characteristic of the CRLNumber integer. I kept different copies of the "trusted_ca_2013.crl" file:
 - one dated October 2 2014, with CRLNumber=2860, 2 revoked certificates
 - one dated October 6 2014, with CRLNumber=2867, AKI is present, the same 2 revoked certificates
 - one dated November 19 2014, with CRLNumber=2512, AKI and critical IDP are present, no revoked certificates

Requesting the corresponding OCSP server for the 2 serial numbers that were previously declared revoked, OCSP responder replies with a "revoked" answer.

I hadn't checked earlier, but you claimed in public discussion (in an October 8 post) that the certificate associated to https://revoked.elektronicznypodpis.pl is correctly detected as revoked by IE. This certificate is not expired, its serial number isn't present in the CRL, and OCSP responder replies with a revoked answer, which isn't consistent. An attacker could block access to your OCSP responder, IE then falls back to CRL downloading, and the certificate becomes valid.

You still have serious problems with revocation information. This has a negative impact for your users, and revoked certificates can't be detected by Google CRLSet or the future Mozilla OneCRL.

Comment 40

[certificates]

(In reply to Erwann Abalea from comment #39)
> (In reply to certificates from comment #38)
> [...]
> > Action Item #2
> > 
> > We included a critical IDP in our CRLs to limit their scope.
> 
> You also broke the monotonic characteristic of the CRLNumber integer. I kept
> different copies of the "trusted_ca_2013.crl" file:
>  - one dated October 2 2014, with CRLNumber=2860, 2 revoked certificates
>  - one dated October 6 2014, with CRLNumber=2867, AKI is present, the same 2
> revoked certificates
>  - one dated November 19 2014, with CRLNumber=2512, AKI and critical IDP are
> present, no revoked certificates
> 
> Requesting the corresponding OCSP server for the 2 serial numbers that were
> previously declared revoked, OCSP responder replies with a "revoked" answer.
> 
> I hadn't checked earlier, but you claimed in public discussion (in an
> October 8 post) that the certificate associated to
> https://revoked.elektronicznypodpis.pl is correctly detected as revoked by
> IE. This certificate is not expired, its serial number isn't present in the
> CRL, and OCSP responder replies with a revoked answer, which isn't
> consistent. An attacker could block access to your OCSP responder, IE then
> falls back to CRL downloading, and the certificate becomes valid.
> 
> You still have serious problems with revocation information. This has a
> negative impact for your users, and revoked certificates can't be detected
> by Google CRLSet or the future Mozilla OneCRL.

We started publishing CRL with AKI and IDP http://cdp.elektronicznypodpis.pl/trusted_ca_2013.crl since the 5th of November. These CRLs are dedicated only for certificates with cRLDistribuitionPoints  http://cdp.elektronicznypodpis.pl/trusted_ca_2013.crl . 
These CRLs have their own monotonic numeration, as they have a different scope. But still these are different CRLs – the CRLs previously published were for the whole scope of certificates, the CRLs published now are for certificates with the given IDP.
The CRL with none revoked certs you got was our mistake in publishing. By mistake we published CRL for a different IDP. But this problem was fixed. 
OCSP based on CA data base, not on CRLs. 
To summarize:
-	Now we publish CRL with IDP 
-	OCSP based on CA data base not on CRLs

Comment 41

[certificates]

Please, let us know when you plan to start Second Public Discussion.

Comment 42

[Kathleen Wilson]

(In reply to certificates from comment #38)
> All actions were done. The new versions of CPS and CP were published under
> friendly links:
> 
> http://elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf
> http://elektronicznypodpis.pl/files/doc/certification_policy.pdf
> 


I'm not able to download the documents using these links. Please double-check that they are working.

I've tried to download them from here too: http://eng.elektronicznypodpis.pl/en/information/documents-and-agreements
I can download other pdf files from that page, but not the Certification Policies documents.

Comment 43

[certificates]

Recently, our company has changed corporate website and we have had temporary problems with friendly links. They work now properly. Please, use them again.

Comment 44

[Kathleen Wilson]

(In reply to certificates from comment #38)
> All actions were done. The new versions of CPS and CP were published under
> friendly links:
> 
> http://elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf
> http://elektronicznypodpis.pl/files/doc/certification_policy.pdf
> 

I confirm that the CP and CPS have been updated to reflect the stated changes.

However, I am concerned about the following:
> 
> Section 7.1.1.
> (...)
> "Certificates of the subscribers shall be issued for RSA keys having the
> length of 1024 bits or 2048 bits and SHA-1 or SHA-256 hash functions.

According to the Baseline Requirements Appendix A, 1024-bit certificates should no longer be issued.

Comment 45

[certificates]

(In reply to Kathleen Wilson from comment #44)
> (In reply to certificates from comment #38)
> > All actions were done. The new versions of CPS and CP were published under
> > friendly links:
> > 
> > http://elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf
> > http://elektronicznypodpis.pl/files/doc/certification_policy.pdf
> > 
> 
> I confirm that the CP and CPS have been updated to reflect the stated
> changes.
> 
> However, I am concerned about the following:
> > 
> > Section 7.1.1.
> > (...)
> > "Certificates of the subscribers shall be issued for RSA keys having the
> > length of 1024 bits or 2048 bits and SHA-1 or SHA-256 hash functions.
> 
> According to the Baseline Requirements Appendix A, 1024-bit certificates
> should no longer be issued.

As it is pointed in Section 6.1.5. of CPS SSL certificates are issued for 2048 bit RSA keys.  1024 bit RSA keys are only used in ELIXIR certificates.

Comment 46

[Erwann Abalea]

(In reply to certificates from comment #45)
> (In reply to Kathleen Wilson from comment #44)
> > (In reply to certificates from comment #38)
> > > All actions were done. The new versions of CPS and CP were published under
> > > friendly links:
> > > 
> > > http://elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf
> > > http://elektronicznypodpis.pl/files/doc/certification_policy.pdf
> > > 
> > 
> > I confirm that the CP and CPS have been updated to reflect the stated
> > changes.
> > 
> > However, I am concerned about the following:
> > > 
> > > Section 7.1.1.
> > > (...)
> > > "Certificates of the subscribers shall be issued for RSA keys having the
> > > length of 1024 bits or 2048 bits and SHA-1 or SHA-256 hash functions.
> > 
> > According to the Baseline Requirements Appendix A, 1024-bit certificates
> > should no longer be issued.
> 
> As it is pointed in Section 6.1.5. of CPS SSL certificates are issued for
> 2048 bit RSA keys.  1024 bit RSA keys are only used in ELIXIR certificates.

CP section 2.6 presents ELIXIR certificates, but this definition seems to allow ELIXIR certificates to be TLS server certificates.
I haven't found an ELIXIR certificate so far, nor a precise profile of such a certificate. Can an ELIXIR certificate have either one of these characteristics:
 - presence of an EKU extension with either serverAuth or anyExtendedKeyUsage OID
 - absence of the EKU extension

Comment 47

[certificates]

(In reply to Erwann Abalea from comment #46)
> (In reply to certificates from comment #45)
> > (In reply to Kathleen Wilson from comment #44)
> > > (In reply to certificates from comment #38)
> > > > All actions were done. The new versions of CPS and CP were published under
> > > > friendly links:
> > > > 
> > > > http://elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf
> > > > http://elektronicznypodpis.pl/files/doc/certification_policy.pdf
> > > > 
> > > 
> > > I confirm that the CP and CPS have been updated to reflect the stated
> > > changes.
> > > 
> > > However, I am concerned about the following:
> > > > 
> > > > Section 7.1.1.
> > > > (...)
> > > > "Certificates of the subscribers shall be issued for RSA keys having the
> > > > length of 1024 bits or 2048 bits and SHA-1 or SHA-256 hash functions.
> > > 
> > > According to the Baseline Requirements Appendix A, 1024-bit certificates
> > > should no longer be issued.
> > 
> > As it is pointed in Section 6.1.5. of CPS SSL certificates are issued for
> > 2048 bit RSA keys.  1024 bit RSA keys are only used in ELIXIR certificates.
> 
> CP section 2.6 presents ELIXIR certificates, but this definition seems to
> allow ELIXIR certificates to be TLS server certificates.
> I haven't found an ELIXIR certificate so far, nor a precise profile of such
> a certificate. Can an ELIXIR certificate have either one of these
> characteristics:
>  - presence of an EKU extension with either serverAuth or
> anyExtendedKeyUsage OID
>  - absence of the EKU extension

ELIXIR Certificates have no EKU extension. They are used to sign and encrypt transactions exchanged in clearing system operated by KIR. There is no server authetication. These certificates are issued to banks' operators.

Comment 48

[Kathleen Wilson]

(In reply to certificates from comment #47)
> ELIXIR Certificates have no EKU extension. They are used to sign and encrypt
> transactions exchanged in clearing system operated by KIR. There is no
> server authetication. These certificates are issued to banks' operators.

I looked into this to confirm my understanding. So here's the answer...

Currently a certificate with no EKU extension will be accepted as a valid SSL cert. So the ELIXIR certs could be used as SSL certs in Firefox if this root cert were included with the Websites trust bit enabled (and the intermediate cert not technically constrained as described in Mozilla policy).

I think the ways to move forward would be:

1) Continue with this root inclusion request, but without turning on the Websites trust bit. So only the email and code signing trust bits would be requested.

2) Request inclusion of a new root whose CA hierarchy does not include ELIXIR, that can be used for SSL certificate issuance. This could be added to the current request (though auditing,etc. would be needed), or could be done in a separate request later.

Comment 49

[certificates]

(In reply to Kathleen Wilson from comment #48)
> (In reply to certificates from comment #47)
> > ELIXIR Certificates have no EKU extension. They are used to sign and encrypt
> > transactions exchanged in clearing system operated by KIR. There is no
> > server authetication. These certificates are issued to banks' operators.
> 
> I looked into this to confirm my understanding. So here's the answer...
> 
> Currently a certificate with no EKU extension will be accepted as a valid
> SSL cert. So the ELIXIR certs could be used as SSL certs in Firefox if this
> root cert were included with the Websites trust bit enabled (and the
> intermediate cert not technically constrained as described in Mozilla
> policy).
> 
> I think the ways to move forward would be:
> 
> 1) Continue with this root inclusion request, but without turning on the
> Websites trust bit. So only the email and code signing trust bits would be
> requested.
> 
> 2) Request inclusion of a new root whose CA hierarchy does not include
> ELIXIR, that can be used for SSL certificate issuance. This could be added
> to the current request (though auditing,etc. would be needed), or could be
> done in a separate request later.

BR in Appendix B pointed that:
(3) F. extKeyUsage (required)
Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280] or both values MUST be present. id-kp-emailProtection [RFC5280] MAY be present. Other values SHOULD NOT be present.

Moreover BR Section 9.2.1 requires Subject Alternative Name Extension with either a dNSName containing the
Fully-Qualified Domain Name or an iPAddress containing the IP address of a server.

So a certificate with no EKU extension and no FQDN or IP address in subjectAltName shouldn’t be accepted as a valid SSL.

Earlier question was: 
> Can an ELIXIR certificate have either one of these characteristics:
>  - presence of an EKU extension with either serverAuth or anyExtendedKeyUsage OID
>  - absence of the EKU extension.

We confirmed that ELIXIR certs:
- have no EKU extension 
- are not for server authentication
- are issued for a limited number of users.

These certs have their own Certificate Policy Identifier and have no Fully-Qualified Domain Name and iPAddress in subjectAltName. These characteristics distinguish them from SSL certs.

We can add EKU extension with value id-kp-clientAuth to ELIXIR if this solves the problem.

Comment 50

[Kathleen Wilson]

(In reply to certificates from comment #49)
> 
> We can add EKU extension with value id-kp-clientAuth to ELIXIR if this
> solves the problem.


Yes, that would solve the problem.

How long are the previously issued ELIXIR certs valid for?

Comment 51

[certificates]

(In reply to Kathleen Wilson from comment #50)
> (In reply to certificates from comment #49)
> > 
> > We can add EKU extension with value id-kp-clientAuth to ELIXIR if this
> > solves the problem.
> 
> 
> Yes, that would solve the problem.
> 
> How long are the previously issued ELIXIR certs valid for?

The Elixir certs are valid for maximum 2 years.

Comment 52

[Kathleen Wilson]

Can you do a test to make sure that Firefox shows an error if someone tries to use a current Elixir cert as an SSL cert? Hopefully you will confirm that Firefox shows the domain mismatch error (which can be overridden, so it's not ideal, but I think would be OK).

As long as the current Elixir certs would cause an error in Firefox if they are used as an SSL cert, then I think we can proceed with having all future Elixir certs include the EKU extension with value id-kp-clientAuth.

Comment 53

[certificates]

(In reply to Kathleen Wilson from comment #52)
> Can you do a test to make sure that Firefox shows an error if someone tries
> to use a current Elixir cert as an SSL cert? Hopefully you will confirm that
> Firefox shows the domain mismatch error (which can be overridden, so it's
> not ideal, but I think would be OK).
> 
> As long as the current Elixir certs would cause an error in Firefox if they
> are used as an SSL cert, then I think we can proceed with having all future
> Elixir certs include the EKU extension with value id-kp-clientAuth.

We did a test with Elixir cert. Firefox shows an error: ssl_error_bad_cert_domain. We installed the Elixir cert on our test web page https://ssl.elektronicznypodpis.pl/ for a while, so you can check it.

Comment 54

[Kathleen Wilson]

(In reply to certificates from comment #53)

Thanks for doing the test. I think we can proceed with having all future Elixir certs include the EKU extension with value id-kp-clientAuth. Will you be updating the CPS to reflect this? When do you think this change will be in place?

Comment 55

[certificates]

(In reply to Kathleen Wilson from comment #54)
> (In reply to certificates from comment #53)
> 
> Thanks for doing the test. I think we can proceed with having all future
> Elixir certs include the EKU extension with value id-kp-clientAuth. Will you
> be updating the CPS to reflect this? When do you think this change will be
> in place?

We will start to issue all Elixir certs including the EKU extension with value id-kp-clientAuth from the 15th of February. We will update our CPS to reflect this. It will be valid from the same date.

Comment 56

[Kathleen Wilson]

Attachment: 817994-CAInformation.pdf

I have entered the information for this request into SalesForce. Please review the attached document for accuracy and completeness.

Comment 57

[Kathleen Wilson]

Please also attach the intermediate certificates that we should add to OneCRL.

Comment 58

[certificates]

Attachment: intermediate certificate

The information is complete and accurate. The only thing is that our auditor changed its name to EY.

Comment 59

[Kathleen Wilson]

I am now opening the second public discussion period for this request from KIR S.A. to include the “SZAFIR ROOT CA” root certificate and enable all three trust bits.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum 
http://www.mozilla.org/about/forums/#dev-security-policy

The discussion thread is called “Second Discussion of KIR S.A. Root Inclusion Request”.

Please actively review, respond, and contribute to the discussion.

A representative of KIR must promptly respond directly in the discussion thread to all questions that are posted.

Comment 60

[certificates]

Please find enclosed our current 2015 certificate authority audit.

https://cert.webtrust.org/ViewSeal?id=1845

Comment 61

[Kathleen Wilson]

The public comment period for this request is now over.

This request has been evaluated as per Mozilla’s CA Certificate Inclusion Policy at
https://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/
Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

Inclusion Policy Section 4 [Technical].
I am not aware of instances where Krajowa Izba Rozliczeniowa S.A. (KIR) has knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug.

Inclusion Policy Section 6 [Relevance and Policy].
KIR appears to provide a service relevant to Mozilla users. It is the one of the biggest Polish CAs, and currently mainly issues qualified certificates for general public. KIR is automated clearing house in Poland, and has built numerous business relationships within banking sector. KIR is aiming to expand its sales in services like SSL or VPN certificates. KIR has another line of products called PayByNet, has created a vast network of relationships within online stores and KIR S.A can leverage them to create customer base for trusted non-qualified certificates.

KIR has requested to include the following root certificate.
	 
Root Certificate Name: SZAFIR ROOT CA
O From Issuer Field: Krajowa Izba Rozliczeniowa S.A.
Trust Bits: Code; Email; Websites
EV Policy OID: Not requesting EV treatment
Root Cert Download URL: http://www.elektronicznypodpis.pl/certyfikaty/root_ca.crt

The primary documents, the CP and CPS, are provided in both English and Polish. 
Polish: http://www.elektronicznypodpis.pl/informacje/podstawy-prawne/
English: http://eng.elektronicznypodpis.pl/en/information/documents-and-agreements
CP: http://elektronicznypodpis.pl/files/doc/certification_policy.pdf
CPS: http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf

Certificate Revocation
CRL URL(s): http://cdp.elektronicznypodpis.pl/root_ca.crl
http://cdp.elektronicznypodpis.pl/trusted_ca_2013.crl
OCSP URL(s): http://ocsp.elektronicznypodpis.pl

Inclusion Policy Section 7 [Validation]. 
KIR appears to meet the minimum requirements for subscriber verification, as follows:

* SSL Verification: According to CPS section 3.2.2: If an SSL certificate and a test certificate is to contain a domain name, checking shall include if a recipient of certification services has the right to use the domain name and if the domain remains under its control. Verification performed by KIR S.A. shall comprise:
- checking in publicly available WHOIS services or directly with entities registering domains, if a recipient of certification services is registered as a domain owner or has the right to use the domain name;
- checking, if a response has been sent to an e-mail sent by KIR to the domain administrator to an e-mail address of the administrator domain containing webmaster, admin, administrator, hostmaster, postmster before @domena or an e-mail address indicated as the address for contacts for a specific domain in the WHOIS service or the register of domains;
- checking, if verification data indicated by KIR S.A. has been placed on a server or in a record such as TXT in DNS;
- in case of Wildcard Certificates checking if in the “public suffix list” (PSL) register http://publicsuffix.org/ (PSL), the sign “*” is not put in the first place on the left-hand side of the suffix of gTLD domains delegated by ICANN. KIR S.A. may issue a Wildcard Certificate for gTLD domains, if the subscriber properly proves its right to manage the entire space of names under the gTLD domain.
** CP section 2.5: Test certificate -- These certificates are used for checking co-operation with the system or the subscriber's IT solution.
In the process of issuing this type of certificates the operator KIR S.A. shall verify the subscriber's right to obtain such certificate. In case, when test certificate is to serve to examine the possibility of setting up secure connections, then process includes also verification, if www server or domain are at the disposal of recipient of certification services. 

* Email Verification: Ownership/control of email address to be included in the certificate is demonstrated via an email challenge-response mechanism.
CPS section 3.2.2: If a certificate is to provide for security of electronic mail, verification of the electronic mail address shall be done. Verification shall consist in checking if an electronic mail address indicated in the order belongs to the subscriber. Checking may be done by confirming that the subscriber has collected authentication data sent to an electronic mail address given in the order. Checking is to determine that the e-mail address is legally used by the subscriber.

* Code Signing Subscriber Verification: According to CP section 2.2 KIR verifies the subscriber’s identity and the right to obtain the code signing certificate and confirms the reliability of the data entered into the certificate.

Inclusion Policy Sections 11-14 [Audit]. 
Annual audits are performed by EY, according to the WebTrust criteria.
WebTrust CA and BR: https://cert.webtrust.org/SealFile?seal=1845&file=pdf

Inclusion Policy Section 18 [Certificate Hierarchy]
There is currently one internally-operated subCA which issues 6 types of end-user certificates:
- Standard -- e-mail, for authorizing access to systems, signing and encrypting data in an electronic forms and authenticating subscribers.
- Code signing
- VPN
- SSL
- Test
- ELIXIR -- as of Feb 15 new Elixir certs include the EKU extension with value id-kp-clientAuth
Externally Operated SubCAs: None
Cross Signing: None

Based on this assessment I intend to approve this request from KIR to include the "SZAFIR ROOT CA" root certificate and enable all three trust bits.

Comment 62

[Kathleen Wilson]

As per the summary in Comment #61, and on behalf of Mozilla I approve this request from Krajowa Izba Rozliczeniowa S.A. (KIR) to include the following root certificate:

** "SZAFIR ROOT CA" (websites, email, code signing)

I will file the NSS bug for the approved changes.

Comment 63

[Kathleen Wilson]

I have filed bug #1157375 against NSS for the actual changes.

Comment 64

[certificates]

Attachment: SZAFIR ROOT CA2

The new root and test websites are ready:

https://ssl.elektronicznypodpis.pl/
https://revoked.elektronicznypodpis.pl/
https://expired.elektronicznypodpis.pl/

Please, let us know about next steps.

Comment 65

[certificates]

Attachment: SZAFIR Trusted CA2_KIR_2015.crt

And also the intermediate certificate.

Comment 66

[Kathleen Wilson]

I was testing with the new cert, and noticed
https://certificate.revocationcheck.com/ssl.elektronicznypodpis.pl
lists the error: Response is not yet valid 
in the OCSP Get and Post sections

Comment 67

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #66)
> I was testing with the new cert, and noticed
> https://certificate.revocationcheck.com/ssl.elektronicznypodpis.pl
> lists the error: Response is not yet valid 
> in the OCSP Get and Post sections

This is because the server doesn't return a Date header that is used to check the response. 
https://tools.ietf.org/html/rfc7231#section-7.1.1.2

Comment 68

[Erwann Abalea]

(In reply to Kathleen Wilson from comment #67)
> (In reply to Kathleen Wilson from comment #66)
> > I was testing with the new cert, and noticed
> > https://certificate.revocationcheck.com/ssl.elektronicznypodpis.pl
> > lists the error: Response is not yet valid 
> > in the OCSP Get and Post sections
> 
> This is because the server doesn't return a Date header that is used to
> check the response. 
> https://tools.ietf.org/html/rfc7231#section-7.1.1.2

May I suggest a problem at revocationcheck.com level?
The OCSP answer is correct, valid for 1 hour starting at the exact now().
The Date header in the HTTP response with the GET request is missing but isn't mandatory (a stapled OCSP response wouldn't have it either).
The Date header in the HTTP response with the POST request is missing, as are any other headers (Cache-control, Expires, etc), and revocationcheck.com still says the response isn't yet valid but hasn't expired either.

That said, these OCSP responses have really aggressive validity times. The start date is the now() of the OCSP signer, it's valid only for an hour, so recipients with a non synchronized clock may well be outside of these time boundaries and either declare the response not yet valid or expired. I think this is what's happening with revocationcheck.com.

Another problem in the server certificate is the encoding of the CN (T61String), and 4 '0x1f' (Unit Separator) characters appended in the CN. The T61String encoding is a thing of the past, the corresponding standard (T.61) has been removed between 1988 and 1993.

Comment 69

[certificates]

We fixed these problems. We added missing header and also changed the server certificate.

Comment 70

[Kathleen Wilson]

I updated the discussion thread regarding information about the regenerated root cert:
https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/jB-lp2OGCwAJ

Comment 71

[Kathleen Wilson]

Attachment: 817994-CAInformation-UpdatedRoot.pdf

Updated CA Information document to reflect new root.

Note that we are no longer enabling the Code Signing trust bit, because we will be removing the Code Signing trust bit from Mozilla's CA Cert Policy.
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Changes_Made_to_DRAFT_Version_2.3

Comment 72

[Kathleen Wilson]

(In reply to Kathleen Wilson from comment #70)
> I updated the discussion thread regarding information about the regenerated
> root cert:
> https://groups.google.com/d/msg/mozilla.dev.security.policy/aTN3lkAt0HM/jB-
> lp2OGCwAJ

No concerns were raised, so I have updated Bug #1157375 with the data for the replacement root cert.