<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><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;}
/* 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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.m-3178879151159413396m-3045134859279020391msolistparagraph, li.m-3178879151159413396m-3045134859279020391msolistparagraph, div.m-3178879151159413396m-3045134859279020391msolistparagraph
{mso-style-name:m_-3178879151159413396m-3045134859279020391msolistparagraph;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.m-3178879151159413396default, li.m-3178879151159413396default, div.m-3178879151159413396default
{mso-style-name:m_-3178879151159413396default;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
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;}
/* List Definitions */
@list l0
{mso-list-id:2097435256;
mso-list-type:hybrid;
mso-list-template-ids:359333346 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Rfc822Names<o:p></o:p></span></b></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I’m not 100% tied to permitting rfc822Names, but customers request them occasionally and like to stick them in the cert (such as the OU or E field). I’d like to accommodate them by including email in the proper place if there is a way to do so without affecting browser security. The “reasonable measures” language came from the Mozilla root policy, which is the only policy that contains a specific requirement to validate email addresses. If we’d like something more stringent, I originally planned to propose:<o:p></o:p></span></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph><span style='color:black'>“The subjectAltName MAY include one or more rfc822Name entries provided each entry is an email address compliant with RFC5280. Prior to including an email address, the CA MUST verify the Applicant’s control over the email address by either verifying the domain portion of the mail under Section 3.2.2.4 or c</span>onfirming the Applicant's control over the email by sending a Random Value to the email address and then receiving a confirming response utilizing the Random Value. If a Random Value is used, the Random Value SHALL be unique in each email. The CA or Delegated Third Party MAY resend the email in its entirety, including re<span style='font-family:"Cambria Math",serif'>‐</span> use of the Random Value, provided that the communication's entire contents and recipient(s) remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation.”<o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph>This is a lot more stringent than current browser requirements for email validation, but I see nothing wrong with that as these are server certs.<o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph><b>WFA otherName<o:p></o:p></b></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph>The HotSpot 2.0 program was designed to secure wireless sign-up access points. The goal was two-fold: 1) The WFA wanted to secure the connection between the hostpot authentication server and the connecting device and 2) help users identify the entity operating a hotspot location and understand which hotspot location represented the correct connection. For example, when I’m at the airport, I see a couple dozen hotspots, all of which are named “Starbucks”. I don’t know which hotspot Starbucks intends as its customer portal. Use of the friendly name helps Starbucks funnel customers to their actual sign-up and distinguish their hotspot from potential phishers.<o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph>The value propositions for permitting public trust with HotSpot are:<o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Most of the hardware manufactures have completed or are nearing completion of WFA certification of their devices. However, one a barriers to roll-out has been the interstitial displayed during the connection process. Although, certain platforms can now display and use Friendly Names, the customer experience is interrupted during the sign up as these are self-signed certificates. Adding the possibility of public trust enhances the goal of the WFA by providing a seamless sign-on experience for users connecting with hand-held devices. <o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Use of public trust increases the security of the WFA community. With this change publicly-trusted WFA certs will be compliant with the baseline requirements, and the certs will inherit this group’s wisdom in planning and enforcing security upgrades. For example, a WFA cert containing a server name will benefit from the work we just completed on improving validation methods, leading to a better security ecosystem overall. Although increasing the number of entities relying on public trust has the potential to make improvements more difficult to implement, the positive is more people benefit from increased security and more consumers are protected from attacks.<o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>The browsers are part of the HotSpot program. The WFA membership includes Apple, Microsoft, and Google. As Ryan points out, the representatives are not necessarily the same, but, nevertheless, browsers are interested in the project. This group should provide browsers with the option of reusing their trust store as part of the program (Erwann pointed out that Microsoft has already done this). Forcing browsers to have two separate trust stores on the same platform doesn’t make much sense where the two programs are essentially compatible minus a few points.<o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>4)<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]>Allowing WFA otherNames invites interoperability from other groups. I think showing the public that this group is willing to interoperate with the WFA invites other groups to bring their use cases forward and see whether we can accommodate them. I’d rather know the various ways people would like to use public trust than have everyone assume the public trust industry is impossible to work with. <o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph>I’m sure there are others, but those are my reasons for wanting to see the CAB Forum permit interoperability. <o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph>Jeremy<o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></a></p><span style='mso-bookmark:_MailEndCompose'></span><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'> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Wednesday, January 4, 2017 6:20 PM<br><b>To:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><br><b>Cc:</b> Jeremy Rowley <jeremy.rowley@digicert.com><br><b>Subject:</b> Re: [cabfpub] Ballot 184: rfc822Names and otherNames<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>How tied are you to allowing rfc822Name? "Reasonable measures" feels very much like the "any equivalent method", and it also feels very much like it will open up the gates of S/MIME, for which the GovReform is still working through.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>For example, can you incorporate language such as 3.2.2.4.2 / 3.2.2.4.4 to specify more explicitly what 'reasonable' means? Can you remove it entirely?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm still very uncertain about the value proposition of 7.1.4.2.1.3 / 7.1.4.2.1.5 and why it's desirable, at all, to use BR-compliant CAs for that. I'm hoping you can make a compelling case here.<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Wed, Jan 4, 2017 at 5:03 PM, Jeremy Rowley via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:black'>Thank you everyone for the feedback so far. Attached is an updated draft based on the comments provided. Apologies for the lack of redlining, but I reformatted the entire section into various permitted entries (thanks Gerv) which made the entire thing more readable. Let me know what you think.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:black'>Jeremy</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='color:black'>7.1.4.2.1. Subject Alternative Name Extension </span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:black'>Certificate Field: extensions:subjectAltName </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:black'>Required/Optional: Required </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:black'>Contents: This extension MUST contain at least one entry where each included entry is one of the following:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='color:black'>7.1.4.2.1.1. dNSName </span></b><o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph><span style='color:black'>The subjectAltName extension MAY include one or more dNSName entries provided each entry is either a Fully</span><span style='font-family:"Cambria Math",serif;color:black'>‐</span><span style='color:black'>Qualified Domain Name or a Wildcard Domain Name. The CA MUST verify each Fully-Qualified Domain Name and Wildcard Domain Name entry in accordance with Section 3.2.2.4. </span><o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph><span style='color:black'>Except where the entry is an Internal Name using onion as the right</span><span style='font-family:"Cambria Math",serif;color:black'>‐</span><span style='color:black'>most label in an entry in the subjectAltName Extension or commonName field in accordance with Appendix F of the EV Guidelines, a dNSName entry MUST NOT contain an Internal Name.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='color:black'>7.1.4.2.1.2. iPAddress</span></b><o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph><span style='color:black'>The subjectAltName MAY include one or more iPAddress entries provided each entry is an IP address verified in accordance with Section 3.2.2.5. The entry MUST NOT contain a Reserved IP Address.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='color:black'>7.1.4.2.1.3. rfc822Name</span></b><o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph><span style='color:black'>The subjectAltName MAY include one or more rfc822Name entries provided each entry is an email address compliant with RFC5280. Prior to including an email address, the CA MUST take reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate <em><span style='font-style:normal'>or</span></em><i> </i>has been authorized by the email account holder to act on the account holder’s behalf.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='color:black'>7.1.4.2.1.4. otherName with SRVName { 1.3.6.1.5.5.7.0.18.8.7 } type-id</span></b><o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph><span style='color:black'>The subjectAltName MAY include one or more SRVNames (as defined in RFC4986) as an otherName entry with the SRVName type-id. The CA MUST verify the name portion of the entry in accordance with Section 3.2.2.4. SRVName entries MUST NOT contain Wildcard Domain Names. If a Technically Constrained Subordinate CA Certificate includes a dNSName constraint but does not have a technical constraint for SRVNames, the CA MUST NOT issue certificates containing SRVNames from the Technically Constrained Subordinate CA Certificate. A Technically Constrained Subordinate CA Certificate that includes a technical constraint for SRVNames MUST include permitted name subtrees and MAY include excluded name subtrees.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='color:black'>7.1.4.2.1.5. otherName with id-wfa-hotspot-friendlyName { 1.3.6.1.4.1.40808.1.1.1 } type-id</span></b><o:p></o:p></p><p class=m-3178879151159413396m-3045134859279020391msolistparagraph><span style='color:black'>The subjectAltName MAY include one or more entries of the id-wfa-hotspot-friendlyName type-id. The CA MAY only include id-wfa-hotpost-friendlyName entries compliant with the Hotspot OSU Certificate Policy as officially published by the Wi-Fi Alliance at </span><a href="https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoint" target="_blank"><span style='color:black'>https://www.wi-fi.org</span></a><span style='color:black'>. Prior to including a id-wfa-hotpost-friendlyName entry, the CA MUST:</span><o:p></o:p></p><p class=m-3178879151159413396default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>A)</span><span style='font-size:7.0pt;color:black'> </span><span style='color:black'>Authenticate the authority of the certificate requester in accordance with Section 3.2.5;</span><o:p></o:p></p><p class=m-3178879151159413396default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>B)</span><span style='font-size:7.0pt;color:black'> </span><span style='color:black'>Authenticate the Subject Identity information in accordance with Section 3.2.2.1; and</span><o:p></o:p></p><p class=m-3178879151159413396default style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>C)</span><span style='font-size:7.0pt;color:black'> </span><span style='color:black'>Conduct a trademark search for the entry with the U.S. Patent and Trademark Office and equivalent international trademark office such as the WIPO ROMARIN. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:11.4pt'><span style='color:black'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:black'> </span><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 href="mailto:Public@cabforum.org">Public@cabforum.org</a><br><a 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></body></html>