<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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
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-6470265441106247378m741881086273449798m-3178879151159413396m-3045134859279020391msolistparagraph, li.m-6470265441106247378m741881086273449798m-3178879151159413396m-3045134859279020391msolistparagraph, div.m-6470265441106247378m741881086273449798m-3178879151159413396m-3045134859279020391msolistparagraph
{mso-style-name:m_-6470265441106247378m741881086273449798m-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;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:302279129;
mso-list-type:hybrid;
mso-list-template-ids:-412161480 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;}
@list l1
{mso-list-id:989747751;
mso-list-type:hybrid;
mso-list-template-ids:-1925307094 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1: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><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>If I understand you correctly, then the argument against boils down to a few main points:<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The WFA defined their own PKI Framework, which originally didn’t require public trust so adding public trust now isn’t appropriate. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The number of OSU root operators is currently limited. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The benefit to Google is limited. Although you mentioned browsers, Microsoft has interest in a publicly trusted OSU cert as they added one of the Hotspot roots to their root store.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>4)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>WFA members might want to participate in the discussion but shouldn’t until the governance reform is completed.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>5)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Cross-trusting systems makes it more difficult to migrate to better security practices.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Is that a fair summary? If so, then <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>There are lots of PKI frameworks operated by various entities, and these frameworks are often updated. Usually (like the TAGPMA), the policy aligns sufficiently with the CAB Forum that issuance of a certificate isn’t going to violate either requirement. The OSU framework was partially based on public cert requirements with the addition of the otherName type. This is one reason the validation and profiles look nearly identical to OV certs. The non-critical technical constraint decision was partially based on the lack of support in Apple products, the WFA arriving at nearly the same conclusion as the CAB Forum. Some of the WFA members, but not all, see a need for public trust in the certs. Although they have a separate PKI framework, it is one that is closely aligned with the goals and requirements we’ve created in the CAB Forum.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Although DigiCert is the sole public CA involved at this time, the WFA has twice made an open invitation for CAs to participate. I can’t speak for other CAs about why they chose not to participate in the project. Although there are only a handful of anchors, I’m not sure why this is a “no” for Google. There’s nothing that forces browsers to support OSU or requires CAs to follow the OSU Hotspot profile when issuing non-WFA certs. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I have no knowledge of what Google is doing with the OSU program. Perhaps there isn’t a value to Google, but there’s a value in public trust for the WFA community.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>4)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I’m already participating in both groups. No other WFA members have indicated an interest in participating with the CAB Forum. No need to delay on that account.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><span style='mso-list:Ignore'>5)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I don’t understand this reason. If they removed the friendly name and used publicly trusted certificates, then we’d have the same problem with migration as with friendly names included. This is a problem no matter what because people use publicly trusted certificate roots for a variety of purposes. Limiting the profile doesn’t actually change this concern.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Jeremy<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></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> Thursday, January 5, 2017 1:41 PM<br><b>To:</b> Jeremy Rowley <jeremy.rowley@digicert.com><br><b>Cc:</b> CA/Browser Forum Public Discussion List <public@cabforum.org><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><div><p class=MsoNormal>Hi Jeremy,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It sounds like you're either confused about HotSpot 2.0, making very contradictory arguments, or I'm simply not having any ability to follow your logic.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>HotSpot 2.0 (aka Passpoint) defines its own PKI program ( <a href="https://www.wi-fi.org/download.php?file=/sites/default/files/private/Passpoint_R2_Deployment_Guidelines-v1.1.pdf">https://www.wi-fi.org/download.php?file=/sites/default/files/private/Passpoint_R2_Deployment_Guidelines-v1.1.pdf</a> direct link w/ no shrinkwrap)<o:p></o:p></p></div><div><p class=MsoNormal>As part of that profile, Section 4.2 details the requirements for that PKI<o:p></o:p></p></div><div><p class=MsoNormal>HotSpot 2.0 <b>requires</b> that an OSU (Online Sign Up) server use a server certificate from a HS 2.0 Trust Root CA Certificate.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>That's acceptable for the limited use case of HotSpot 2.0 being used with proprietary (vendor) apps, which is apparently what is was designed for. That is, this is situations like Time Warner Cable's "Wifi Finder" app or the Boingo app. These applications can specify the trust stores they use, as part of their applications, and just like the Point-of-Sale/Cablebox/etc problem, this is not an issue for the CA/Browser Forum to deal with.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>However, if the argument is (and, unfortunately, from the WFA it is), that common off-the-shelf browsers should also communicate with the OSU - this is the Starbucks example Jeremy gave - then it's a problem. Browsers maintain their own trust stores - and do not recognize that of the HS 2.0 CAs (which, if memory serves, also included a WFA-operated CA)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The view of this particular browser vendor is that if you want Chrome to load a page, you should use a publicly trusted CA server. The need for HS 2.0 to require and define its own PKI is inherently sketchy, but I can appreciate the arguments for the EAP-TLS / AP exchange / OOB communication. However, requiring that the OSU use it is, in my view, problematic.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Jeremy works for one of the only two CA vendors that are recognized by HS 2.0, and AFAIK, the only one which also has a publicly trusted CA.<o:p></o:p></p></div><div><p class=MsoNormal>Jeremy's proposal has the effect of allowing the publicly trusted CA to be used for the HS 2.0 OSU - allowing DigiCert certificates to be 'dual use', as it were - usable both in HS 2.0 apps (like the TWC or Boingo apps) and in browsers.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I can understand why that would be appealing to DigiCert. What I don't understand is why that would be appealing or desirable to browsers. I imagine that the argument goes is that HS 2.0 has more momentum then the web, ergo unless browsers allow this, they'll be "forced" to add the HS 2.0 Trust Root Root CA Certificates to their browser stores. I find that extremely unlikely.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>However, if we do believe it's good - that DigiCert should be able to share infrastructure with both publicly trusted PKI and with such private PKIs as HS 2.0 - then I would argue that it's something we absolutely shouldn't be taking on until we get to a point where HS 2.0 participants can participate. That is, until we've completed GovReform.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The same arguments apply to adding rfc822Name.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I understand that we benefit from economies of scale, and a rising tide lifts all boats, and any other aphorisms or metaphors we'd like to go along with that. But I think, on the back of the SHA-1 deprecation woes, we shouldn't be needlessly coupling independent systems, nor should we be trying to expand the scope unless and until we've got better vectors for participation, discussion, and feedback.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Thu, Jan 5, 2017 at 12:22 PM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@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'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Why would you consider it a bad security design? It’s just an SSL cert with an otherName included. There’s really nothing else that differentiates them. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a name="m_-6470265441106247378__MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span></a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>] <br><b>Sent:</b> Thursday, January 5, 2017 12:43 PM<br><b>To:</b> Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>><br><b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> Re: [cabfpub] Ballot 184: rfc822Names and otherNames</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><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Thu, Jan 5, 2017 at 9:51 AM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<o:p></o:p></p><div><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=m-6470265441106247378m741881086273449798m-3178879151159413396m-3045134859279020391msolistparagraph style='margin-left:.5in'><br>3)<span style='font-size:7.0pt'> </span>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></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I'm sorry, this is simply not articulated as to why browsers care.<o:p></o:p></p></div><div><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>More concretely: You've not demonstrated why there is a need for a second trust store at all. If Starbucks wants to run a captive portal, it can and should use a publicly trusted CA cert to the captive portal (e.g. <a href="https://captive.starbuckswifi.com" target="_blank">https://captive.starbuckswifi.com</a> ). It shouldn't create a 'shadow trust store' for captive portal signin pages (as the WFA has done), and there's zero incentive to browsers to support that.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=m-6470265441106247378m741881086273449798m-3178879151159413396m-3045134859279020391msolistparagraph style='margin-left:.5in'>4)<span style='font-size:7.0pt'> </span>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></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I would rather we resolve the many governance issues first, since we have repeatedly made clear that's a precondition to expanding the scope of the Forums' activities.<o:p></o:p></p></div><div><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>As it stands, I think we'd be fairly opposed to both the rfc822Name proposal and the WFA proposal. SRVNames are and remain a good idea, but rfc822Name has significant interoperability and legacy concerns, and the WFA stuff is just... bad security design.<o:p></o:p></p></div></div></div></div></div></div></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>