<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/10/2013 10:40 PM, Tom Albertson
wrote:<br>
</div>
<blockquote
cite="mid:1e25b6891e3d4595b87b165f6f6c86d7@BY2PR03MB144.namprd03.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Maybe
we should start from the definition of “Trust Anchor
Managers” in the NIST IR, or the equally good TAM definition
from ETSI which I don’t have handy at the moment. TAM is a
pretty universal definition for someone who operates a trust
root repository, and I believe it should extend to new
members and categories of members we can expect such as
Oracle. It may be a little wordy and detailed (the first
sentence seems to say it all), but better to converge on
agreed terminology rather than define new ones. Can anyone
read this definition not recognize current members, or
potential future members?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">Trust
Anchor Managers (TAMs):
</span></i><span style="font-size:11.0pt">Authorities who
manage a repository of trusted Root CA Certificates. They
act on behalf of relying parties, basing their decisions on
which CAs to trust on the results of compliance audits. A
TAM sets requirements for inclusion of a CA’s root public
key in their store. These requirements are based on both
security and business needs. The TAM has a duty to enforce
compliance with these requirements, for example,
requirements around the supply of compliance audit results,
on initial acceptance of a root, and on an ongoing basis.
TAMs will follow their normal practice of requiring CAs to
submit an annual compliance audit report. It is our
intention that the requirements in this document will be
included in those compliance audit schemes. As specified in
Section 5.7, the TAM will require the CA to provide
notification of a compromise, and in response, the TAM will
take appropriate action.</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The
one problem here is the relatively recent situation with
Opera adopting the Google trusted root store, and I feel
obligated to ask: will Opera in fact maintain independent
decision-making with respect to the root store for Opera
users? I know Opera will maintain their legacy root program
for legacy version of their browser, but I haven’t heard
(can’t recall from Turkey) the status of the program for
current and future versions. Sig, can you confirm?</span></p>
</div>
</blockquote>
Opera has not adopted Google's trust store. We, just like chromium,
use the rootstore on the OS platform. I'm not aware of google
running any rootstore (perhaps on Android?), so it seems Google and
Opera are in the same boat here.<br>
<br>
Also, even though we don't run a trust store, we still take relevant
security decisions in the ssl stack and the UI level.<br>
<br>
<blockquote
cite="mid:1e25b6891e3d4595b87b165f6f6c86d7@BY2PR03MB144.namprd03.prod.outlook.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Disclaimer:
No WAY am I trying to toss out Opera or any other CABF
membership via a definition change. Convergence though has
its issues and we should sort them out. We allocate one
vote per CA regardless of how many CA brands they represent;
I don’t think we want to allocate voting among browsers if
the members behind those votes don’t exercise independent
beneficial control of their root store(s).
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Apologies
in advance to Opera folks everywhere, I’ve tried to raise
the issue as tactfully and sensitively as I can. Personally
I hope they come back and confirm they can meet the
guideline options under discussion. This is about the time
when someone should haul out the picture of me wearing the
Opera t-shirt during a past CABF face to face meeting….
</span><span
style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">All
the best, Tom<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif"">
<a class="moz-txt-link-abbreviated" href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>
[<a class="moz-txt-link-freetext" href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Ryan Sleevi<br>
<b>Sent:</b> Thursday, October 10, 2013 12:46 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:ben@digicert.com">ben@digicert.com</a><br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] Definition of "Browser" in the
Bylaws<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Regrets that I was not able to make the
call this morning. I have a few questions inline.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Oct 10, 2013 at 12:28 PM, Ben
Wilson <<a moz-do-not-send="true"
href="mailto:ben@digicert.com" target="_blank">ben@digicert.com</a>>
wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">During
today’s call we discussed the definition of
“browser” in the bylaws. This is relevant due to
Oracle’s potential interest in joining the Forum.
Back in 2009 we were looking at revising the
browser category of membership. I have pasted
excerpts from that discussion below. Today we had
a similar discussion, which ended in a suggestion
that we start this thread on the list.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The
current bylaws define a “browser” member as “[an
organization that] produces a software product
intended for use by the general public for
browsing the Web securely.”
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">One
suggestion is that we amend the definition in two
ways – (1) adding the concept of “trust agency”
and (2) broadening the definition beyond just
“browsing the web”.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm reasonably concerned about the
second definition.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We've obviously seen that there are
a set of security decisions being made for products
that operate on the Internet, but are not meant for
browsing the web. These products and decisions can
have significant negative impact on overall user
security. For example, note the challenges and
objections raised by several members with regards to
deprecating internal server names or 1024-bit RSA
keys.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While I recognize the need for CAs
to be able to engage their customer base, I would like
to see our group be able to focus on the broader
public's needs through web browsers, and let those
flow into other product lines as appropriate.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That is, if Payment Company 1 makes
terminals that only support 1024-bit RSA keys (or
MD5), I would not want to see them able to hold the
Internet's security hostage.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">For
example, the definition could be revised:<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Browser/User
Trust Agent (“Browser”): The member organization
produces a software product widely used by the
general public that uses a root store for making
trust decisions for relying parties.” <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">During
the conversation, we noted that we’re not talking
about root store operators, but systems, operating
platforms, and browsers.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Also,
to what degree should we consider the size of the
applicant, if there were several small ones that
wanted to join and become voting members, that
might have an impact, and since this is not
trivial, we are opening up this discussion on the
list. <o:p>
</o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">One
draft from 2009 was as follows: “<b>Product
Supplier</b> - The organization supplies a
product intended for use by the general public
that acts as a PKI relying party (making trust
decisions on behalf of the user by actually
processing certificates with software) to secure
information or transactions.”<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Here
are the notes of our meeting May 14, 2009:<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The
voting category [would be] expanded beyond Web
browsers to any product that acts as a PKI relying
party.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">…<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Would
the author of a Web browser with two users be
eligible for membership? Tim said that it would.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">…<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Nick
said that, because we have so few members in this
category, someone with very little market presence
could have disproportionate influence on the
ballots.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">…<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Johnathan
said that he would like to be able to apply common
sense on a case-by-case basis.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Tim
said that we have to ensure that our criteria are
objective.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Johnathan
said that the proposed criteria do not distinguish
between software that curates its own root store
and software that relies entirely on another's
root store. There are a lot of browsers that are
extensions on Mozilla. They use the same root
store and make the same EV decisions. If they were
all to join, then Mozilla may be over-represented.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Tim
suggested that it should depend upon whether their
constituents viewed them as their agent in
questions of trust. Johnathan agreed.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Aaron
said that there are browsers that use the Apple
framework to make trust decisions and that should
not be enough to disqualify them; their input as
browsers is still very important.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Johnathan
said that there is a case to be made that, if a
piece of software has meaningfully different trust
characteristics, then that is closer to a rational
test.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Yngve
said that we have encountered this situation with
Google. He wasn't sure whether Google relies on
its own root store or the platform's root store.
Johnathan said that, without speaking for Chrome,
his understanding was that they use the Microsoft
root store on windows, but make their own EV
determination, and that it is their intention to
use 'platform native' cert stores on Mac and Linux
as well.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While I realize these notes were
from 2009, I do want to chime in that we do ship a set
of trust roots for Android, Chrome for iOS, ChromeOS,
as well as other consumer products such as the Google
Chromecast. Additionally, as noted in our root store
policy, we reserve the right to remove any certificate
from being trusted, even if trusted by the underlying
OS root store, if we believe the inclusion impacts the
security of our users. See
<a moz-do-not-send="true"
href="http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-Removal-of-Trust">http://www.chromium.org/Home/chromium-security/root-ca-policy#TOC-Removal-of-Trust</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As such, I would presumably see
Opera in a similar situation as Google, in which the
products they ship may derive their primary trust
value from the decisions made as part of the Chromium
projects, but for which they reserve the right
(organizationally) to remove or modify such trusts as
appropriate to the security of their users.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Bjørn
said that he would not want to accept anyone who
is simply 'skinning' Internet Explorer, for
instance.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Tim
said that the wording we have is 'acts as a
relying party'. Bjørn said that it is slightly
vague. Yngve suggested 'acting as a PKI relying
party, making trust decisions on behalf of the
user'. Bjørn agreed. Tim said that he would
incorporate that clause, and if there were no
objections he would take it to ballot.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></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">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><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ryan<o:p></o:p></p>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>