[cabfpub] OIDs for DV and OV

Ryan Sleevi sleevi at google.com
Mon Oct 6 08:32:39 MST 2014


On Oct 6, 2014 7:36 AM, "Robin Alden" <robin at comodo.com> wrote:
>
> Hi Dean,
>
>                 Comodo already use the DV and OV policy OIDs defined at
https://cabforum.org/object-registry/
>
> We have no objection to other CAs following suit.
>
>
>
> I am of the opinion that if a CA has policy OIDs which identify which of
the two defined options in the BRs you followed for subject information
then it would be better that we all use the same OIDs.
>
>
>
> Ryan’s objection is religious, not technical.
>

There are significant and nontrivial technical concerns noted and
unaddressed.

>
>
> Regards
> Robin
>
>
>
>
>
>
>
>
>
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Dean Coclin
> Sent: 02 October 2014 18:34
>
> To: 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/20141006/cff4a71e/attachment-0001.html 


More information about the Public mailing list