Subject: [pkix] Extended Validation Certificate OIDs

From: "Piyush Jain" <[email-masked]>
Date: Fri, 29 Mar 2013 16:42:47 -0700

Hi list,

It seems that every CA that issues an EV certificate today uses a different
certificate policy OID to indicate extended validation.
Is there a reason why EV OID is not standardized?

Thanks
-Piyush

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 30 Mar 2013 01:39:22 +0100

> Is there a reason why EV OID is not standardized?

Each browser able to recognize EV certificates enable each Root  
*individually* as being able to issue EV certificates, this is based on  
evaluation of audits for the Root CA and agreements between the Root CA  
and the browser vendor. For that reason it does not really matter which  
OID is used, so each CA can obtain their own OID. It is also not desirable  
that any CA can insert an OID and be automatically considered to have  
issued an EV certificate.

In addition, theoretically, every subordinate CA under an EV-enabled Root  
can be provided with a distinct EV-OID different from the EV-OID(s) used  
by any other subordinate CA under that root, with the EV-OID being  
filtered in the certificate of the subordinate CA. This system (which is  
not actually in use) would allow a CA to ask the browsers to turn off EV  
for a specific subordinate CA that is (for whatever reason) no longer  
qualified to issue EV certificates, without affecting the other  
subordinate CAs or revoking that subordinate CA's certificate.

At present I am aware of one case where a CA is using two EV-OIDs, one for  
general sites, and one for a special class of certificates issued to  
government sites in that country.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 29 Mar 2013 18:08:40 -0700

Thank Yngve.

Am I correct to assume that the EV certificates are only issued to servers
and browsers are the only known clients that make use of such certificates?
I'm investigating the possibility of making use of EV status in closed
environments where trust in the CA is established through a bridge and
direct mapping of CA root to EV OID is not available to the RP.

I guess the correct approach in this case would be to define yet another EV
OID and propagate the EV information through policy mapping extensions in
certs issued by the bridge.

-Piyush

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yngve N. Pettersen
> Sent: Friday, March 29, 2013 5:39 PM
> To: [email-masked]
> Subject: Re: [pkix] Extended Validation Certificate OIDs
> 
> > It seems that every CA that issues an EV certificate today uses a
> > different certificate policy OID to indicate extended validation.
OID
> is used, so each CA can obtain their own OID. It is also not desirable
that any
> CA can insert an OID and be automatically considered to have issued an EV
> certificate.
> 
by
> any other subordinate CA under that root, with the EV-OID being filtered
in
> the certificate of the subordinate CA. This system (which is not actually
in
> use) would allow a CA to ask the browsers to turn off EV for a specific
> subordinate CA that is (for whatever reason) no longer qualified to issue
EV
> certificates, without affecting the other subordinate CAs or revoking that
> subordinate CA's certificate.
> 
government
> sites in that country.
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Sat, 30 Mar 2013 03:01:37 +0100

> and browsers are the only known clients that make use of such  

There is also an EV spec for Object signing, and it is AFAIK used by  
security features in Windows 8.

> direct mapping of CA root to EV OID is not available to the RP.

It is generally not possible to create your own private EV Root CA and get  
it accepted by browsers, unless you go through the route of getting your  
Root embedded in the client Rootstores, which require annual audits under  
WebTrust or ETSI for both Normal CA and Extended Validation.

The only client that I am aware of that allow local control of the EV OID  
information is Windows Vista (MSIE) and newer, through special enterprise  
configuration mechanisms.

In all other cases I believe the information is hardcoded in the  
executable, or as in the case of Opera, distributed in a digitally signed  
format. These restrictions exist because of the strict requirements for  
being allowed to issue EV certificates and to enable the EV indication.

As for the most realistic options for acceptance in all browsers, you  
probably need to either establish an EV-enabled enterprise account with  
one of the recognized CAs or buy a Subordinate CA certificate from one  
that is allowed to issue EV certificates (which would require the full  
audit regime)

-- 
Sincerely,
Yngve N. Pettersen