[cabfpub] OIDs for DV and OV
Dean Coclin
Dean_Coclin at symantec.com
Tue Oct 21 00:45:32 UTC 2014
On last week’s CA/B Forum call, we had an additional discussion on this
topic.
>From my understanding, according to RFC 5280, this is OK:
Root -> Intermediate (with no policy OIDs) -> End-entity
(some policy OID)
Or this:
Root -> Intermediate (with special ‘any policy OID’) ->
End-entity (some policy OID)
But this is not valid:
Root -> Intermediate (with policy OID A) -> End-entity (with
policy OIDs A and B)
The policy OIDs are supposed to “flow down” from intermediate to end-entity.
The end-entity shouldn’t contain a policy OID that isn’t in the
intermediate, except in the first two special cases above.
Now, we have a list of what some current members are doing here:
https://cabforum.org/object-registry/, which presumable agrees with the
above rules (hopefully?). I’d like to add more data to the list so if your
CA is not listed, please email me the OIDs you use and I’ll add them.
Returning to the previous discussion, Ryan made a comment that CAs would
have to “re-do” their hierarchies to implement these OIDs but presumably he
meant if they don’t follow the protocol above, is that right?
Thanks,
Dean
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Erwann Abalea
Sent: Friday, October 10, 2014 12:02 PM
To: public at cabforum.org
Subject: Re: [cabfpub] OIDs for DV and OV
I'm a bit late, sorry.
Le 09/10/2014 20:26, Dean Coclin a écrit :
[...]
What I fail to understand from this discussion is how anything is “broken”
or “non-compliant” if everyone is already doing something as described
above?
A browser can't programmatically "tag" a certificate as being OV/DV based on
its policyId, because sometimes this policyId is not present in its chain of
issuing CAs.
For example, take the first 3 CABF members as listed on the website, click
on their link (modify it to be https if necessary). Those first 3 have an
incoherent policyId chain (right of "=>" is the resulting set of acceptable
policies):
- Actalis:
Baltimore Cybertrust Root is limited to anyPolicy => { anyPolicy }
Actalis Authentication CA G2 is limited to 1.3.6.1.4.1.6334.1.0 =>
{ 1.3.6.1.4.1.6334.1.0 }
portal.actalis.it is 1.3.159.1.4.1 => { empty }
- ANF:
Baltimore Cybertrust Root is limited to anyPolicy => { anyPolicy }
DigiCert High Assurance EV Root CA is limited to
1.3.6.1.4.1.6334.1.0 => { 1.3.6.1.4.1.6334.1.0 }
DigiCert High Assurance CA-3 is limited to
2.16.840.1.114412.1.3.0.2 => { empty }
anf.es is 2.16.840.1.114412.1.1 => { empty }
- AS Sertifitseerimiskeskus:
KLASS3-SK 2010 has no CertificatePolicies extension => { empty }
www.sk.ee is 1.3.6.1.4.1.10015.7.1.2.5 => { empty }
Based on X.509/RFC5280 validation algorithm, these subscriber certificates
can at most be valid but for an empty set of policies. They are RFC5280
compliant, but either invalid or valid for no identified policy.
I'm not name dropping, just took the first three. Unfortunately, I see this
more often when reviewing Mozilla inclusion requests.
Thanks,
Dean
From: Kelvin Yiu [ <mailto:kelviny at exchange.microsoft.com>
mailto:kelviny at exchange.microsoft.com]
Sent: Thursday, October 09, 2014 11:13 AM
To: Moudrick M. Dadashov; Ben Wilson; Dean Coclin;
<mailto:i-barreira at izenpe.net> i-barreira at izenpe.net;
<mailto:sleevi at google.com> sleevi at google.com; <mailto:public at cabforum.org>
public at cabforum.org
Subject: RE: [cabfpub] OIDs for DV and OV
AFAIK, the additional OIDs would not be compliant with RFC 5280.
Kelvin
From: Moudrick M. Dadashov [ <mailto:md at ssc.lt> mailto:md at ssc.lt]
Sent: Tuesday, October 7, 2014 3:17 PM
To: Kelvin Yiu; Ben Wilson; Dean Coclin; <mailto:i-barreira at izenpe.net>
i-barreira at izenpe.net; <mailto:sleevi at google.com> sleevi at google.com;
<mailto:public at cabforum.org> public at cabforum.org
Subject: Re: [cabfpub] OIDs for DV and OV
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>
mailto:ben.wilson at digicert.com]
Sent: Tuesday, October 7, 2014 12:56 PM
To: Kelvin Yiu; Dean Coclin; <mailto:i-barreira at izenpe.net>
i-barreira at izenpe.net; <mailto:sleevi at google.com> sleevi at google.com;
<mailto:public at cabforum.org> 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: <mailto:public-bounces at cabforum.org> 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; <mailto:i-barreira at izenpe.net> i-barreira at izenpe.net;
<mailto:sleevi at google.com> sleevi at google.com; <mailto:public at cabforum.org>
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%28v=vs.85%
29.aspx>
http://msdn.microsoft.com/en-us/library/windows/desktop/aa377163(v=vs.85).as
px
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: <mailto:public-bounces at cabforum.org> 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: <mailto:i-barreira at izenpe.net> i-barreira at izenpe.net;
<mailto:sleevi at google.com> sleevi at google.com; <mailto:public at cabforum.org>
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: <mailto:i-barreira at izenpe.net> 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; <mailto:sleevi at google.com> sleevi at google.com;
<mailto:public at cabforum.org> 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
<mailto:i-barreira at izenpe.net> 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: <mailto:public-bounces at cabforum.org> 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; <mailto:public at cabforum.org> 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:[mailto:sleevi at google.com]>
[mailto:sleevi at google.com]
Sent: Thursday, October 02, 2014 8:56 PM
To: Dean Coclin
Cc: <mailto:public at cabforum.org> 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>
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 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: <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org
[mailto: <mailto:public-bounces at cabforum.org> public-bounces at cabforum.org]
On Behalf Of Ryan Sleevi
Sent: Thursday, October 02, 2014 3:37 PM
To: Dean Coclin
Cc: <mailto:public at cabforum.org> 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>
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/hEOQ
K-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/2tRU
S444krwJ 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
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
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: <http://lists.cabforum.org/pipermail/public/attachments/20141020/21640083/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 19121 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141020/21640083/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6130 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141020/21640083/attachment-0001.p7s>
More information about the Public
mailing list