<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><font face="Calibri">We fully agree and we endorse the proposal.</font></p>
<p><font face="Calibri">In addition, we propose to amend the BRs so
to make it clear what address (company legal/registration
address, mail delivery address, actual headquarter, main
operations address, any operations address...) MAY or SHALL be
included in an OV/IV certificate, as we deem the current wording
in §3.2.2.1 is ambiguous.</font></p>
<p><font face="Calibri">Adriano</font></p>
<p><font face="Calibri"></font><br>
</p>
<br>
<div class="moz-cite-prefix">Il 25/02/2017 07:06, Kirk Hall via
Public ha scritto:<br>
</div>
<blockquote
cite="mid:57494d01c71442bfb33b2ec4c2c0620f@PMSPEX04.corporate.datacard.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
.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="MsoPlainText">+1 Peter. Well said. <o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Wow, I didn't expect it, but thanks for
posting the links to my RSA Security Conference presentation
last week on the importance of website identity for user
security. All the CA Security Council (CASC) members have
endorsed the following Five Principles of TLS Certificate
Identity - see page 33 of the following White Paper, if you
are interested:
<a moz-do-not-send="true"
href="https://casecurity.org/wp-content/uploads/2017/02/Use-of-Identity-in-SSL-TLS-Certs-for-User-Safety-Final-2017-02-17.pdf">https://casecurity.org/wp-content/uploads/2017/02/Use-of-Identity-in-SSL-TLS-Certs-for-User-Safety-Final-2017-02-17.pdf</a>
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">1. Identity in
TLS server certs should be used by browsers as a proxy for
greater user safety<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">2. CAs should
vet their customers to the highest identity level possible<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">3. OV certs
should receive their own browser UI different from DV certs to
show user safety<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">4. EV certs
should continue to receive a separate browser UI from OV and
DV certs to show greater user safety<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in">5. Browsers
should agree on common UI security indicators, avoid changes
to UI, and work with others to educate users about the meaning
of the common UI security indicators for greater user safety.<o:p></o:p></p>
<p class="MsoPlainText" style="margin-left:.5in"><o:p></o:p></p>
<p class="MsoPlainText">These principles have been endorsed by
Comodo, DigiCert, Entrust Datacard, GlobalSign, GoDaddy,
Symantec, Trustwave. If any other members of the Forum (CA or
browser) want to add their endorsement, please let me know.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Here is an executive summary of the same
White Paper: <a moz-do-not-send="true"
href="https://casecurity.org/wp-content/uploads/2017/02/Executive-Summary-Use-of-Identity-in-SSL-TLS-Certs-for-User-Safety-Final-2017-02-17.pdf">https://casecurity.org/wp-content/uploads/2017/02/Executive-Summary-Use-of-Identity-in-SSL-TLS-Certs-for-User-Safety-Final-2017-02-17.pdf</a>
<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">In addition, there is a long list of
major enterprise website owners who have also endorsed the use
(and display) of website identity for user security. See
Slide 49 of the attached pdf, which I presented at the RSA
Security Conference last week. Oddly enough, no one has ever
asked enterprise website owners what they would like to see in
the browser UI to protect their brands and their customers -
but when asked, they have indicated they would like to see
confirmed identity data displayed to users. Peter posted the
link to the audio of my presentation, but here it is again:
<a moz-do-not-send="true"
href="https://www.rsaconference.com/videos/100-encrypted-web-new-challenges-for-tls">https://www.rsaconference.com/videos/100-encrypted-web-new-challenges-for-tls</a>
The presentation was well attended, and appeared to be well
received.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">We had not planned to bring this up in
the Forum (and there is no need to discuss further on this
list), but if anyone is interested in promoting website
identity, please let me and the CASC members know.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">As to the main suggestion in Peter’s
email – we support this. If there are pre-BR certs still out
there that are not in compliance with the BRs (after five
years), let’s get them revoked. It will be easy to do, and
good for user security.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">-----Original Message-----<br>
From: Public [<a class="moz-txt-link-freetext" href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>] On Behalf Of
Peter Bowen via Public<br>
Sent: Friday, February 24, 2017 8:40 PM<br>
To: CA/Browser Forum Public Discussion List
<a class="moz-txt-link-rfc2396E" href="mailto:public@cabforum.org"><public@cabforum.org></a><br>
Cc: Peter Bowen <a class="moz-txt-link-rfc2396E" href="mailto:pzb@amzn.com"><pzb@amzn.com></a><br>
Subject: [cabfpub] Assuring trust in website identities</p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The BRs came into effect on July 1,
2012. This year we have the fifth anniversary of the BRs, and
we have an opportunity to help provide high assurance of
website identities using certificates. Given the new Website
Identity initiative (<a moz-do-not-send="true"
href="https://casecurity.org/identity/"><span
style="color:windowtext;text-decoration:none">https://casecurity.org/identity/</span></a>)
announced at RSAC last week (<a moz-do-not-send="true"
href="https://www.rsaconference.com/videos/100-encrypted-web-new-challenges-for-tls"><span
style="color:windowtext;text-decoration:none">https://www.rsaconference.com/videos/100-encrypted-web-new-challenges-for-tls</span></a>),
it is clear others are thinking similarily.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">In a discussion with Kirk today, I
mentioned that one of the challenges with recognition of OV
certificates is the existence of certificates with OV/IV info
which are not covered by the BRs, either due to issuance date
or missing data in the certificate. It is very hard for
browsers to detect whether a certificate is a legitimate OV/IV
certificate or not given the existence of these certificates.
In order to help assure trust in website identity, Kirk
suggested that we set a sunset date for certificates with
identity that are not clearly covered in the BRs.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I think the sunset date should be July
1, 2017, which is five years from the BR effective date. On
this date, all CAs much revoke unexpired certificates that
meet the following criteria:<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">- Contain at least one attribute of type
organizationName {2 5 4 10}, givenName {2 5 4 42}, or surName
{2 5 4 4} in the Subject Name, and<o:p></o:p></p>
<p class="MsoPlainText">- Is not self-signed certificate, as
defined in X.509, and does not have cA set to true in the
basic constraints extension (this avoids revoking CA
certificates), and<o:p></o:p></p>
<p class="MsoPlainText">- Any of the following are true:<o:p></o:p></p>
<p class="MsoPlainText"> - Is not a valid Certificate as
defined by X.509<o:p></o:p></p>
<p class="MsoPlainText"> - Was issued before
2012-07-01T00:00:00Z and includes an extended key usage
extension that contains the id-kp-serverAuth {1 3 6 1 5 5 7 3
1} or anyExtendedKeyUsage {2 5 29 37 0} key purpose
<o:p></o:p></p>
<p class="MsoPlainText"> - Does not include an extended key
usage extension but does include a key usage extension with
digitalSignature<o:p></o:p></p>
<p class="MsoPlainText"> - Does not include an extended key
usage extension but does include a key usage extension with
keyEncipherment and has a RSA subject public key<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">By revoking these certificates, we can
assure that all un-revoked certificates used for website
identity authentication that have identity information were
vetted according to the BRs.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">I want to thank Kirk for suggesting
revocation of these as the solution to help assure relying
parties of website identities.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Do others agree that this path makes
sense in order to provide high assurance of website identity?<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">Thanks,<o:p></o:p></p>
<p class="MsoPlainText">Peter<o:p></o:p></p>
<p class="MsoPlainText">_______________________________________________<o:p></o:p></p>
<p class="MsoPlainText">Public mailing list<o:p></o:p></p>
<p class="MsoPlainText"><a moz-do-not-send="true"
href="mailto:Public@cabforum.org"><span
style="color:windowtext;text-decoration:none">Public@cabforum.org</span></a><o:p></o:p></p>
<p class="MsoPlainText"><a moz-do-not-send="true"
href="https://cabforum.org/mailman/listinfo/public"><span
style="color:windowtext;text-decoration:none">https://cabforum.org/mailman/listinfo/public</span></a><o:p></o:p></p>
</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>
<div class="moz-signature">-- <br>
<p style="font-family: Serif">
Cordiali saluti,<br>
<br>
Adriano Santoni<br>
ACTALIS S.p.A.<br>
(Aruba Group)</p>
</div>
</body>
</html>