[cabfpub] OIDs for DV and OV

Ryan Sleevi sleevi at google.com
Mon Oct 6 21:12:29 MST 2014


On Oct 7, 2014 12:00 AM, "Jeremy.Rowley" <jeremy.rowley at digicert.com> wrote:
>
> If an RP's ability to confirm assertion is required, why bother requiring
domain verification?  Or require that a CA have a secure infrastructure?
There are lots of provisions in the BRs that cannot be confirmed by anyone
other than an auditor.  Fortunately, OV/DV is something RPs can look up in
the relevant CP if they have questions.

I would hardly quantify the fact that root stores are dependent upon
auditors as a good thing. Were that the case, solutions such as Certificate
Transparency would hardly be necessary.

It should come as no surprise that we are not at all keen to introduce more
required aspects of certificates that have no meaningful security value,
nor serve any programmatic purpose (and indeed, violate them)

> We could, in theory, make up a fictitious extension, but most CAs are
already using the BR policy OID.  Why not use that?  It's already in there,
meaning it won't add size to the certificate and will require a smaller
change for CAs than a brand new extension.  Plus, what is the harm to
Google?  It's not like you actually use the policy OIDs in Chrome.  Was
there a plan to start using this information?  I think the confusion is no
one is actually sure what Google's concern is other than you don't feel the
OIDs are necessary.
>

You have continued to ignore that this meaningfully changes the profiles of
certificates above the DV level to something NOT required by the BRs.

More importantly, it is not the Forum's role to make market segment
analysis easier or cheaper for technically competent organizations. Our
role should be to make things secure, and this fails to do so in any
quantifiable way, and at non trivial cost.

At the same time as we are looking at ways to optimize performance,
mandating OIDs that have zero security value, AND which further restrict
the profile of certificates unnecessarily, is a non-starter. Without such
benefits, it strikes more as CAs trying to affect the behavior of their
competitors or to aid in marketing, rather than to meaningfully address any
security concerns shared as part of the Web PKI.

> Although nothing new was presented for Google, the intended beneficiaries
of the proposal are entities like Netcraft and relying parties similar to
PayPal who have asked for this information.  I think continued discussion
might be of interest to them and other non-Google software vendors, even if
they can only chime in via the questions email.
>
> Jeremy
>
>
>
> On 10/6/2014 9:26 PM, Ryan Sleevi wrote:
>>
>>
>>
>> On Mon, Oct 6, 2014 at 7:21 PM, Jeremy.Rowley <jeremy.rowley at digicert.com>
wrote:
>>>
>>> 1) This isn't a path validation.  Instead, it's an assertion of
compliance with a particular section of the BRs.  An assertion of
compliance could be required in the intermediate as well, but, for the
time-being, the discussion is focused solely on assertions made in
end-entity certificates.  Even if the policy OID were required for
intermediates, rekeys are not necessarily required since the Forum has a
precedent of grandfathering in existing certificates.
>>
>>
>> It's an assertion of compliance in a way that no conforming relying
party can validate.
>>
>> What does it mean to issue a leaf according to the BRs, for example, if
the intermediate neither conforms to the BRs or is audited to the BRs?
>>
>> Your reply makes me feel like you're just trying to stick it in there
because it's convenient, since no conforming RP would be able to vet that
OID according to RFC 5280. If that's the case, why not just make up a
fictitious extension to signal this same data?
>>
>>>
>>>
>>> 2) I believe that point is a red-herring.  Section 11 of the BRs has
not materially changed since adoption of the BRs. Because of that, the
notBefore date is a "close enough" approximation of compliance.  Besides,
Section 11.2 of the BRs has always referred to validation of the legal
existence. An assertion of validating the legal existence is sufficient to
distinguish between Amazon.com the company and Amazon.com the domain name.
>>>
>>> Distinguishing between ETSI and Webtrust audited CAs would be an
interesting project, but I think it's out of scope for the current
discussion.
>>
>>
>> As a relying party, if I'm to take meaningful action on the distinction,
I'd like to know what degree of assurances I have on the self-claimed
conformance.
>>
>> I think your focus on Section 11 is perhaps misguided, since the
assertion of conformance to the BRs (and the version) is far more
important/relevant to RPs than the arbitrary DV/OV separation (which can
already be determined)
>>
>>>
>>>
>>> 3) I think this is speculation.  Since passage of the BRs, most CAs
seem to perform similar or nearly identical validation on organizations.
Creating more uniform rules about validation of entities was one of the
purposes in adopting the BRs. From reviewing CPSs, I think the BRs were
successful at this goal.  There may not be a value for the browsers, but I
think there are other entities that may disagree.  To Dean's point, I think
everyone recognizes that requiring assertion of the BR OID is not something
we are proposing for the benefit of the browsers.  Instead, we support it
in favor of those monitoring compliance with section 9 and 11 of the BRs
and those relying parties who are also interested in evaluating the
DV/OV/IV landscape.
>>
>>
>> Again, please note that requiring assertion of these OIDs materially
changes what CAs are permitted to include in these fields.
>>
>> Since at this point, no new information is really being shared, and the
concerns remain unaddressed, I doubt there's much more productive
discussion to be had beyond noting our opposition.
>>
>>>
>>>
>>> Jeremy
>>>
>>>
>>> On 10/6/2014 8:02 PM, Ryan Sleevi wrote:
>>>>
>>>> Jeremy,
>>>>
>>>> 1) The technical means is dependent on how the intermediate _and root_
CAs have been provisioned. As a CA offering EV certificates, no doubt
you're aware and familiar with Section 4.2.1.4 and the algorithm described
in Section 6.1 of RFC5280, which at best may be summarized as "The policy
needs to appear in the intermediate/root"
>>>>
>>>> That is, a policy appearing ONLY in a leaf is by no means an
expression of a conforming RFC5280 policy, in that the intermediate CA has
not been authorized to issue such certificates by policy. While neither a
violation of RFC5280 either (since one may believe that there exist
alternative paths that the policy IS valid for), when it comes to
programatic validation under the existing hierarchy, a relying party CANNOT
apply the RFC5280 path validation to such an "after-the-fact" OID
>>>>
>>>> 2) Your comment about Section 11.2 makes me believe you've
misunderstood the point I've made in several fora regarding the technical
value of such a policy expression. Expressing BR compliance is an act
without meaning, since there are multiple versions of the BRs (with
different technical and procedural requirements), and which are audited
under different regimes (ETSI, WebTrust) which themselves are also
versioned and cover different technical aspects.
>>>>
>>>> These permutations are what meaningfully express the issuance policies
and practices of a CA - that is, how many are conforming with BR 1.1.9
using WebTrust vs those conforming to BR 1.1.7 using ETSI, etc.
>>>>
>>>> 3) The distinction between DV (which is to say, the bare minimum of BR
requirements) and OV (which exists as a marketing hodge-podge of optional
requirements included in the BRs, but no one set mandating what OV is) is,
at it's core, a distinction that varies between CA to CA, and for which no
browser expressed support for during our most recent F2F. Just compare
Section 9.3.1 with the language in Section 9.2 to see that there's a
mismatch between the requirements of the fields.
>>>>
>>>>
>>>> Again, believing there to be NO value in the expression of a BR OID,
and believing that mandating the presence of the OID, when combined with
the language in Section 9.3.1, would have the net-effect of introducing
more restrictions on the ability of CAs to provide BR-compliant certs, this
is not something we're really keen on.
>>>>
>>>> Cheers,
>>>> Ryan
>>>>
>>>> On Mon, Oct 6, 2014 at 6:04 PM, Jeremy Rowley <
jeremy.rowley at digicert.com> wrote:
>>>>>
>>>>> Technical means exist to express the policy since the OIDs are
included in the certificate policy.  Plus, the policy is fairly stable as
section 11.2 has not had substantial changes since adoption of the baseline
requirements.
>>>>>
>>>>>
>>>>>
>>>>> How would it require a rekeying of every CA’s hierarchy if the policy
were only in the end entity certificate?  At that point, it’s only a
profile change.
>>>>>
>>>>>
>>>>>
>>>>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
On Behalf Of Ryan Sleevi
>>>>> Sent: Monday, October 6, 2014 6:51 PM
>>>>>
>>>>>
>>>>> To: Dean Coclin
>>>>> Cc: public at cabforum.org
>>>>> Subject: Re: [cabfpub] OIDs for DV and OV
>>>>>
>>>>>
>>>>>
>>>>> Dean,
>>>>>
>>>>>
>>>>>
>>>>> You have yet to demonstrate how this would not require a complete
rekeying of every CA's hierarchy, given the nature of policy OIDs, to
ultimately express a conformance to a policy that is not stable in time,
nor consistently audited.
>>>>>
>>>>>
>>>>>
>>>>> Putting aside whether or not you see value in such an expression of
policy, it's more important to just establish whether or not the means to
technically express such a policy exist and are reasonable. Then and only
then is it useful to discuss whether we should.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Oct 6, 2014 at 12:17 PM, Dean Coclin <Dean_Coclin at symantec.com>
wrote:
>>>>>
>>>>> 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]
>>>>> Sent: Thursday, October 02, 2014 8:56 PM
>>>>>
>>>>>
>>>>> To: Dean Coclin
>>>>> Cc: 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: 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
>>>>>> 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/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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>
> ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141006/226c8f42/attachment-0001.html 


More information about the Public mailing list