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