[cabfpub] Ballot 89 Again (Publish Recommendations for the Processing of EV SSL Certificates v.2)

[Erwann Abalea]

Bonjour,

Le 22/11/2013 17:47, Moudrick M. Dadashov a écrit :
> On 11/22/2013 5:43 PM, Erwann Abalea wrote:
>> Le 22/11/2013 02:11, Moudrick M. Dadashov a écrit :
>>> Rick, I see here a problem that not all roots have policy OIDs. It's 
>>> been common understanding that roots serve more like TA containers 
>>> rather than certificates. Looks like this has changed, right?
>> EV OIDs are attached to a TA, as metadata.
>>
>> It fits the X.509/RFC5280 validation algorithm; the relying party just
>> has to set the initial-policy-set (X.509) or user-initial-policy-set
>> (RFC5280) with the OIDs declared as EV, run the validation algorithm,
>> and check the user-constrained-policy-set (X.509) or valid_policy_tree
>> (RFC5280) size. If those final sets are not empty, then the certificate
>> is EV.
> ok, thanks for clarification. It seems the the referenced validation 
> algorithm leaves quite a lot of flexibility how implementers interpret 
> the top of the chain. I'm still curious will the "final sets" for the 
> following chain:
>
> Root (no policy OID OR any_policy)
>  I
> V
> Issuing (CA supplied  EV policy OID)
>  I
> V
> EV SSL ([CA supplied  EV policy OID] OR [CAB Forum EV SSL OID] AND/OR 
> [ETSI EVCP OR ETSI EVCP+]
>
> be empty?

The Root is the TA, and you may have some metadata attached to it 
(ServerAuth/ClientAuth/emailProtection rights, one or several EV OIDs, ...).

Imagine that this root has been granted EV treatment under both your "EV 
policy OID" and the CABF EVSSL OID. The client puts "EV policy OID" and 
the CABF EV SSL OID in the user-initial-policy-set/initial-policy-set 
list, runs the path validation, and under this hierarchy, only "EV 
policy OID" will be found in the final set (the intermediate CA wasn't 
allowed to issue certificates under the CABF EV SSL OID).