[cabfpub] EV Guidelines §14.2 delegation of functions to RAs etc.

Kirk Hall Kirk.Hall at entrust.com
Wed Aug 17 16:56:50 UTC 2016


Adriano, I may not be understanding your original question -- but here is another possible answer.



If Company A applies for an EV cert for foo.com, the CA will do an EV vetting for the organization (Company A) and then for the domain (foo.com).  Under EVGL 14.2, it looks like Company A can then ask to be designated as an Enterprise RA - but only for the confirmed domain foo.com -- and then get certs for third level and higher domains that end in foo.com.  But Company A has not proven ownership or control of any other domains, such as bar.com, so is not an Enterprise RA for any other domains.



Now suppose Company A comes back to the RA and asks for a cert for bar.com.  In my opinion, the CA is not required to re-do EV organization validation for Company A again -- it can rely on the earlier EV organization validation (for the full 13 month period), so long as the CA is certain it is really dealing with Company A.  But it must do EV validation of bar.com to prove it is owned or controlled by Company A.  Once that has been done, Company A could ask to be designated as an Enterprise RA for bar.com also.  But there is no real connection between the status of foo.com versus bar.com, other than Company A may only have to go through a single EV organization vetting.



Is that responsive to your original question?



-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Peter Bowen
Sent: Friday, August 5, 2016 9:19 AM
To: Adriano Santoni <adriano.santoni at staff.aruba.it>
Cc: CABFPub <public at cabforum.org>
Subject: Re: [cabfpub] EV Guidelines §14.2 delegation of functions to RAs etc.



I don’t think this is a very high bar.  It would seem the following process would work:



1) Customer requests EV Enterprise RA privileges for example.com, example.net, corp.example.org, example.biz, …



2) CA follows EV issuance procedures and issues a single EV certificate that has all the base domains in it.  This certificate could have a CA-defined critical extension marking it an “Enterprise RA EV” certificate or some such to prevent it from being used on a server.  I think it could even have CA-generated key pair where the CA simply threw away the private key after generation.



3) If the customer wants new domains, the CA issues a new “Enterprise RA EV” certificate using the same process.  There does not appear to be a requirement that all domains be in a single certificate, so it could just be the new domains.



I think this would meet all the requirements that are set out.



Thanks,

Peter



> On Aug 4, 2016, at 11:58 PM, Adriano Santoni <adriano.santoni at staff.aruba.it<mailto:adriano.santoni at staff.aruba.it>> wrote:

>

> Ok,. but what is (was) the ratio for that constraint?

>

> Assume the following:

>

> 1) A certain company (say "ACME Corp") owns/controls several 2nd level domains (two or more).

>

> 2) That company wants EV certificates, from a certain CA, for two or more of those domains, or possibly all of them.

>

> 3) The same company would like to be authorized as an Enterprise RA by the said CA.

>

> Now assume that the said CA, first of all, verifies (with _positive result_) that *all* of those domains are actually owned/controlled by ACME.

>

> Next, the CA verifies that all requirements for issuing the first EV certificate (for any one of those domains) are met, and therefore issues the first EV certificate.

>

> At this point, why should ACME not be allowed to act as an Enterprise RA and thus obtain by themselves (in compliance with all applicable reqs. for Enterprise RAs) the desired EV certificates for the remaining 2nd level domains ?

>

> What would be the implied risk of allowing that?

> Adriano

>

>

>

> Il 04/08/2016 23:24, Ryan Sleevi ha scritto:

>> You're saying the original certificate is xxx.example, and the new certificate is for xxx.example and yyy.example?

>>

>> No, it would not be appropriate, because yyy.example was not "contained within the domain of the original EV certificate"

>>

>> On Thu, Aug 4, 2016 at 6:19 AM, Adriano Santoni <adriano.santoni at staff.aruba.it<mailto:adriano.santoni at staff.aruba.it>> wrote:

>> All,

>>

>> I have a doubt regarding §14.2 of EV guidelines, and particularly §14.2.2 (Enterprise RAs) that reads:

>>

>> "The CA MAY contractually authorize the Subject of a specified Valid EV Certificate to perform the RA function and authorize the CA to issue additional EV Certificates at third and higher domain levels that are contained within the domain of the original EV Certificate (also known as an Enterprise EV Certificate). In such case, the Subject SHALL be considered an Enterprise RA, and the following requirements SHALL apply: ..."

>> Now, let's assume that a certain company owns/controls two or more domains, say xxx.com and yyy.net, and that the "original EV Certificate" (quoted from above) was issued by the CA for any one of those domains (say xxx.com): under these conditions, would it be okay to authorize that company to act as an Enterprise RA for the remaining 2nd-level domains that it owns/controls ?

>>

>> Based on §14.2.2, it seems not.

>>

>> Adriano

>>

>>

>> _______________________________________________

>> Public mailing list

>> Public at cabforum.org<mailto:Public at cabforum.org>

>> https://cabforum.org/mailman/listinfo/public

>>

>>

>

> --

> Cordiali saluti,

>

> Adriano Santoni

> ACTALIS S.p.A.

> (Aruba Group)

>

> _______________________________________________

> Public mailing list

> Public at cabforum.org<mailto:Public at cabforum.org>

> https://cabforum.org/mailman/listinfo/public



_______________________________________________

Public mailing list

Public at cabforum.org<mailto:Public at cabforum.org>

https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160817/13d03930/attachment-0003.html>


More information about the Public mailing list