<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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. 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. <br>
<br>
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. <br>
<br>
Jeremy<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/6/2014 9:26 PM, Ryan Sleevi
wrote:<br>
</div>
<blockquote
cite="mid:CACvaWvbQwZQ0n7kiR3XH2Nffw0aB7C_078FgL46GgD+DOH2gjQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Oct 6, 2014 at 7:21 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 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>
</div>
</blockquote>
<div><br>
</div>
<div>It's an assertion of compliance in a way that no
conforming relying party can validate.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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?</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <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>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <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>
</div>
</blockquote>
<div><br>
</div>
<div>Again, please note that requiring assertion of these
OIDs materially changes what CAs are permitted to include
in these fields.</div>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font
color="#888888"> <br>
<div>Jeremy<br>
</div>
</font></span>
<div>
<div class="h5"> <br>
<br>
<div>On 10/6/2014 8:02 PM, Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite">
<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="148e86a75f398228_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><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>
<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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>