On Jun 5, 6:40 pm, "Eddy Nigg (StartCom Ltd.)" <[EMAIL PROTECTED]> wrote: > Frank Hecker: > > > > > > > This language and other language in section 3.1.8 seem pretty standard > > to me; I've seen language like it in lots of CPSs. As I read it, RAs get > > various identity-related documents from applicants and cross-check that > > information against various databases, including checking the > > association between domain name and organizational identity, to make > > sure there are no inconsistencies (e.g., the domain name isn't > > registered to someone else). The CPS requires RAs to take "commercially > > reasonable efforts" in doing this. > > > Compare this to what our policy requires > > > ... for a certificate to be used for SSL-enabled servers, the CA > > takes reasonable measures to verify that the entity submitting > > the certificate signing request has registered the domain(s) > > referenced in the certificate or has been authorized by the domain > > registrant to act on the registrant's behalf > > > The policy doesn't specify exactly how this verification is to be done, > > only that the measures be "reasonable". In the US and Canada (where > > Entrust is based) the term "commercially reasonable" as used in the > > Entrust CPS means something like "what a reasonably prudent business > > person would do in similar circumstances"; this level of effort is > > consistent with our intent in the policy. > > Well, there is no problem with "commercially reasonable efforts", rather > I'd like to know a little bit more about their procedures and > requirements by the RAs. A practical example will help illustrate what > I'm missing... > > I'm Frank Hecker and I own bid4books.net. Validating Frank shouldn't be > such a problem perhaps, but do you really own bid4books.net? The third > party source (WHOIS) shows: > > Registrant: > Domains by Proxy, Inc. > DomainsByProxy.com > 15111 N. Hayden Rd., Ste 160, PMB 353 > Scottsdale, Arizona 85260 > United States > > Now, lets go back to their CPS again (and I haven't found anything > better than that): > > Registration Authorities operating under the Entrust SSL Web Server > Certification Authorities shall *determine whether* the organizational > identity, address, and *domain* name provided with an Entrust SSL Web > Server Certificate Application are *consistent* with *information* > contained *in third-party databases* and/or governmental sources. > > There is no stipulation about what happens in cases this can't be done > (e.g. it doesn't say it refuses to issue the certificate nor does it say > what else it does in such cases). In this respect the CPS is very weakly > defined at best and I'd prefer to receive explicit information from them > about what RAs are required to do. > > Additionally I'm missing something more about how the subscriber is > verified, consistency with third party sources isn't really enough, > isn't it? Or can I be really also Frank Hecker if I know all your details? > > Regards > Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> > Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> > Blog: Join the Revolution! <http://blog.startcom.org> > Phone: +1.213.341.0390- Hide quoted text - > > - Show quoted text -
All Organization Validated SSL certificates are issued using a three part process. The applicant's business name is validated against a third party database (e.g. D&B or government registry). Domain names are validated via a WHOIS lookup to ensure that the domain is registered to the business or that the applicant has the right to use the domain (i.e. parent or subsidiary company of registrant). Finally, an employee of the applicant is contacted through a phone number found in a third party source to confirm authorization to issue the certificate. See the Entrust enrollment guide for more details on the verification process http://www.entrust.net/ssl-resources/pdf/ssl-wap-enrollment-guide.pdf. This process is audited as part of our WebTrust for CA audit. FYI, Entrust does not issue Domain-only Validated SSL certificates. I hope that this provides enough additional clarification. Regards, Bruce Morton, Entrust _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
