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 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 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. My bank doesn't go down for four hours every week, nor does it claim to be able to. If it did, I'd find another bank, but as a relying party, I can't find another CA to present a certificate for a site I wish to verify the authenticity of. > 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. I think that would be best. - 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
