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 authenticate other data recording which in the > certificate a specific entity requests, KIR S.A. may ask for: > 1) placing data indicated by KIR S.A. in a target server by the > subscriber acting to order of a legal person, which is to verify the > rights to the Internet domain; > 2) providing answer to a query sent by KIR S.A. to an e-mail address > placing of which in the certificate a legal person demands. > > ** CPS section 3.2.5. Checking Rights to Receive Certificate > The recipient of certification services signs an agreement with KIR > S.A. for the provision of certification services. Authorised > representatives also sign data for the certificate included in the > order for a specific subscriber. Thus, pursuant to an agreement they > confirm the subscriber's right to use the certificate in which the > data of the entity they represent is included. > The right to represent an entity by such persons is checked by KIR > S.A. in the course of identification and authentication. > > ** CP section 2.1, Standard certificate: These certificates may be > used for securing electronic mail and for logging into the systems > or services, authorising the subscriber during establishment of > secure connections. > In the process of issuing this type of certificates the operator KIR > S.A. shall verify the subscriber’s identity and the right to obtain > such certificate. The certificate is delivered to the subscriber > most often with a pair of keys generated on a carrier defined by the > subscriber. Data included in the certificate allows identifying the > subscriber that uses the certificate. > > ** CP section 2.2: Certificates for signing codes are used for > confirming authenticity and origins of binary codes. Based on the > data included in the certificate it is possible for define the > author or an entity that provides the code for a program or > application. > In the process of issuing this type of certificates the operator KIR > S.A. shall verify the subscriber’s identity and the right to obtain > such certificate and shall confirm reliability of the data entered > into the certificate. > > ** CP section 2.4: An SSL certificate allows confirming authenticity > of www servers and setting up secure connections using SSL and TSL > protocols. A certificate may contain data of a single www server or > associated servers within a single domain. > 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 may also include verification, whether > the server or domain are held by the recipient of certification > services. > > ** 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. > > * EV Policy OID: Not requesting EV treatment > > * Test Website: https://ssl.elektronicznypodpis.pl > > * OCSP: http://ocsp.elektronicznypodpis.pl > > * Audit: Annual audits are performed by Ernst&Young according to the > WebTrust CA and BR criteria. The WebTrust seal file contains two > audit statements: WebTrust CA and WebTrust BR. > https://cert.webtrust.org/SealFile?seal=1681&file=pdf > > * Potentially Problematic Practices – None Noted > (http://wiki.mozilla.org/CA:Problematic_Practices) > > This begins the discussion of the request from KIR S.A. to include > the “SZAFIR ROOT CA” root certificate and enable all three trust > bits. At the conclusion of this discussion I will provide a summary > of issues noted and action items. If there are outstanding issues, > then an additional discussion may be needed as follow-up. If there > are no outstanding issues, then I will recommend approval of this > request in the bug. > > Kathleen > > -- > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- I still can't see a wasp without thinking "400K 1W" -- Derek Potter, uk.misc _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
