[cabfpub] OIDs for DV and OV

Moudrick M. Dadashov md at ssc.lt
Tue Oct 7 15:16:52 MST 2014


Hi Kelvin,

On 10/8/2014 12:40 AM, Kelvin Yiu wrote:
>
> I don't have a problem if a CA chooses to use the BR OIDs instead of 
> their own OIDs to identify BR related certificate policies as long as 
> it is consistently used in the certificate chain. My concern is with 
> cases that do not follow RFC 5280. For example, when BR OIDs are added 
> to end entity certificates in addition to CA specific OIDs when the CA 
> certificate explicitly contain only CA specific OIDs.
>
I realized this was a real use case where a single CP presents different 
types of certificates and adding a xV OID makes it just more clear. Are 
you saying this doesn't follow RFC 5280?

Thanks,
M.D.
>
> Kelvin
>
> *From:*Ben Wilson [mailto:ben.wilson at digicert.com]
> *Sent:* Tuesday, October 7, 2014 12:56 PM
> *To:* Kelvin Yiu; Dean Coclin; i-barreira at izenpe.net; 
> sleevi at google.com; public at cabforum.org
> *Subject:* RE: [cabfpub] OIDs for DV and OV
>
> I don't think that the use of a policy OID in a certificate 
> necessarily "ignores" "rules" around policy processing in RFC5280.   I 
> don't think anyone has requested that we require a policy constraints 
> extension.  We're only talking about putting a policy OID in a BR 
> certificate, along with any other policy OIDs the CA cares to insert. 
>  The primary purpose of the CP OID is to assert the policy under which 
> the certificate has been issued.  It is not to build a path up the 
> chain or constrain processing---those are secondary considerations.  I 
> agree about the necessity of putting the CP OID in your CPS and of 
> being audited for compliance with the policy (the BRs and EVGs 
> acknowledge that a point-in-time / readiness audit would be acceptable).
>
> The BRs is the closest thing to a Certificate Policy that currently 
> exists.  It is ""A named set of rules that indicates the applicability 
> of a certificate to a particular community and/or class of application 
> with common security requirements."  Section D.7.1.6 of the PKI 
> Assessment Guidelines states,  "The certificate policies extension is 
> intended to convey policy information or references to policy 
> information.  Specifically, a PKI can place the object identifier of a 
> certificate policy within the certificate policies extension.  The 
> object identifier can enable a relying party to configure its systems 
> to cause its software to look for the OID of an acceptable certificate 
> policy, permit the transaction to continue if the system finds the OID 
> of an acceptable CP in the certificate, and halt the transaction if it 
> does not."   So while it enables functionality, it doesn't require it, 
> in case that is a browser concern.
>
> *From:*public-bounces at cabforum.org 
> <mailto:public-bounces at cabforum.org> 
> [mailto:public-bounces at cabforum.org] *On Behalf Of *Kelvin Yiu
> *Sent:* Tuesday, October 7, 2014 1:03 PM
> *To:* Dean Coclin; i-barreira at izenpe.net 
> <mailto:i-barreira at izenpe.net>; sleevi at google.com 
> <mailto:sleevi at google.com>; public at cabforum.org 
> <mailto:public at cabforum.org>
> *Subject:* Re: [cabfpub] OIDs for DV and OV
>
> FWIW, Microsoft provides an API on Windows 7 and later to determine 
> whether a certificate is EV or not, according to Microsoft's root CA 
> program.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa377163(v=vs.85).aspx 
> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa377163%28v=vs.85%29.aspx> 
>
>
> I think it is a bad idea to assert BR OIDs for xV compliance by 
> ignoring the rules around certificate policies processing in RFC 5280. 
> While I understand the desire to have a source of information to 
> identify xV certificates, the value is questionable to me unless the 
> information is also in the CPS and the appropriate audit has taken place.
>
> Kelvin
>
> *From:*public-bounces at cabforum.org 
> <mailto:public-bounces at cabforum.org> 
> [mailto:public-bounces at cabforum.org] *On Behalf Of *Dean Coclin
> *Sent:* Tuesday, October 7, 2014 9:12 AM
> *To:* i-barreira at izenpe.net <mailto:i-barreira at izenpe.net>; 
> sleevi at google.com <mailto:sleevi at google.com>; public at cabforum.org 
> <mailto:public at cabforum.org>
> *Subject:* Re: [cabfpub] OIDs for DV and OV
>
> Hi Inigo,
>
> Yes, I did create such a sheet and I've enclosed it here. And I think 
> it proves my point that the current situation exacerbates the problem, 
> making it difficult for one to programmatically determine what type of 
> cert they are encountering.
>
> Dean
>
> *From:*i-barreira at izenpe.net <mailto:i-barreira at izenpe.net> 
> [mailto:i-barreira at izenpe.net]
> *Sent:* Tuesday, October 07, 2014 12:44 AM
> *To:* Dean Coclin; sleevi at google.com <mailto:sleevi at google.com>; 
> public at cabforum.org <mailto:public at cabforum.org>
> *Subject:* RE: [cabfpub] OIDs for DV and OV
>
> Dean, time ago you created an Excel sheet with those CAs that use 
> their own OIDs for DV and OV, similar to what was done with EV. The 
> intention of that list was to also have another "source" of 
> information for considering those certs as DV or OV for the browsers 
> in case they need it.
>
> BTW, Izenpe uses their own OIDs plus the CABF ones.
>
> *Iñigo Barreira*
> Responsable del Área técnica
> i-barreira at izenpe.net <mailto:i-barreira at izenpe.net>
>
> 945067705
>
> Descripción: cid:image001.png at 01CE3152.B4804EB0
>
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta 
> egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada 
> (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, 
> korreo honi erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o 
> confidencial a la que solo tiene derecho a acceder el destinatario. Si 
> usted lo recibe por error le agradeceriamos que no hiciera uso de la 
> informacion y que se pusiese en contacto con el remitente.
>
> *De:*public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> 
> [mailto:public-bounces at cabforum.org] *En nombre de *Dean Coclin
> *Enviado el:* lunes, 06 de octubre de 2014 21:17
> *Para:* Ryan Sleevi; public at cabforum.org <mailto:public at cabforum.org>
> *Asunto:* Re: [cabfpub] OIDs for DV and OV
>
> So I get the part that Chrome (and likely other browsers in the CA/B 
> forum) don't intend to distinguish DV and OV certs in any way. Got 
> that. Not a point of contention. In fact, I knew that when I started 
> this thread.  So no need to go down that path anymore. Having 
> different OIDs does not oblige a browser do anything.
>
> I would have expected more negative commentary from CAs but so far 
> there has been none. And only 1 browser has chimed in.
>
> However, browsers are not the only application that use SSL 
> certificates. There are others out there and I distinctly recall a 
> conversation about 2-3 years ago where Paypal (a CA/B member) 
> explicitly asked that these OIDs be mandatory. Brad stated that their 
> security group had deemed DV certs to be a security threat to their 
> ecosystem and wanted an easy programmatic way to distinguish them. At 
> the time, there was some pushback (I don't believe from browsers) and 
> the OIDs ended up being optional.
>
> It looks as if some CAs do use OIDs in their DV and OV certs but some 
> don't use the CA/B Forum OIDs (rather their own). This makes it 
> difficult to apply a uniform decision process.
>
> Certs conforming to policy and issued correctly are one aspect that 
> some folks are looking for. The type of certificate is another. One 
> that has not been vetted is different from one that has some vetting 
> completed (other security issues being equal). Perhaps that benefit is 
> not tangible to some but it certainly is to others. I can spew some 
> stats on DV cert use and fraud but that will just muddle this thread 
> so I'll save it for another day.
>
> Why do browsers care one way or the other if other parties want to 
> make this distinction? The CA/B Forum has defined different baseline 
> standards for these types of certs. Why not make transparency around 
> those standards easy for those that want to draw a distinction?
>
> Certainly would love to hear from some other interested parties.
>
> Thanks,
>
> Dean
>
> *From:*Ryan Sleevi [mailto:sleevi at google.com] 
> <mailto:[mailto:sleevi at google.com]>
> *Sent:* Thursday, October 02, 2014 8:56 PM
> *To:* Dean Coclin
> *Cc:* public at cabforum.org <mailto:public at cabforum.org>
> *Subject:* Re: [cabfpub] OIDs for DV and OV
>
> On Thu, Oct 2, 2014 at 5:31 PM, Dean Coclin <Dean_Coclin at symantec.com 
> <mailto:Dean_Coclin at symantec.com>> wrote:
>
> Thanks for the response and pointers. I've read through the threads 
> but still have additional questions/comments. I'll readily admit that 
> I don't understand all the commentary in the Mozilla threads so I 
> apologize if these questions sound somewhat naïve. Happy to be educated:
>
> You've heard repeatedly from several browsers about an explicit 
> non-goal of distinguishing DV and OV. As the Forum is comprised of CAs 
> and Browsers, do we have any Browsers that wish to make such a 
> distinction? If not, it would be wholly inappropriate for the Forum to 
> require it.
>
> >>I haven't heard of any browsers that want to make that distinction 
> (yet). It is my understanding that the Forum BRs do require an OID for 
> EV certs. So why is it "inappropriate" for the Forum to require OIDs 
> for DV/OV?
>
> Browsers have agreed to make a distinction between EV and !EV, so have 
> required there be a way to detect that.
>
> Browsers have not agreed that there is a distinction between DV or OV, 
> nor is there a need to detect the difference.
>
> That the browsers have required (effectively all stores at this point, 
> AFAIK) is that the root program members be BR compliant. So any new 
> certs issued (technically, independent of the notBefore, and we know 
> CAs regularly backdate from time of issuance, but it's a rough 
> heuristic) are, by definition, BR compliant.
>
>     If there are non-browser relying parties interested in such
>     distinctions, the CA can always provide such distinctions themselves.
>
>     >>Can you elaborate on what you mean by this? If there's another way to
>     accomplish the end result, happy to explore further. But it would
>     have to be uniform among all CAs that issue these certs.
>
> I don't see why it needs to be uniform.
>
>
> The requirement as to what shape it takes is dictated by the relying 
> party applications.
>
> The browsers, as relying party applications, do not and have not yet 
> cared about the shape of DV and OV, and as per our recent F2F, aren't 
> really keen to either.
>
> So having the browsers dictate the shape of the solution seems 
> unnecessary, and an issue for these relying party applications (e.g. 
> Netcraft) to work with CAs.
>
>     As someone very keen on programatic checks and detection for
>     misissuance, there's no question that this would NOT meaningfully
>     help address the concerns we see.
>
>     >>I wasn't suggesting that this addition would in any way help you
>     with your programmatic checks for mis-issuance.  Rather, it would
>     make the task for organizations like Netcraft, EFF or others that
>     tabulate statistics on various types of certificates easier to do.
>     Is that not the case?
>
> Not really. These organizations are interested in the same discussions 
> and distinctions we are - what are the certificates being issued and 
> do they conform to the policies that they're supposed to.
>
> We've established that there's no 'uniform' definition of what 
> constitutes OV, only that the BR requires certain vetting steps for 
> certain subject fields that are OPTIONAL. CAs have taken these and 
> marketed them as OV, but there's no such distinction as a level, nor a 
> particular profile spelled out in the appendices as to what 
> constitutes a "DV" vs "OV".
>
> If that was the only degree of distinction required, it's just as easy 
> as checking the Subject fields for any of the OPTIONAL fields.
>
>     That is, there would need to be an OID _per revision_ of the BRs,
>     to indicate "which" version of the BRs something was complying to.
>
>     >>Fully admit that I don't understand how this works. But wouldn't that
>     also be the case for EV (which currently requires this OID)?
>
> YES! And it's one of the many reasons why EV is somewhat muddled for 
> programatic checks or distinctions. And yet this is also necessary 
> because any change in policy, by definition, necessitates a change in 
> OID to (meaningfully) reflect that. And that constitutes rolling a new 
> hierarchy (and updating browsers' lists of recognized EV OIDs)
>
>     I'm just trying to suggest a  way that someone can say: X is a DV
>     cert, Y is an OV cert, Z is an EV cert without a doubt. If OIDs
>     are not the place to do that, is there another mechanism available?
>     I'm sure you are familiar with Ryan Hurst's blog on how difficult
>     the task currently is.
>
> I am (you're talking about http://unmitigatedrisk.com/?p=203 
> <http://unmitigatedrisk.com/?p=203> in particular). But I'm also not 
> supportive of encouraging a distinction that we neither recognize nor 
> have plans to recognize, and especially not supportive of mandating 
> such distinctions.
>
> This is especially true, as these distinctions don't offer any 
> tangible security benefits to the Web, as previously discussed.
>
> If we go to the point of mandating anything additional in 
> certificates, which requires a variety of changes in processes, 
> profiles, and CPSes, I want it to have meaningful security value. This 
> change - which, as has been shown by the development of audit 
> standards and then the eventual incorporation of those audit standards 
> into the root programs, and then FINALLY the *enforcement* of those 
> audit standards of the root programs - would take several years, at 
> BEST, to deploy, and would communicate nothing of actionable value. 
> It's a hard sell.
>
>
>     Thanks,
>     Dean
>
>     *From:*public-bounces at cabforum.org
>     <mailto:public-bounces at cabforum.org>
>     [mailto:public-bounces at cabforum.org
>     <mailto:public-bounces at cabforum.org>] *On Behalf Of *Ryan Sleevi
>     *Sent:* Thursday, October 02, 2014 3:37 PM
>     *To:* Dean Coclin
>     *Cc:* public at cabforum.org <mailto:public at cabforum.org>
>     *Subject:* Re: [cabfpub] OIDs for DV and OV
>
>     On Thu, Oct 2, 2014 at 10:33 AM, Dean Coclin
>     <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com>> wrote:
>
>     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
>
>     You've heard repeatedly from several browsers about an explicit
>     non-goal of distinguishing DV and OV. As the Forum is comprised of
>     CAs and Browsers, do we have have any Browsers that wish to make
>     such a distinction?
>
>     If not, it would be wholly inappropriate for the Forum to require
>     it. If there are non-browser relying parties interested in such
>     distinctions, the CA can always provide such distinctions themselves.
>
>         2.Analysts that report on SSL certificate data who have had to
>         issue revised reports because of cert misclassification
>
>     As mentioned on the call, this has been discussed with Mozilla in
>     the past -
>     https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/hEOQK-ubGRcJ
>
>     As someone very keen on programatic checks and detection for
>     misissuance, there's no question that this would NOT meaningfully
>     help address the concerns we see.
>
>     That is, there would need to be an OID _per revision_ of the BRs,
>     to indicate "which" version of the BRs something was complying to.
>
>     I would hope that
>     https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/2tRUS444krwJ
>     would capture some of these concerns more fully.
>
>     Finally, to do anything meaningful with this in all major clients,
>     it would require that CAs redo their certificate hierarchy, as
>     policy OIDs are inherited. That's a silly thing, especially when
>     CAs are still struggling to migrate from SHA-1 to SHA-256 in their
>     intermediates.
>
>         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 <mailto:Public at cabforum.org>
>         https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> 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/20141008/a2fb2373/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 19121 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20141008/a2fb2373/attachment-0001.png 
-------------- 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/20141008/a2fb2373/attachment-0001.bin 


More information about the Public mailing list