<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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. <br>
<br>
Distinguishing between ETSI and Webtrust audited CAs would be an
interesting project, but I think it's out of scope for the current
discussion.<br>
<br>
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. <br>
<br>
<div>Jeremy<br>
</div>
<br>
<br>
<div class="moz-cite-prefix">On 10/6/2014 8:02 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvZXDYVnfNw53LP-LJQVi6t2+uar9KWzDztKJxpuNSbbCg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">Jeremy,
<div><br>
</div>
<div>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"</div>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Ryan</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Oct 6, 2014 at 6:04 PM, Jeremy
Rowley <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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. </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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. </span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
name="148e8231547c4e29__MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></a></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>
[mailto:<a moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org"
target="_blank">public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Ryan Sleevi<br>
<b>Sent:</b> Monday, October 6, 2014 6:51 PM</span></p>
<div>
<div class="h5"><br>
<b>To:</b> Dean Coclin<br>
<b>Cc:</b> <a moz-do-not-send="true"
href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a><br>
<b>Subject:</b> Re: [cabfpub] OIDs for DV and OV</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Dean,</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Mon, Oct 6, 2014 at
12:17 PM, Dean Coclin <<a
moz-do-not-send="true"
href="mailto:Dean_Coclin@symantec.com"
target="_blank">Dean_Coclin@symantec.com</a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.
</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
would have expected more negative
commentary from CAs but so far there has
been none. And only 1 browser has chimed
in.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.
</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.
</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.
</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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?</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Certainly
would love to hear from some other
interested parties.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks,</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Dean</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Ryan Sleevi [mailto:<a
moz-do-not-send="true"
href="mailto:sleevi@google.com"
target="_blank">sleevi@google.com</a>]
<br>
<b>Sent:</b> Thursday, October 02, 2014
8:56 PM</span></p>
<div>
<div>
<p class="MsoNormal"><br>
<b>To:</b> Dean Coclin<br>
<b>Cc:</b> <a moz-do-not-send="true"
href="mailto:public@cabforum.org"
target="_blank">public@cabforum.org</a><br>
<b>Subject:</b> Re: [cabfpub] OIDs for
DV and OV</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Thu, Oct
2, 2014 at 5:31 PM, Dean Coclin
<<a moz-do-not-send="true"
href="mailto:Dean_Coclin@symantec.com"
target="_blank">Dean_Coclin@symantec.com</a>>
wrote:</p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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:</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>>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?</span></p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Browsers
have agreed to make a
distinction between EV and
!EV, so have required there be
a way to detect that.</p>
</div>
<div>
<p class="MsoNormal">Browsers
have not agreed that there is
a distinction between DV or
OV, nor is there a need to
detect the difference.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in
0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal">If
there are non-browser
relying parties interested
in such distinctions, the
CA can always provide such
distinctions themselves.</p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>>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.</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I don't see
why it needs to be uniform.</p>
</div>
<div>
<p class="MsoNormal"><br>
The requirement as to what
shape it takes is dictated by
the relying party
applications.</p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in
0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>>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?</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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".</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in
0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">>>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)?</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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)</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in
0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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?<br>
I’m sure you are
familiar with Ryan
Hurst’s blog on how
difficult the task
currently is.</span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I am
(you're talking about
<a moz-do-not-send="true"
href="http://unmitigatedrisk.com/?p=203"
target="_blank">http://unmitigatedrisk.com/?p=203</a>
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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">This is
especially true, as these
distinctions don't offer any
tangible security benefits to
the Web, as previously
discussed.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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
<b>enforcement</b> 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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in
0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><br>
Thanks,<br>
Dean</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a
moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>
[mailto:<a
moz-do-not-send="true"
href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Ryan
Sleevi<br>
<b>Sent:</b> Thursday,
October 02, 2014 3:37 PM<br>
<b>To:</b> Dean Coclin<br>
<b>Cc:</b> <a
moz-do-not-send="true"
href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a><br>
<b>Subject:</b> Re:
[cabfpub] OIDs for DV
and OV</span></p>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal"> </p>
<div>
<p
class="MsoNormal">On
Thu, Oct 2, 2014
at 10:33 AM,
Dean Coclin <<a
moz-do-not-send="true" href="mailto:Dean_Coclin@symantec.com"
target="_blank">Dean_Coclin@symantec.com</a>>
wrote:</p>
<div>
<div>
<p
class="MsoNormal">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:</p>
<p
class="MsoNormal"> </p>
<p>1.<span
style="font-size:7.0pt">
</span>Relying
parties that
would like to
distinguish
between these
certificates</p>
</div>
</div>
<div>
<p
class="MsoNormal">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?</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">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.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc
1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p>2.<span
style="font-size:7.0pt">
</span>Analysts
that report on
SSL
certificate
data who have
had to issue
revised
reports
because of
cert
misclassification</p>
</div>
</div>
</blockquote>
<div>
<p
class="MsoNormal">As
mentioned on
the call, this
has been
discussed with
Mozilla in the
past - <a
moz-do-not-send="true"
href="https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/hEOQK-ubGRcJ"
target="_blank">https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/hEOQK-ubGRcJ</a></p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">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.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">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. </p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">I
would hope
that <a
moz-do-not-send="true"
href="https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/2tRUS444krwJ"
target="_blank">https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/2tRUS444krwJ</a>
would capture
some of these
concerns more
fully.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<p
class="MsoNormal">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.</p>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc
1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p
class="MsoNormal"> </p>
<p
class="MsoNormal">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.</p>
<p
class="MsoNormal"> </p>
<p
class="MsoNormal">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).</p>
<p
class="MsoNormal"> </p>
<p
class="MsoNormal">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.</p>
<p
class="MsoNormal"> </p>
<p
class="MsoNormal">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).</p>
<p
class="MsoNormal"><br>
Thanks,<br>
Dean</p>
<p> </p>
<p> </p>
<p
class="MsoNormal"> </p>
</div>
</div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing
list<br>
<a
moz-do-not-send="true"
href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a
moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a></p>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>