Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Entrust EV request

10 views
Skip to first unread message

Frank Hecker

unread,
Jun 4, 2008, 1:49:00 PM6/4/08
to
I've been looking at a request from Entrust (bug 416544) to (among other
things) have its new Entrust Root Certification Authority root enabled
for EV. This is a new Entrust root that was approved for inclusion last
year by Gerv (bug 382352) and subsequently added to NSS (bug 387892).

(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

Eddy Nigg (StartCom Ltd.)

unread,
Jun 4, 2008, 8:15:46 PM6/4/08
to mozilla's crypto code discussion list
Frank Hecker:
(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.)
  

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? I haven't found any reference in that respect and I would like to make this clear. If not, then OV should be removed from the pending page, else I'd like to comment further.


Regards 
 
Signer:  Eddy Nigg, StartCom Ltd.
Jabber:  star...@startcom.org
Blog:  Join the Revolution!
Phone:  +1.213.341.0390
 

Frank Hecker

unread,
Jun 5, 2008, 12:43:54 AM6/5/08
to
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.

Eddy Nigg (StartCom Ltd.)

unread,
Jun 5, 2008, 4:41:00 AM6/5/08
to mozilla's crypto code discussion list
Frank Hecker:
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.
  

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 ?

Frank Hecker

unread,
Jun 5, 2008, 8:47:27 AM6/5/08
to
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.

Eddy Nigg (StartCom Ltd.)

unread,
Jun 5, 2008, 4:27:06 PM6/5/08
to Frank Hecker, mozilla's crypto code discussion list
Frank Hecker:
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.
  
I peaked already at the bug and continue to respond to the inclusion request as it seems to be clear that non-EV certificates may be issued from this root and the governing CP/CPS is http://www.entrust.net/CPS/pdf/webcps051404.pdf

Therefore I'd like to request clarification and verification about how domains are validated by the RAs, since the CPS isn't clear in that respect. Please note that Gerv in the original inclusion request perhaps missed that point and I must have been asleep as well or just started to regularly review inclusions back then.

Refence is 3.1.8 from the CPS:

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.

Frank Hecker

unread,
Jun 5, 2008, 4:55:41 PM6/5/08
to
Eddy Nigg (StartCom Ltd.) wrote:
> Therefore I'd like to request clarification and verification about how
> domains are validated by the RAs, since the CPS isn't clear in that
> respect.
<snip>

> Refence is 3.1.8 from the CPS:
>
> 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.

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.

Eddy Nigg (StartCom Ltd.)

unread,
Jun 5, 2008, 6:40:02 PM6/5/08
to Frank Hecker, mozilla's crypto code discussion list
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?

Bruce

unread,
Jun 6, 2008, 8:49:56 AM6/6/08
to
On Jun 5, 6:40 pm, "Eddy Nigg (StartCom Ltd.)"
> 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:         start...@startcom.org <xmpp:start...@startcom.org>
> 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

Eddy Nigg (StartCom Ltd.)

unread,
Jun 6, 2008, 9:34:13 AM6/6/08
to bruce....@entrust.com, mozilla's crypto code discussion list
Hi Bruce,

Bruce:
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.
  

Thank you for providing us with this information. If I understand correctly (also according to the enrollment guide) if the WHOIS records don't match those of the subscriber, the process is stopped and the request rejected? Therefore the example I made previously wouldn't be acceptable?

Also, do you request from subscribers to actually see some documents, like photo ID and company registration confirmation or similar? And how do you make sure that the subscriber is authorized for requesting a certificate? Also it seems that you rely only on confirming the (organization) details with that of the relevant authority (like company registry)? Are there any other cross-verifications you perform in order to establish sufficient authorization and privileges by the subscriber?

The reason I'm asking is because it appears to me that you don't perform some kind of administrative privilege check to verify domain ownership (and control), instead you rely on information provided by the subscriber and a phone call to the number you found in the phone directory for that business (and most likely by requesting to speak with the person who submitted the request).

In that respect, domain validation by automated means isn't such a bad thing to establish initial authorization and control over the domain.


Regards 
 
Signer:  Eddy Nigg, StartCom Ltd.

Bruce

unread,
Jun 6, 2008, 5:46:48 PM6/6/08
to
On Jun 6, 9:34 am, "Eddy Nigg (StartCom Ltd.)"

<eddy_n...@startcom.org> wrote:
> Hi Bruce,
>
> Bruce:
>
>
>
> > 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 processhttp://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.
>
> Thank you for providing us with this information. If I understand
> correctly (also according to the enrollment guide) if the WHOIS records
> don't match those of the subscriber, the process is stopped and the
> request rejected? Therefore the example I made previously wouldn't be
> acceptable?
>
> Also, do you request from subscribers to actually see some documents,
> like photo ID and company registration confirmation or similar? And how
> do you make sure that the subscriber is authorized for requesting a
> certificate? Also it seems that you rely only on confirming the
> (organization) details with that of the relevant authority (like company
> registry)? Are there any other cross-verifications you perform in order
> to establish sufficient authorization and privileges by the subscriber?
>
> The reason I'm asking is because it appears to me that you don't perform
> some kind of administrative privilege check to verify domain ownership
> (and control), instead you rely on information provided by the
> subscriber and a phone call to the number you found in the phone
> directory for that business (and most likely by requesting to speak with
> the person who submitted the request).
>
> In that respect, domain validation by automated means isn't such a bad
> thing to establish initial authorization and control over the domain.
>
> Regards
> Signer:         Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
> Jabber:         start...@startcom.org <xmpp:start...@startcom.org>
> Blog:   Join the Revolution! <http://blog.startcom.org>
> Phone:  +1.213.341.0390

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.

Eddy Nigg (StartCom Ltd.)

unread,
Jun 6, 2008, 6:02:00 PM6/6/08
to bruce....@entrust.com, mozilla's crypto code discussion list
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.

  

Excellent Bruce, I think those were the missing links I was looking for. Just to make sure, in case no authorized contact is published at the WHOIS records or registrar (perhaps  when only the company name is published) I guess that you'll request confirmation of the owners or CEO or other reasonable contact of the company in order to confirm authorization of the subscriber. Is there such a procedure?

If positive I think this satisfies my questions in full. There might be another issue, which I'll discuss first with Frank before turning to you for any further help. Thanks for your cooperation!


Regards 
 
Signer:  Eddy Nigg, StartCom Ltd.

Nelson B Bolyard

unread,
Jun 7, 2008, 8:27:00 PM6/7/08
to mozilla's crypto code discussion list

Bruce wrote, On 2008-06-06 14:46:

> [...] 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?

Frank Hecker

unread,
Jun 8, 2008, 9:39:52 AM6/8/08
to
Nelson B Bolyard wrote:
> Bruce wrote, On 2008-06-06 14:46:
<snip>

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

Eddy Nigg (StartCom Ltd.)

unread,
Jun 8, 2008, 6:20:32 PM6/8/08
to mozilla's crypto code discussion list
Frank Hecker:
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.
  

A few things here:

According to the Mozilla CA policy we don't have to verify the IV/OV procedures usually, because the policy doesn't require it. However - and this is highly important to understand why and where also my experience as a CA comes in - it is important when those validations (IV/OV) are part of the validation procedure for domain, respectively email ownership verification. If ownership and control of a domain (and email) is performed by other means, it's not really important.

In this specific case it is important since no other procedure exists. That's also the reason why I requested to know more about the procedures performed by Entrust and its RAs. In this respect the question of Nelson is legitimate because it's not beyond the scope of what Mozilla requires.

Now, the industry standard of accepting faxes and other phrases about "reasonable measures", "best efforts" isn't really relevant if faxes aren't up to today's reasonable possibilities. Faxes are really something of the last century and today it's many times easier for the customer to scan photo ID cards, passports etc. and provide them. Those are of much higher quality usually and tools exist to detect retouching and editing of originals which is very hard to do with faxes. Obviously not the same as face-to-face verification, which however isn't really feasible most of the times.

But even in this case, the documents relayed to the CA are really only one of the pointers for successfully validating a person and/or organization and in doubt there are other means to receiving this information. The big question is usually, which effort the CA is willing to make and how fast it gets satisfied in order to receive the payment. Paradoxically, CAs are really getting their money from the wrong parties, but nothing will change that.

About EV: Extended Validation isn't a "best effort", but a defined procedure about how to do what. In my opinion, it isn't even the best a CA can do and as with all OV validation where the organization is the only part which is confirmed has very obvious shortcomings! If you don't mind, read about it at https://blog.startcom.org/?p=94 where I explained what it really means. Which is by the way not bad if the relying party knows what it means too - which I doubt. In short, a "best effort" you might find perhaps somewhere else, I'd rather say it's a "defined and forced upon the CAs effort" ;-)


Regards 
 
Signer:  Eddy Nigg, StartCom Ltd.

Frank Hecker

unread,
Jun 8, 2008, 8:02:22 PM6/8/08
to
Eddy Nigg (StartCom Ltd.) wrote:
> A few things here:
>
> According to the Mozilla CA policy we don't have to verify the IV/OV
> procedures usually, because the policy doesn't require it. However - and
> this is highly important to understand why and where also my experience
> as a CA comes in - it is important when those validations (IV/OV) are
> part of the validation procedure for domain, respectively email
> ownership verification. If ownership and control of a domain (and email)
> is performed by other means, it's not really important.
>
> In this specific case it is important since no other procedure exists.
> That's also the reason why I requested to know more about the procedures
> performed by Entrust and its RAs. In this respect the question of Nelson
> is legitimate because it's not beyond the scope of what Mozilla requires.

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.

Eddy Nigg (StartCom Ltd.)

unread,
Jun 8, 2008, 8:15:04 PM6/8/08
to mozilla's crypto code discussion list
Frank Hecker:
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.
  

Yes, I think they have by their answers proved compliance to the policy. Accepting faxes is really a matter of taste and somewhat backward.

Of course, merely sending an email to postmaster isn't the holy grail either and this can be improved by highly limiting the time-frame such a verification would be valid, additional lookup of the WHOIS records, checking of the purchase date of the domain etc...all this can/should be part of the domain validation when performing through electronic and automated means.

Gervase Markham

unread,
Jun 9, 2008, 5:27:09 AM6/9/08
to
Frank Hecker wrote:
> 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.

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

Frank Hecker

unread,
Jun 12, 2008, 1:15:13 PM6/12/08
to
Frank Hecker wrote:
> I've been looking at a request from Entrust (bug 416544) to (among other
> things) have its new Entrust Root Certification Authority root enabled
> for EV. This is a new Entrust root that was approved for inclusion last
> year by Gerv (bug 382352) and subsequently added to NSS (bug 387892).
\<snip>

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

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

0 new messages