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