[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