(NOTE: This has nothing to do with Entrust legacy roots in NSS, and
nothing to do with Entrust cross-signing of other CA's roots. AFAICT
this root is used only for Entrust EV certificates. In bug 416544
Entrust has also requested EV status for its legacy roots, but I'm
handling that as a separate issue.)
Entrust recently completed and published a WebTrust EV audit for this
root. (There's a WebTrust audit as well.) At first glance everything
looks in order. I'm therefore opening up an initial public comment
period for this request. At the end of that comment period I'll make a
preliminary determination whether to approve the request or not, and
then we'll have a final public comment period before I make a final
decision.
This idea of having two comment periods is one I think I mentioned
previously in this forum. You can consider this a first call for
comments, and then we'll have a last call if/when I do a preliminary
approval. This is the first time we've done it this way, so I'll
arbitrarily set the first comment period at 2 weeks, and the second one
at 1 week; we can make these longer or shorter as needed.
For more information about the Entrust EV request please see the pending
list entry for Entrust:
http://www.mozilla.org/projects/security/certs/pending/#Entrust
For more information about the previous request from last year please
see the Entrust entry in the included list:
http://www.mozilla.org/projects/security/certs/included/#Entrust
Note that I checked in Entrust-related updates for these list just a few
minutes ago, so it may take an hour or two for them to show up on the site.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
(NOTE: This has nothing to do with Entrust legacy roots in NSS, and nothing to do with Entrust cross-signing of other CA's roots. AFAICT this root is used only for Entrust EV certificates. In bug 416544 Entrust has also requested EV status for its legacy roots, but I'm handling that as a separate issue.)
Regards | |
Signer: | Eddy Nigg, StartCom Ltd. |
Jabber: | star...@startcom.org |
Blog: | Join the Revolution! |
Phone: | +1.213.341.0390 |
Per Entrust, at present this root has only one subordinate CA, the
"Entrust Certification Authority - L1A" used to issue EV certificates.
So in that sense, yes, the governing CPS for the hierarchy is the EV CPS.
Eddy Nigg (StartCom Ltd.) wrote:Does the document http://www.entrust.net/CPS/pdf/webcps051404.pdf not apply for this root and if so how do you know about it?Per Entrust, at present this root has only one subordinate CA, the "Entrust Certification Authority - L1A" used to issue EV certificates. So in that sense, yes, the governing CPS for the hierarchy is the EV CPS.
My apologies, I didn't exactly get what you were asking. Yes, I'll make
a note about this in the bug and in the pending list, and get confirmation.
Eddy Nigg (StartCom Ltd.) wrote:That's nice, but how can *I* also know about it? Would it be possible to confirm it at the bug (that only EV certificates will be issued from that root ) and remove the OV attribute from http://www.mozilla.org/projects/security/certs/pending/#Entrust ?My apologies, I didn't exactly get what you were asking. Yes, I'll make a note about this in the bug and in the pending list, and get confirmation.
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.
Maybe I'm being dense, but I don't see what the issue is here.
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.
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
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.
Regards | |
Signer: | Eddy Nigg, StartCom Ltd. |
You are correct, if the WHOIS records do not match then the process is
stopped. In the case of a private domain registration as per your
Domains by Proxy example, we would confirm via another method such as
1) through the registar (Domains by Proxy provides this service), 2)
have domain information made public, 3)communication with the
registrant through the registrar.
Business ID is generally performed through third party database look-
ups. Individual ID is accepted by fax.
Authorization is confirmed by calling an authorizing contact at the
business that has registered the domain. This is an additional contact
to the certificate requester.
Regards, Bruce.
You are correct, if the WHOIS records do not match then the process is stopped. In the case of a private domain registration as per your Domains by Proxy example, we would confirm via another method such as 1) through the registar (Domains by Proxy provides this service), 2) have domain information made public, 3)communication with the registrant through the registrar. Business ID is generally performed through third party database look- ups. Individual ID is accepted by fax. Authorization is confirmed by calling an authorizing contact at the business that has registered the domain. This is an additional contact to the certificate requester.
Regards | |
Signer: | Eddy Nigg, StartCom Ltd. |
> [...] In the case of a private domain registration as per your
> Domains by Proxy example, we would confirm via another method such as
> 1) through the registar (Domains by Proxy provides this service), 2)
> have domain information made public, 3)communication with the
> registrant through the registrar.
>
> Business ID is generally performed through third party database look-
> ups. Individual ID is accepted by fax.
Is that good enough for Individual ID?
Can you detect if an individual faxes a stolen ID?
Before we go too far down this path... I believe that having people fax
in identity documents (whether individual or corporate) is a fairly
common and accepted practice in the CA world. Unless someone can show me
that I'm wrong and that Entrust's practices are significantly out of
line with the rest of the industry, this is not an issue I'd see as
relevant for this particular request.
This touches on the point I made earlier about "reasonable measures" as
used in our CA policy, and the term "commercially reasonable" as used in
US and Canadian legal contexts. The contrasting legal term to
"commercially reasonable" is "best efforts", which is a more stringent
standard implying (in a CA context) that the CA would take pretty much
any and all measures practicable to verify identity ("leave no stone
unturned") and would strive to minimize as much as possible the
possibility of accepting a fraudulent application.
In my opinion the level of verification for IV/OV certs, as practiced in
the CA industry and required by our policy, corresponds to a
"commercially reasonable efforts" standard. If we want to apply a "best
efforts" standard then IMO that's what EV is for.
Nelson B Bolyard wrote:Is that good enough for Individual ID? Can you detect if an individual faxes a stolen ID?Before we go too far down this path... I believe that having people fax in identity documents (whether individual or corporate) is a fairly common and accepted practice in the CA world. Unless someone can show me that I'm wrong and that Entrust's practices are significantly out of line with the rest of the industry, this is not an issue I'd see as relevant for this particular request. This touches on the point I made earlier about "reasonable measures" as used in our CA policy, and the term "commercially reasonable" as used in US and Canadian legal contexts. The contrasting legal term to "commercially reasonable" is "best efforts", which is a more stringent standard implying (in a CA context) that the CA would take pretty much any and all measures practicable to verify identity ("leave no stone unturned") and would strive to minimize as much as possible the possibility of accepting a fraudulent application. In my opinion the level of verification for IV/OV certs, as practiced in the CA industry and required by our policy, corresponds to a "commercially reasonable efforts" standard. If we want to apply a "best efforts" standard then IMO that's what EV is for.
Regards | |
Signer: | Eddy Nigg, StartCom Ltd. |
I agree that it would be a good thing if Entrust (or any CA, for that
matter) used technical means (like sending email to postmaster or
whatever) to verify domain name ownership for non-EV SSL certs, in
addition to whatever other procedures are used. However based on what
the policy says and how we've interpreted it in the past, I can't
justify rejecting or delaying Entrust's request based on this particular
issue.
I agree that it would be a good thing if Entrust (or any CA, for that matter) used technical means (like sending email to postmaster or whatever) to verify domain name ownership for non-EV SSL certs, in addition to whatever other procedures are used. However based on what the policy says and how we've interpreted it in the past, I can't justify rejecting or delaying Entrust's request based on this particular issue.
In the past, at least, I've used "email a contact at the domain" as the
minimum required for me to accept the process for the issuance of DV
certs. Given that this process can be almost entirely automated, it
would strike me as surprising if any CA wasn't doing it, but did more
expensive manual processes instead. <shrug>
Gerv
It's now been a week since I opened the first public comment period on
this, and there haven't been any new comments in the last few days.
Would anyone object if I went ahead and rendered a preliminary decision
on this request? (Then we'll have a second public comment period.)