[cabfpub] OIDs for DV and OV

Moudrick M. Dadashov md at ssc.lt
Fri Oct 3 10:46:38 MST 2014


Hi Mads,

I noticed you use two different terms: CP OID (as a reference to CA 
document) and xV OID (as a reference to DV, OV or EV type certificate). 
Did I understand you correctly?

Thanks,
M.D.

On 10/3/2014 7:06 PM, Mads Egil Henriksveen wrote:
>
> 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
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141003/40f442b7/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3653 bytes
Desc: S/MIME Cryptographic Signature
Url : https://cabforum.org/pipermail/public/attachments/20141003/40f442b7/attachment.bin 


More information about the Public mailing list