Re: KIR S.A. Root Inclusion Request
On 10/22/14, 4:02 PM, Kathleen Wilson wrote: On 9/23/14 5:49 PM, Kathleen Wilson wrote: Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the “SZAFIR ROOT CA” root certificate and enable all three trust bits. Thanks to all of you who have contributed to this discussion. To summarize the discussion so far, KIR has action items to update their CPS and CRLs. 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. Did I miss anything? Are there any further questions or comments for KIR before they update their CPS? Thanks, Kathleen Thanks again to all of you who contributed to this discussion. I am now closing this discussion, and I will track the action items in the bug. Any further follow-up should be added directly to the bug. https://bugzilla.mozilla.org/show_bug.cgi?id=817994 When I have confirmed completion of the action items, I will start a new discussion thread. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Re: Re: KIR S.A. Root Inclusion Request
W dniu czwartek, 9 października 2014 02:12:47 UTC+2 użytkownik Erwann Abalea napisał: Bonsoir, Le mardi 7 octobre 2014 13:20:48 UTC+2, siuda...@gmail.com a écrit : W dniu wtorek, 7 października 2014 00:19:39 UTC+2 użytkownik Erwann Abalea napisał: I agree that AKI is not a way to limit scope of CRL. Good. The problem you noticed concerns building cert path during validation CRL (because CA and CRL are identified by name). Do you think that more applications and browsers are recognizing IDP (and matching between CDP/IDP) than AKI ?? There is no security hole in KIR scanario, because, even if someone will substitute CRL, it will be not verified by higher level CA (wrong signature). CA's duty is to produce signed elements (certificates and CRLs) according to RFC5280. RP's duty is to verify those signed elements according to the same standard. Don't mix the two and lower CA's behaviour because you assert that your RP will reduce their checks. We have to also remember that AKI must be included in CRL, use od IDP is optional. IDP is not optional in KIR scenario, and AKI offers no support here. I reproduced a test-case similar to KIR's scenario: - root CA cert and empty CRL - sub CA generation1 and generation2 (those are the 2 certificates for the same CA, with the same name, they only differ by their keys) - sub CA generation1 delivers a certificates for an EE and revokes it, produces a CRL (with AKI) containing this certificate - sub CA generation2 produces an empty CRL (with AKI) - EE signs a message - a relying party tries to validate this message, with complete path validation and CRL checks If the relying party is given the CRL produced by Sub CA generation1, the validation fails (certificate is revoked). If the relying party is given the CRL produced by Sub CA generation2, the validation passes. AKIs are followed, RFC5280 validation path is followed. The relying party software is OpenSSL, which is included in nearly every Linux distrib, along with Mozilla Root CA certificates. The sample signed message is at https://kouettland.com/SZAFIR/test.eml Trust store generation1 is at https://kouettland.com/SZAFIR/verifier1.cacrt Trust store generation2 is at https://kouettland.com/SZAFIR/verifier2.cacrt Run openssl cms -verify -CAfile verifier1.cacrt -crl_check -crl_check_all -extended_crl -in test.eml or openssl cms -verify -CAfile verifier2.cacrt -crl_check -crl_check_all -extended_crl -in test.eml and compare the results. Issuing different complete CRLs for the same scope is a security risk, whatever the key used to sign the CRL. Erwann, I appreciate your input, but: 1.OpenSSL cant be treated as reference application, as an oracle... OpenSSL doesnt support AKI in CRL. Are you sure that will it support IDP ?? What can we found on OpenSSL site: http://www.openssl.org/docs/apps/cms.html# in section Bugs: No revocation checking is done on the signer's certificate... Check this...Maybe it is not working as it should ? 2. I know, Openssl is great set of crypto primitives, and is in linux dist, but in reality - it means nothing... Mozilla uses its own set of cryptolibraries - JSS/NSS, they dont uses openssl Redhat in their CA and PKI services, dont uses openssl - they uses Mozilla NSS/JSS . They all supports AKI. Moreover, browsers also doesnt have any problem with correct validation KIR certs and CRL 3. KIR scenario, is encountered also in Microsoft PKI, this was also issue in Apache MOD SSL: https://issues.apache.org/bugzilla/show_bug.cgi?id=45708 In this scenario, you also objected against AKI, but Apache solved this bug, using AKI, like KIR want. Microsoft also uses AKI, not IDP. So - rfc5280 says one thing, market revised it and uses AKI, and only AKI. 4. Lets consider OCSP - all responders uses CRL as backbone. What we have in OCSP request? AKI. IDP is completely useless. 5. RFC5280, 6.3 CRL validation -read it..- conforming implementations that support CRL are not required to implement this algorithm... 6. I respect standards, but they should serve the market,not in opposite way. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Re: Re: KIR S.A. Root Inclusion Request
W dniu wtorek, 7 października 2014 00:19:39 UTC+2 użytkownik Erwann Abalea
napisał:
Bonsoir,
Le lundi 6 octobre 2014 15:55:24 UTC+2, Certificates a écrit :
Thank you for your clarifications. We analysed it, and we add Authority
Key Identifier extension to our CRLs. As it it mentioned in s. 5.2.1 RFC
5280 this extension is especially useful where an issuer has more than
one signing key, either due to multiple concurrent key pairs or due to
changeover. We based the value of this extension on issuer name and
serial number. We checked that GoDaddy distinguishes CRLs in the same way.
The CRL for the newer CA certificate is available now here
http://www.elektronicznypodpis.pl/crl/trusted_ca_2013.crl. CRL for the
elder CA certificate will be available tomorrow.
Please read X.509 or RFC5280 again. AKI is not a way to limit the scope of
the CRL. AKI is not to be set as a critical extension. AKI is only a helper
so the RP can avoid guessing which key signed this object. The RP has
absolutely no obligation to follow this helper.
The ONLY RFC5280-compatible extension to reduce the scope of a CRL is the
IssuingDistributionPoint.
GoDaddy distinguishes the CRLs not by their AKI, but by the
IssuingDistributionPoint extension, and this extension MUST be critical for
its goal to be achieved. BTW, the AKI extension of such partitioned CRLs at
GoDaddy is identical on all the CRLs (I checked
http://crl.godaddy.com/gds2-{1,...,17}.crl).
Erwann,
I agree that AKI is not a way to limit scope of CRL.
The problem you noticed concerns building cert path during validation CRL
(because CA and CRL are identified by name). Do you think that more
applications and browsers are recognizing IDP (and matching between CDP/IDP)
than AKI ?? There is no security hole in KIR scanario, because, even if someone
will substitute CRL, it will be not verified by higher level CA (wrong
signature).
We have to also remember that AKI must be included in CRL, use od IDP is
optional.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: KIR S.A. Root Inclusion Request
Le vendredi 3 octobre 2014 10:22:06 UTC+2, Kurt Roeckx a écrit : On 2014-10-02 18:53, Erwann Abalea wrote: Yet, 2 different and incompatible CRLs from the same issuer exist: [...] The CRLNumber numbering has been restarted from 1, and the revoked certificates list is different. This is a security problem, and is non compliant to X.509 and RFC5280. An attacker can replace one CRL by another, it will be accepted by a compliant application. This is similar to the PKITS test 4.4.19 (Valid Separate Certificate and CRL Keys Test19). At least godaddy is doing this too, they have over 100 CRLs covering the same CA that don't contain the same revoked serial numbers each having it's own counter, each still updated. The certificates point to 1 of them. For GoDaddy, the CRLs are limited in their scope, each of these CRLs has a critical IssuingDistributionPoint extension. That way, nobody can replace ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: KIR S.A. Root Inclusion Request
Sorry, left hand kicked the tab key, don't remember what the right hand did but it sent the mail... Continuing it. Le vendredi 3 octobre 2014 19:27:06 UTC+2, Erwann Abalea a écrit : Le vendredi 3 octobre 2014 10:22:06 UTC+2, Kurt Roeckx a écrit : On 2014-10-02 18:53, Erwann Abalea wrote: Yet, 2 different and incompatible CRLs from the same issuer exist: [...] The CRLNumber numbering has been restarted from 1, and the revoked certificates list is different. This is a security problem, and is non compliant to X.509 and RFC5280. An attacker can replace one CRL by another, it will be accepted by a compliant application. This is similar to the PKITS test 4.4.19 (Valid Separate Certificate and CRL Keys Test19). At least godaddy is doing this too, they have over 100 CRLs covering the same CA that don't contain the same revoked serial numbers each having it's own counter, each still updated. The certificates point to 1 of them. For GoDaddy, the CRLs are limited in their scope, each of these CRLs has a critical IssuingDistributionPoint extension. That way, nobody can replace gds2-17.crl with gds2-18.crl, because the RP will have to check that the CRLDP extension in the certificate matches with the IDP extension in the CRL. There's nothing similar here for SZAKIR. The 2 CRLs are full scope CRLs from the same issuer, with 2 different contents. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ODP: Re: ODP: Re: KIR S.A. Root Inclusion Request
On Tue, Sep 30, 2014 at 01:17:22PM +0200, Certificates wrote: We are able to add some additional information to our CPS. In our opinion they should be more general than those in our explanations sent to you. More detailed information are placed in our internal procedures, which are checked by auditors. Frankly, I don't have a particularly high opinion of the quality of the job that auditors do on CAs. The CPS is a Certification *Practice* Statement, not a Certification *Principles* Statement, and so I think it is reasonable to expect a description of the practices undertaken in issuing certificates. If you believe otherwise, and you're right, then the rest of the members of this list will presumably be in support your application and you'll be accepted into the trust store. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ODP: Re: ODP: Re: KIR S.A. Root Inclusion Request
On 9/30/14, 1:40 PM, Matt Palmer wrote: The CPS is a Certification *Practice* Statement, not a Certification *Principles* Statement, and so I think it is reasonable to expect a description of the practices undertaken in issuing certificates. Matt is correct. BR section 8.2.1 says: The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. https://wiki.mozilla.org/CA:BaselineRequirements#CA_Conformance_to_the_BRs The CA's CP/CPS must include a reasonable description of the ways the CA can verify that the certificate subscriber owns/controls the domain name(s) to be included in the certificate. The more information in the CP/CPS, the better. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
ODP: Re: KIR S.A. Root Inclusion Request
On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): That's presumably supposed to be CPS, not CSP (I noted that error frequently throughout the documents themselves; you might want to get that corrected). KIR's answer: OK, we'll check it. -agreement, -order, -document confirming rights to the domain . What valid forms can this document take? What steps are taken to verify or validate that information? KIR's answer: 1. Verification of agreement is done by checking if the company exist or not. We check it at the public registers, for example for companies registered in Poland we check it in register provide by Polish Ministry of Justice and Central Registration and Information of Business( https://ems.ms.gov.pl/krs/wyszukiwaniepodmiotu?t:lb=t, https://prod.ceidg.gov.pl/CEIDG/CEIDG.Public.UI/Search.aspx). Based on this information we checked if the person who sign agreement and order is entitled representative (if the company is in the register, there are also information who is entitled representative). 2. To verify an order we do validation in the same way as for the agreement and also we check if the data given in order are correct, e.g. if the data given in the order concerns the company which signed the agreement. Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4): 1. verification of agreement (we check if the company exist, who sign agreement, if it is entitled representative), 2. verification of order (we check who sign order, if it is entitled representative, if the data given in order are correct), 3. verification whether the client has granted the right to the domain (we check who is an owner of the domain); How is that ownership check performed? KIR's answer: For the domain name specified in the order we check at http://www.dns.pl/cgi-bin/whois.pl whether the data presented to the domain owner are the same as customer data and the data for the certificate indicated in the order and agreement. If they are the same operator asks the administrator of the domain to place unique identification code supplied by KIR on the server. If the code is placed correctly KIR's operator confirms that order is valid and lets to issue certificate. He also makes a note in our internal system about how he checked validity of the ownership of the given domain. 4. verification whether the client controls the domain (we ask to place data indicated by KIR on server); 5. identity of person authorised to represent client (we meet face to face with that person). If it is still unclear in CSP we can make it more clarified. That would be appreciated. KIR's answer: OK Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. KIR's answer: When issuing test certificate, we check the points 1 -4 listed above, and the validy of the renewed certifcate. That would be a good clarification to place in the CPS itself. KIR's answer: OK - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy Od: Matt Palmer mpal...@hezmatt.org Do: dev-security-policy@lists.mozilla.org, Data: 2014-09-26 22:45 Temat: Re: KIR S.A. Root Inclusion Request Wysłane przez: dev-security-policy dev-security-policy-bounces+certificates=kir.com...@lists.mozilla.org On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): That's presumably supposed to be CPS, not CSP (I noted that error frequently throughout the documents themselves; you might want to get that corrected). -agreement, -order, -document confirming rights to the domain . What valid forms can this document take? What steps are taken to verify or validate that information? Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4): 1. verification of agreement (we check if the company exist, who sign agreement
ODP: RE: KIR S.A. Root Inclusion Request
For the domain name specified in the order we check at http://www.dns.pl/cgi-bin/whois.pl whether the data presented to the domain owner are the same as customer data and the data for the certificate indicated in the order and agreement. If they are the same operator asks the administrator of the domain to place unique identification code supplied by KIR on the server. If the code is placed correctly KIR's operator confirms that order is valid and lets to issue certificate. He also makes a note in our internal system about how he checked validity of the ownership of the given domain. Od: Jeremy Rowley jeremy.row...@digicert.com Do: Certificates certifica...@kir.com.pl, dev-security-policy@lists.mozilla.org dev-security-policy@lists.mozilla.org, Data: 2014-09-26 16:16 Temat: RE: KIR S.A. Root Inclusion Request I think you should clarify what constitutes a document confirming rights to the domain. Is this authorization from the registrar or registrant? Who provides the document? -Original Message- From: dev-security-policy [ mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org ] On Behalf Of Certificates Sent: Friday, September 26, 2014 6:42 AM To: dev-security-policy@lists.mozilla.org Subject: Re: KIR S.A. Root Inclusion Request Answers for Matt Palmer questions: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): -agreement, -order, -document confirming rights to the domain . Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4): 1. verification of agreement (we check if the company exist, who sign agreement, if it is entitled representative), 2. verification of order (we check who sign order, if it is entitled representative, if the data given in order are correct), 3. verification whether the client has granted the right to the domain (we check who is an owner of the domain); 4. verification whether the client controls the domain (we ask to place data indicated by KIR on server); 5. identity of person authorised to represent client (we meet face to face with that person). If it is still unclear in CSP we can make it more clarified. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. KIR's answer: When issuing test certificate, we check the points 1 -4 listed above, and the validy of the renewed certifcate. Best regards Przemyslaw Rawa Od: Matt Palmer mpal...@hezmatt.org Do: dev-security-policy@lists.mozilla.org, Data: 2014-09-25 22:38 Temat: Re: KIR S.A. Root Inclusion Request Wysłane przez: dev-security-policy dev-security-policy-bounces+certificates=kir.com...@lists.mozilla.org On Thu, Sep 25, 2014 at 03:06:59PM +0200, Certificates wrote: Answers for Matt Palmer questions: On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@gmail.com wrote: As you can see above in the same point of CPS: To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming rights to the domain (optionally, relative to the certificate type); 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber). In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Rights to the domain is indicated there as being optional, and I can't find any indication in the CPS of which certificate types will be domain-validated. Also, the only place I've found a description of your domain validation practices is at the bottom of CPS s3.2.2, which only mentions having information placed on a server. My reading of the e-mail communication option is for purposes other than domain validation. Can you confirm that is the case? CSP s3.2 concerns all type of certificates. Optional, relevant
Re: ODP: Re: KIR S.A. Root Inclusion Request
On Mon, Sep 29, 2014 at 03:41:07PM +0200, Certificates wrote: On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote: -agreement, -order, -document confirming rights to the domain . What valid forms can this document take? What steps are taken to verify or validate that information? KIR's answer: All of this additional information should be placed in the CPS. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: KIR S.A. Root Inclusion Request
Answers for Matt Palmer questions: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): -agreement, -order, -document confirming rights to the domain . Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4): 1. verification of agreement (we check if the company exist, who sign agreement, if it is entitled representative), 2. verification of order (we check who sign order, if it is entitled representative, if the data given in order are correct), 3. verification whether the client has granted the right to the domain (we check who is an owner of the domain); 4. verification whether the client controls the domain (we ask to place data indicated by KIR on server); 5. identity of person authorised to represent client (we meet face to face with that person). If it is still unclear in CSP we can make it more clarified. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. KIR's answer: When issuing test certificate, we check the points 1 -4 listed above, and the validy of the renewed certifcate. Best regards Przemyslaw Rawa Od: Matt Palmer mpal...@hezmatt.org Do: dev-security-policy@lists.mozilla.org, Data: 2014-09-25 22:38 Temat: Re: KIR S.A. Root Inclusion Request Wysłane przez: dev-security-policy dev-security-policy-bounces+certificates=kir.com...@lists.mozilla.org On Thu, Sep 25, 2014 at 03:06:59PM +0200, Certificates wrote: Answers for Matt Palmer questions: On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@gmail.com wrote: As you can see above in the same point of CPS: To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming rights to the domain (optionally, relative to the certificate type); 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber). In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Rights to the domain is indicated there as being optional, and I can't find any indication in the CPS of which certificate types will be domain-validated. Also, the only place I've found a description of your domain validation practices is at the bottom of CPS s3.2.2, which only mentions having information placed on a server. My reading of the e-mail communication option is for purposes other than domain validation. Can you confirm that is the case? CSP s3.2 concerns all type of certificates. Optional, relevant to the certificate type means that we don't ask for domain validation for e.g. the standard certificate. We do domain validation for all SSL certifcates. More details about process of validation during issuing certificates of all types you can find in CP. I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. We reserve itself the right to downtime our OCSP, but it doesn't mean that we do it every week during normal working hours. What is acceptable level of service for you? We can adjust our technical downtime for OCSP. 100%. OCSP is a fundamental service for a publically-trusted CA to provide. Given
RE: KIR S.A. Root Inclusion Request
I think you should clarify what constitutes a document confirming rights to the domain. Is this authorization from the registrar or registrant? Who provides the document? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Certificates Sent: Friday, September 26, 2014 6:42 AM To: dev-security-policy@lists.mozilla.org Subject: Re: KIR S.A. Root Inclusion Request Answers for Matt Palmer questions: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): -agreement, -order, -document confirming rights to the domain . Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4): 1. verification of agreement (we check if the company exist, who sign agreement, if it is entitled representative), 2. verification of order (we check who sign order, if it is entitled representative, if the data given in order are correct), 3. verification whether the client has granted the right to the domain (we check who is an owner of the domain); 4. verification whether the client controls the domain (we ask to place data indicated by KIR on server); 5. identity of person authorised to represent client (we meet face to face with that person). If it is still unclear in CSP we can make it more clarified. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. KIR's answer: When issuing test certificate, we check the points 1 -4 listed above, and the validy of the renewed certifcate. Best regards Przemyslaw Rawa Od: Matt Palmer mpal...@hezmatt.org Do: dev-security-policy@lists.mozilla.org, Data: 2014-09-25 22:38 Temat: Re: KIR S.A. Root Inclusion Request Wysłane przez: dev-security-policy dev-security-policy-bounces+certificates=kir.com...@lists.mozilla.org On Thu, Sep 25, 2014 at 03:06:59PM +0200, Certificates wrote: Answers for Matt Palmer questions: On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@gmail.com wrote: As you can see above in the same point of CPS: To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming rights to the domain (optionally, relative to the certificate type); 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber). In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Rights to the domain is indicated there as being optional, and I can't find any indication in the CPS of which certificate types will be domain-validated. Also, the only place I've found a description of your domain validation practices is at the bottom of CPS s3.2.2, which only mentions having information placed on a server. My reading of the e-mail communication option is for purposes other than domain validation. Can you confirm that is the case? CSP s3.2 concerns all type of certificates. Optional, relevant to the certificate type means that we don't ask for domain validation for e.g. the standard certificate. We do domain validation for all SSL certifcates. More details about process of validation during issuing certificates of all types you can find in CP. I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do
Re: KIR S.A. Root Inclusion Request
On Fri, Sep 26, 2014 at 02:42:05PM +0200, Certificates wrote: I don't read the CP (specifically, s2.4) as confirming that the Applicant controls the Fully-Qualified Domain Name (as per BR 1.1.9 s.9.2.1). KIR's answer: To get a SSL certificate client has to provide(CSP s.3.2): That's presumably supposed to be CPS, not CSP (I noted that error frequently throughout the documents themselves; you might want to get that corrected). -agreement, -order, -document confirming rights to the domain . What valid forms can this document take? What steps are taken to verify or validate that information? Identification and authentication includes (CSP s.3.2, 3.2.2, CP s.2.4): 1. verification of agreement (we check if the company exist, who sign agreement, if it is entitled representative), 2. verification of order (we check who sign order, if it is entitled representative, if the data given in order are correct), 3. verification whether the client has granted the right to the domain (we check who is an owner of the domain); How is that ownership check performed? 4. verification whether the client controls the domain (we ask to place data indicated by KIR on server); 5. identity of person authorised to represent client (we meet face to face with that person). If it is still unclear in CSP we can make it more clarified. That would be appreciated. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. That is not clear from the CPS. KIR's answer: When issuing test certificate, we check the points 1 -4 listed above, and the validy of the renewed certifcate. That would be a good clarification to place in the CPS itself. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: KIR S.A. Root Inclusion Request
Answers for Matt Palmer questions: On Wed, Sep 24, 2014 at 05:17:02AM -0700, kircertifica...@gmail.com wrote: As you can see above in the same point of CPS: To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming rights to the domain (optionally, relative to the certificate type); 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber). In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Rights to the domain is indicated there as being optional, and I can't find any indication in the CPS of which certificate types will be domain-validated. Also, the only place I've found a description of your domain validation practices is at the bottom of CPS s3.2.2, which only mentions having information placed on a server. My reading of the e-mail communication option is for purposes other than domain validation. Can you confirm that is the case? CSP s3.2 concerns all type of certificates. Optional, relevant to the certificate type means that we don't ask for domain validation for e.g. the standard certificate. We do domain validation for all SSL certifcates. More details about process of validation during issuing certificates of all types you can find in CP. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). Are you asking Mozilla to blacklist certificates marked with that OID from being trusted? If not, the fact that they have such an identifier is irrelevant for the purposes of determining trustworthiness. I am not sure if Mozilla has implemented funcionality like blacklist for certificates marked with OID. As we can see other CAs do not force their subscriber to show their ID even during issuing non-test certificates. We check subscribers identity face to face. Only issuing test cerificate we don't ask subscriber for visiting our RA. Below you can find one example from CPS of CA which root certificates is inclued in the Mozilla browser: Registration might require subscriber or a representative authorized by the subscriber to personally attend a registration authority. Nevertheless, CERTUM permits (for specified certificate types) sending applications for registration by mail, electronic mail, WWW sites, etc.; examination of the applications does not necessitate a physical contact with the requester. We reserve itself the right to downtime our OCSP, but it doesn't mean that we do it every week during normal working hours. What is acceptable level of service for you? We can adjust our technical downtime for OCSP. 100%. OCSP is a fundamental service for a publically-trusted CA to provide. Given that it can easily be run as a read-only service for a period of time (in your case, up to 24 hours), there is no reason why maintenance cannot be done entirely without interruption. We maintain OCSP on line 24x7. But 100% availability of is utopia. Even e- banking systems have their downtimes. We want to be fair to the user, that's why we inform them about possibility of downtime. We can remove this 4 hour from CSP. Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł. Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz z załącznikami) z Państwa systemu. The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you are not an indicated recipient, you must not copy, distribute or take any action in reliance on it. If received in error, please notify the sender by return email and delete his transmission (and any attachments) from your system. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: KIR S.A. Root Inclusion Request
Hi Przemyslaw, 1) Suspension I can see that it's no problem for a certificate's status as shown in OCSP or in a CRL (as viewed from outside your organization) to transition from valid to 'Revoked' as a result of a 'suspension' within your system. The problem comes when you try to 'unsuspend'. You can't transition back from 'revoked' to valid. http://www.ietf.org/rfc/rfc5280.txt 3.3. Revocation ... An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. Regards Robin Alden -Original Message- From: dev-security-policy [mailto:dev-security-policy- bounces+robin=comodo@lists.mozilla.org] On Behalf Of Certificates Sent: 25 September 2014 14:03 To: dev-security-policy@lists.mozilla.org Subject: Re: KIR S.A. Root Inclusion Request Answers for Jeremy Rowley questions: A couple of notes: 1) Under Section 3.4 and 4.9, suspension is not permitted for SSL certs under the BRs. Where the BR forbids certificates suspension? The Repository gives an answer revoke for suspended certificate, so it's consistent withe BR s13.2.7. 2) Section 3.3 should specify when re-verification is required (at least every 39 months). Although the CPS does say the original issuance process is followed, I didn't this specified at the certificate lifecycle is 5 years. Also, be aware that five year certs are only permitted until April 1, 2015. After that, the maximum lifecycle is 39 months Yes, we know about this requirement. Presently, we do not issue certificates above 2 years validity period, although we mentioned such possibility in CPS. We do verification both for first certificate and renewal, in particular we verify rights to domain for SSL certificates. Our internal procedures describe this process in details. 3) See section 13.1.5 of the BRs for the reasons a CA must revoke a certificate. Section 4.9 of your CPS doesn't really match these. The reasons for revoking subscriber certificate pointed in CSP corresponds to the reasons pointed in BR. But if the connection isn't clear we can clarified it more in CSP by introducing some changes. 4) Archiving is required for 7 years under the BRs (5.4.3 and 5.5). That's a mistake in CPS. We will change it. 5) 6.28 should require at least two individuals acting together to activate the private key It is done by two persons. It is mentioned in CPS s.6.2.2 that the secrets are distributed among 5 persons. CSP s6.2.6. Uploading a private key to cryptographic modules is done in the following situations: 1) launch of the certification authority during the system start-up; 2) recovery of the key of the certification authority in the back-up location; 3) replacement of the cryptographic module. The key is uploaded to the module with the presence of the holders of co-shared secrets. To upload the key it is necessary to have the presence of the number of secrets described in Clause 6.2.2. Uploading is done within a closed security environment. A private key is made up of elements. Parts of the secret key from the cards are provided in sequence, enciphered files are uploaded into the module's memory and then deciphered. A private key is ready to use. Uploading of the key into the module is recorded in the register of events. CSP s.6.2.8 Once uploaded into the module, the key shall be active. 6) Some of your EKU extensions are not permitted in the same certificate. We are aware of it. In the SSL certificates we use only clientAuthentication and serverAuthentication. 7) Note the recently announced SHA-2 requirement. SHA-1 is the only hash specified in the CPS. 5 year certificates will not be possible. We are aware of it and we will start issuing certificates with SHA 256 before this date and also supplement our CSP accordingly. 8) What is your OCSP response for a not issued cert? The answer is unknown - CSP s4.9.9. Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł. Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz z załącznikami) z Państwa systemu. The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you
Re: KIR S.A. Root Inclusion Request
If you look under Section 13.2.4, a CA cannot remove an entry from its CRLs, meaning there is no way to un-suspend a certificate. On 9/25/2014 7:03 AM, Certificates wrote: Answers for Jeremy Rowley questions: A couple of notes: 1) Under Section 3.4 and 4.9, suspension is not permitted for SSL certs under the BRs. Where the BR forbids certificates suspension? The Repository gives an answer revoke for suspended certificate, so it's consistent withe BR s13.2.7. 2) Section 3.3 should specify when re-verification is required (at least every 39 months). Although the CPS does say the original issuance process is followed, I didn't this specified at the certificate lifecycle is 5 years. Also, be aware that five year certs are only permitted until April 1, 2015. After that, the maximum lifecycle is 39 months Yes, we know about this requirement. Presently, we do not issue certificates above 2 years validity period, although we mentioned such possibility in CPS. We do verification both for first certificate and renewal, in particular we verify rights to domain for SSL certificates. Our internal procedures describe this process in details. 3) See section 13.1.5 of the BRs for the reasons a CA must revoke a certificate. Section 4.9 of your CPS doesn't really match these. The reasons for revoking subscriber certificate pointed in CSP corresponds to the reasons pointed in BR. But if the connection isn't clear we can clarified it more in CSP by introducing some changes. 4) Archiving is required for 7 years under the BRs (5.4.3 and 5.5). That's a mistake in CPS. We will change it. 5) 6.28 should require at least two individuals acting together to activate the private key It is done by two persons. It is mentioned in CPS s.6.2.2 that the secrets are distributed among 5 persons. CSP s6.2.6. Uploading a private key to cryptographic modules is done in the following situations: 1) launch of the certification authority during the system start-up; 2) recovery of the key of the certification authority in the back-up location; 3) replacement of the cryptographic module. The key is uploaded to the module with the presence of the holders of co-shared secrets. To upload the key it is necessary to have the presence of the number of secrets described in Clause 6.2.2. Uploading is done within a closed security environment. A private key is made up of elements. Parts of the secret key from the cards are provided in sequence, enciphered files are uploaded into the module's memory and then deciphered. A private key is ready to use. Uploading of the key into the module is recorded in the register of events. CSP s.6.2.8 Once uploaded into the module, the key shall be active. 6) Some of your EKU extensions are not permitted in the same certificate. We are aware of it. In the SSL certificates we use only clientAuthentication and serverAuthentication. 7) Note the recently announced SHA-2 requirement. SHA-1 is the only hash specified in the CPS. 5 year certificates will not be possible. We are aware of it and we will start issuing certificates with SHA 256 before this date and also supplement our CSP accordingly. 8) What is your OCSP response for a not issued cert? The answer is unknown - CSP s4.9.9. Krajowa Izba Rozliczeniowa S.A., ul. rtm. W. Pileckiego 65, 02-781 Warszawa, zarejestrowana w Sądzie Rejonowym dla m. st. Warszawy, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 113064, NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony 5.445.000 zł. Informacja zawarta w tej transmisji jest przeznaczona tylko dla osoby lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. W przypadku otrzymania tej transmisji przez pomyłkę, proszę powiadomić nadawcę za pomocą emaila zwrotnego i usunąć tę transmisję (wraz z załącznikami) z Państwa systemu. The information contained in this transmission is intended only for the individual or entity to whom it is addressed. It may contain privileged and confidential information and if you are not an indicated recipient, you must not copy, distribute or take any action in reliance on it. If received in error, please notify the sender by return email and delete his transmission (and any attachments) from your system. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy . ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: KIR S.A. Root Inclusion Request
As you can see above in the same point of CPS: To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming rights to the domain (optionally, relative to the certificate type); 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber). In case of test certificates according our CPS we can skip point 1 from the above list. It means that we do not force subscriber to visit our RA and show his identification card, as we do in case of another kinds of certificates. But still all other things like agreement, order and documents confirming rights to the domain are verified carefully. Note that test cerificates have their own policy's distinguished identifier (s 2.5 CP). We reserve itself the right to downtime our OCSP, but it doesn't mean that we do it every week during normal working hours. What is acceptable level of service for you? We can adjust our technical downtime for OCSP. On Wednesday, September 24, 2014 6:02:15 AM UTC+2, Matt Palmer wrote: One thing leaps out at me immediately: these test certificates. They appear to be issued from the same CA as the regular certificates, but s3.2 states, In case of test certificates they may be issued remotely *without the necessity to verify the subscriber's identity. That seems... bad. *Really* bad. I'm also a little concerned about the last sentence of s4.9.9 (dealing with OCSP responders) -- at least, I'm assuming that italics sentence in the header of 4.9.10 isn't supposed to be a header. I don't think that being able to take down your OCSP service for fours hours every week really constitutes an acceptable level of service. - Matt On Tue, Sep 23, 2014 at 05:49:17PM -0700, Kathleen Wilson wrote: Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the SZAFIR ROOT CA root certificate and enable all three trust bits. KIR S.A. is a private corporation in Poland which currently mainly issues qualified certificates for general public and plans to issue non-qualified certificates (e.g. SSL certificates). KIR S.A. is an automated clearing house in Poland and its core business is clearings, and has built numerous business relationships within banking sector. Therefore, KIR S.A. is aiming to expand its sales in services such as SSL and VPN certificates. KIR S.A. has another line of products called PayByNet, and has created a vast network of relationships within online stores that KIR S.A. can leverage to create customer base for trusted non-qualified certificates. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=817994 And in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/ Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8441701 Noteworthy points: * The primary documents, the CP and CPS, are provided in both English and Polish. Document Repository: http://elektronicznypodpis.pl/en/information/documents-and-agreements CPS: http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf CP: http://elektronicznypodpis.pl/files/doc/certification_policy.pdf * CA Hierarchy: There is currently one internally-operated subordinate-CA which issues 6 types of end-user certificates: - Standard certificate - For protection of information sent electronically, using mainly e-mail, for authorizing access to systems, customer authentication in SSL connections. It allows signing and encrypting data in an electronic form and authenticating subscribers. - Code signing certificate - VPN certificate - SSL certificate - Test certificate - For testing co-operation of the certificate with solutions used or developed by a recipient of certification services or a subscriber. - ELIXIR certificate - For protecting information sending within ELIXIR and EuroELIXIR systems. This kind of certificates are issued only for Participants of ELIXIR and EuroELIXIR systems. * The request is to enable all three trust bits. ** CPS section 3.2, Initial Identity Validation: Depending on the type of certificate the procedure of certificate issuance may be different and is relative to a specific certification policy. To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming
Re: KIR S.A. Root Inclusion Request
One thing leaps out at me immediately: these test certificates. They appear to be issued from the same CA as the regular certificates, but s3.2 states, In case of test certificates they may be issued remotely *without the necessity to verify the subscriber's identity. That seems... bad. *Really* bad. I'm also a little concerned about the last sentence of s4.9.9 (dealing with OCSP responders) -- at least, I'm assuming that italics sentence in the header of 4.9.10 isn't supposed to be a header. I don't think that being able to take down your OCSP service for fours hours every week really constitutes an acceptable level of service. - Matt On Tue, Sep 23, 2014 at 05:49:17PM -0700, Kathleen Wilson wrote: Krajowa Izba Rozliczeniowa (KIR) S.A. has applied to include the “SZAFIR ROOT CA” root certificate and enable all three trust bits. KIR S.A. is a private corporation in Poland which currently mainly issues qualified certificates for general public and plans to issue non-qualified certificates (e.g. SSL certificates). KIR S.A. is an automated clearing house in Poland and its core business is clearings, and has built numerous business relationships within banking sector. Therefore, KIR S.A. is aiming to expand its sales in services such as SSL and VPN certificates. KIR S.A. has another line of products called PayByNet, and has created a vast network of relationships within online stores that KIR S.A. can leverage to create customer base for trusted non-qualified certificates. The request is documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=817994 And in the pending certificates list: http://www.mozilla.org/projects/security/certs/pending/ Summary of Information Gathered and Verified: https://bugzilla.mozilla.org/attachment.cgi?id=8441701 Noteworthy points: * The primary documents, the CP and CPS, are provided in both English and Polish. Document Repository: http://elektronicznypodpis.pl/en/information/documents-and-agreements CPS: http://www.elektronicznypodpis.pl/files/doc/certification_practice_statement.pdf CP: http://elektronicznypodpis.pl/files/doc/certification_policy.pdf * CA Hierarchy: There is currently one internally-operated subordinate-CA which issues 6 types of end-user certificates: - Standard certificate - For protection of information sent electronically, using mainly e-mail, for authorizing access to systems, customer authentication in SSL connections. It allows signing and encrypting data in an electronic form and authenticating subscribers. - Code signing certificate - VPN certificate - SSL certificate - Test certificate - For testing co-operation of the certificate with solutions used or developed by a recipient of certification services or a subscriber. - ELIXIR certificate - For protecting information sending within ELIXIR and EuroELIXIR systems. This kind of certificates are issued only for Participants of ELIXIR and EuroELIXIR systems. * The request is to enable all three trust bits. ** CPS section 3.2, Initial Identity Validation: Depending on the type of certificate the procedure of certificate issuance may be different and is relative to a specific certification policy. To receive a certificate it is necessary for the subscriber who is a natural person or an authorised representative of the recipient of certification services to present: 1) an identification card (or its photocopy depending on the type of certificate); 2) documents confirming rights to the domain (optionally, relative to the certificate type); 3) a file with the certificate request (if the pair of keys is generated individually by the subscriber). KIR S.A. may expect presentation of other documents, in case entering data other than the subscriber's first name and surname and the PESEL or NIP number into the certificate is requested. ** CPS section 3.2.2: Identification and authentication of entities other than a natural person is the case when data of such entity is included in the data for the certificate for the issuance of which it applies to KIR S.A., or data included in the certificate contains information about such entity, e.g. the name of the Internet domain. Depending on the type of certificate, identification shall be performed on the basis of documents sent by the recipient of certification services or data disclosed in the Agreement and in the order. The manner of confirming such data depends on the type of certificate. For this purpose KIR S.A. may request sending additional documents, check the data of the recipient of certification services in commonly accessible registers and services, obtain a card of signatures of persons authorised to represent the recipient of certification services. Issuance of the certificate may also require a personal meeting of a person authorised to represent a specific entity with an authorised representative of KIR S.A. Wishing to
