[cabfpub] OIDs for DV and OV

Mads Egil Henriksveen Mads.Henriksveen at buypass.no
Fri Oct 3 09:06:41 MST 2014


Hi Dean

My understanding is that EVG requires an Issuer specific EV CP OID for EV certificates while BR requires one or more CP OIDs for OV and DV certificates. I don't see any difference between EV and OV/DV with respect to OID requirements. In addition BR defines two CP OIDs for OV and DV respectively while EVG does not define any EV CP OID.

Buypass already use the BR CP OV and DV OIDs in addition to our own specific OV and DV CP OIDs in our certificates. For EV we use our specific EV CP OID only.

We do not see any issues regarding the use of the BR specific OIDs in OV/DV-certificates.

Regards
Mads

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Dean Coclin
Sent: 2. oktober 2014 19:34
To: public at cabforum.org<mailto:public at cabforum.org>
Subject: [cabfpub] OIDs for DV and OV

Further to today's discussion on our call, I'd like to get more feedback on a proposal to make a unique standardized OID mandatory for DV and OV certificates in the Baseline Requirements. Currently we have a mandatory OID for EV certificates but optional for OV and DV.  This makes things difficult for at least two groups of constituents:


1.       Relying parties that would like to distinguish between these certificates

2.       Analysts that report on SSL certificate data who have had to issue revised reports because of cert misclassification

My proposal is for CAs to put in OID X if it's a DV certificate and OID Y if it's an OV certificate.

As Rick reminded me on the call, we currently have something like this for EV certificates (except that CAs are free to use the standard OID or define one of their own).

I'd like to hear pros/cons of this. Ryan S indicated that Google would not support such a proposal but we didn't have time to discuss the reasons.

I'm sure there are both technical and policy reasons. Personally I'd like to focus on the latter but remarks on both are welcome. This proposal doesn't require anyone to do anything with this data (i.e relying parties can choose whether or not to utilize it).

Thanks,
Dean





-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141003/8f8f40ec/attachment-0001.html 


More information about the Public mailing list