<div dir="ltr">I don't think it's misleading - both GlobalSign and Let's Encrypt took steps to disable issuance to avoid introducing further risk. Both GlobalSign and Let's Encrypt than proposed future steps to ensure that the risks were mitigated, to various degrees of comprehensiveness. These steps were taken within hours and days, respectively, of becoming aware of issues, and it's a credit to both GlobalSign and Let's Encrypt the degree of responsiveness that was undertaken.<div><br></div><div>I think that both CAs took proactive steps to cease issuance, and engage in the community, is reflective of both what is reasonable and what is exemplary, particularly given the challenges in disabling automated forms of issuance (compared to, say, manual forms, in which it is already routinely expected to engage with the customer-applicant)<br><div><br></div><div>Compare and contrast that with Bruce's proposal, which provides for no mitigations for the many issues already discovered in the level of assurance provided by Entrust's use of 3.2.2.4.1, which presently allows for up to 3 year certificates to be issued (to be reduced to 825-days in March), and further proposes to allow the reuse of that validation information. To really emphasize this point, as it may be missed, the maximum 'damage' an improperly validated certificate validated under 3.2.2.4.10 by Let's Encrypt can do is measured by 90 days from its issuance, or, if we were to look at today, 2018-04-29. The maximum 'damage' an improperly validated certificate validated under 3.2.2.4.1 by Entrust, as proposed by Bruce, is measured as 2021-04-29 (if DV/OV), or 2020-04-29 (if EV) - if the move was made today, or 2021-05-28 (DV/OV) and 2020-11-03 (EV) if adopted by August.</div><div><br></div><div>I don't think it's misleading to suggest that the responses to 3.2.2.4.9 and 3.2.2.4.10, by GlobalSign and Let's Encrypt, respectively, are reflective of positive committments to ensuring that users and site operators are secure and protected from improper validation - even when the risk is mitigatable - and the reactions to 3.2.2.4.5 and 3.2.2.4.1, for which both no mitigations exist, nor have the inherent security issues been acknowledged or responded to, are of a different kind and calibre.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 29, 2018 at 1:03 PM, Doug Beattie <span dir="ltr"><<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4482425526845975029WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Ryan,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I think the term “disable” is a bit strong, or perhaps misleading in this context. Yes, Let’s Encrypt did was temporarily disabled method 10 within hours, but
isn’t method 10 still being used to issue a large number of certificates, and isn’t renewal of domains that used this method still allowed? I wouldn’t call that “disabled”.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><a name="m_-4482425526845975029__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<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"> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@<wbr>cabforum.org</a>]
<b>On Behalf Of </b>Ryan Sleevi via Public<br>
<b>Sent:</b> Monday, January 29, 2018 12:42 PM<br>
<b>To:</b> Mike Reilly (WDG) <<a href="mailto:Mike.Reilly@microsoft.com" target="_blank">Mike.Reilly@microsoft.com</a>><br>
<b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span></p><div><div class="h5"><br>
<b>Subject:</b> Re: [cabfpub] Ballot 218 version 2: Remove validation methods #1 and #5<u></u><u></u></div></div><p></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">As a further point of comparison regarding impact versus risk - CAs were successfully able to disable the use of methods 3.2.2.4.9 and 3.2.2.4.10 within hours of determining they may provide less than reliable information, despite such
validation methods accounting for more than half of some CAs issuance.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We think this more than demonstrates that security-conscious CAs can take steps to mitigate risk, and to do so transparently, in a rapid timeframe, and thus are concerned about CAs that present it as overly burdensome or difficult, given
the risks.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Jan 29, 2018 at 12:29 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<u></u><u></u></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>
<p class="MsoNormal">Hi Mike,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">To be clear, we (Google) do not believe that August represents a suitable balancing of risk. As Bruce notes, we are examining moving sooner on this - the security risk posed by the arbitrariness allowed, which Entrust has specifically demonstrated
their systems are vulnerable to, presents an unacceptably large risk to our users.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">From a technical perspective, the fact that validation methods (and their use) is entirely dependent on a 'trust us' approach based by CAs, as compared to say, requirements on the use of signature algorithms, certificate profiles, or revocation
actions, further presents complications, in that it indirectly ties browser security policy to a majority of CAs agreeing. This sort of product-level decision remains best dealt with at a product level, and to the extent the Forum can provide harmonized discussion,
we do want to take advantage of it.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We believe that the information shared - by Entrust (who believes it acceptable) and by DigiCert (who understandably expressed concerns with how it's historically used) - and the past discussions of and information shared on how CAs are
using these methods, such as during our Berlin F2F last year, provide sufficient context as to the risk. With regard to CA practices, given CAs' disclosures in their CP/CPS, and the ready availability of methods .2 and .3 - which involve the same amount of
validation effort (a Reliable Method of Communication, the same as used in 3.2.5), but use reliable information rather than unreliable information, more than sufficiently mitigate the risk posed.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As a practical matter, Entrust's proposal effectively attempts to stifle action for another two months, with a further completely unacceptable proposal to continue to reuse the (insecurely validated) information. We believe that CAs can,
and must, be able to respond more effectively, and more responsibly, then making a change by then. This includes, to be clear, the August date - which attempts to seek consensus in the Forum for what is already an upper-bound on the level of security that
users expect and the level of control - and ability to mitigate misissuance - that site operators expect.<u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Jan 29, 2018 at 11:52 AM, Mike Reilly (WDG) <<a href="mailto:Mike.Reilly@microsoft.com" target="_blank">Mike.Reilly@microsoft.com</a>> wrote:<u></u><u></u></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">Hi Bruce and Ryan. Based on my review of the ballot 218 discussion, I believe it would be beneficial to discuss this ballot at our next f2f meeting which is just about a month
away. This is an important topic for all members of the ecosystem (customers, CAs, and Browsers) and the outcome will impact some CAs more that others.
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I’d prefer to see more deliberate planning toward mitigating this security risk, which the August date seams to support. From my understanding this discussion started with Jeremy’s
proposal on 19 December, which was right before the time most were away on holiday break. So, it has been in discussion for just over a month now, but via email and part of one CABF call.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I’m still a relatively new member of the CABF and see the f2f meetings as a great setting to discuss these larger issues. If there are elements of the discussion which are missing
perhaps the best use of the mail list would be to centrally collect the concerns (ideally with some data from key stakeholders) in order to facilitate a productive f2f meeting in early March. I’ve not seen good data on actual security incidents related to
this method nor have I seen data on how much members of our CA ecosystem rely on this method.
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I definitely believe 3.2.2.4.1 needs improvement or elimination for the security of customers. However, I would also like to see the risk mitigated in a deliberate vs. crisis
mode fashion to minimize disruption to the ecosystem. Seems we could agree on landing a vote immediately after f2f #43. Thanks, Mike<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><b>From:</b> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@<wbr>cabforum.org</a>]
<b>On Behalf Of </b>Ryan Sleevi via Public<br>
<b>Sent:</b> Monday, January 29, 2018 7:21 AM<br>
<b>To:</b> Bruce Morton <<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.<wbr>com</a>>; 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 218 version 2: Remove validation methods #1 and #5<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Bruce,<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">To date, Entrust has not provided any of the requested details about its use of 3.2.2.4.1, the prevalence, and the potential impact. Given the lack of responsiveness to the issues,
which were raised over a month ago, and have made no substantial progress to addressing or understanding the security considerations, it does not seem like another two months of discussion will be productive, particularly given the user-security risk.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Given the lack of information and responsiveness to the issues, it is difficult to believe this is a good faith request, and not simply yet another attempt to stall conversation
in the Forum. We are certainly sensitive to the potential impact, based on available data - but CAs, such as Entrust's, unwillingness to contribute effectively to that conversation, or ability to demonstrate an awareness of and sensitivity to the security
risks presented to the ecosystem by the current practices, leads to the unavoidable conclusion that there is not much productive progress.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">We value the Forum for its excellent opportunities to discuss proposals, share information, and assess the impact to the security of users about various proposals - including the
potential challenges faced by site operators. Yet that does not preclude taking necessary steps to protect the safety and security of users, to accurately report to users the level of assurance provided by a given certificate, and to take steps to reduce the
risk from CAs whose validation practices are insufficient for the needs of the Web PKI.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Thus, we do not believe further delays, given the direct lack of responsiveness to the matters, is either warranted or wise.<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">On Mon, Jan 29, 2018 at 10:01 AM, Bruce Morton via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<u></u><u></u></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"><span style="color:#1f497d">On the CA/Browser Teleconference last Thursday, the members discussed pending Ballot 218, which would eliminate domain validation method 1 (WhoIs lookup,
BR 3.2.2.4.1) as of August, 2018. Google indicated it was not satisfied with an August 2018 implementation date, and might impose a March 2018 date on its own (through the Google root program) ending the ability to use Method 1 for domain validation as of
that date.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">We would like to ask Forum members, including Google, for a little more time to discuss this issue, including possible amendments to Ballot 218 that
might satisfy everyone’s concerns. Some possible ideas for amending Method 1 (which we can develop further in our next meeting) could include the following:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<ul type="disc">
<li class="MsoNormal" style="color:#1f497d">
Strengthen Method 1 by adding more details match the Applicant and the domain Registrant using name and a unique identifier.<u></u><u></u></li><li class="MsoNormal" style="color:#1f497d">
Require the CA also to send a notice of domain validation to the Registrant, allowing the Registrant to have the certificate revoked if the validation is not authorized.<u></u><u></u></li><li class="MsoNormal" style="color:#1f497d">
Eliminating Method 1 for DV and OV domain validation, but allowing Method 1 to be used for EV validation. The EV validation process already includes two steps to confirm the authority of the Applicant Representative to order the certificate – including a call
to a second person at the organization to confirm that the Applicant Representative has authority to request the certificate. (EVGL 11.8)<u></u><u></u></li><li class="MsoNormal" style="color:#1f497d">
Ballot 218 will require revalidation of 100% of domains previously validated using Method 1 for issuance starting 1 August 2018 (if Google acts unilaterally to prohibit use of Method 1 by March, this revalidation deadline could be March 2018). We suggest Ballot
218 should allow reuse of domain validation data for the normal period allowed by BR 4.2.1, as is the Forum’s standard practice. This will allow CAs to change processes, implement/extend automation and train customers on alternative validation methods.<u></u><u></u></li><li class="MsoNormal" style="color:#1f497d">
Finally, the elimination of Method 1 will have a significant impact not only on CAs (some of whom are Forum members, but many of whom are not and are unaware of this discussion), but more importantly on major certificate users including enterprises and governments
who often prefer Method 1 for validation of their domains. Therefore, we ask for more time for both discussion and implementation so both CAs and website owners can have a more graceful transition to whatever new rules we ultimately adopt.<u></u><u></u></li></ul>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">The Forum will be meeting in approximately 5 weeks at our Face to Face meeting in Herndon – this is a complex topic which would benefit from a thorough
discussion at that meeting to try to reach a sensible solution. We should continue discussion on this list, but let’s wait until the F2F meeting occurs to reach a final conclusion that can be implemented without unnecessary disruption to the security ecosystem.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">Thanks,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d">Bruce.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:#1f497d"> </span><u></u><u></u></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@<wbr>cabforum.org</a>]
<b>On Behalf Of </b>Tim Hollebeek via Public<br>
<b>Sent:</b> January 22, 2018 4:31 PM<br>
<b>To:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br>
<b>Subject:</b> [EXTERNAL][cabfpub] Ballot 218 version 2: Remove validation methods #1 and #5<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Ballot 218 version 2: Remove validation methods #1 and #5<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Purpose of Ballot: Section 3.2.2.4 says that it “defines the permitted processes and procedures for validating the Applicant’s ownership or control of the domain.” Most of the
validation methods actually do validate ownership and control, but two do not, and can be completed solely based on an applicant’s own assertions.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Since these two validation methods do not meet the objectives of section 3.2.2.4, and are actively being used to avoid validating domain control or ownership, they should be removed,
and the other methods that do validate domain control or ownership should be used.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The following motion has been proposed by Tim Hollebeek of DigiCert and endorsed by Ryan Sleevi of Google and Rich Smith of Comodo.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">-- MOTION BEGINS –<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based upon Version 1.5.4:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">In Section 1.6.1, in the definition of “Domain Contact”, after “in a DNS SOA record”, add “, or as obtained through direct contact with the Domain Name Registrar”<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">In Section 3.2.2.4.1, add text at the end: “For certificates issued on or after August 1, 2018, this method SHALL NOT be used for validation, and completed validations using this
method SHALL NOT be used for the issuance of certificates.”<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">In Section 3.2.2.4.5, add text at the end: “For certificates issued on or after August 1, 2018, this method SHALL NOT be used for validation, and completed validations using this
method SHALL NOT be used for the issuance of certificates.”<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">After Section 3.2.2.4.10, add following two new subsections:<u></u><u></u></p>
<p class="MsoNormal">“3.2.2.4.11 Any Other Method<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">This method has been retired and MUST NOT be used.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">3.2.2.4.12 Validating Applicant as a Domain Contact<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact. This method may only be used if the CA is also the Domain Name Registrar, or
an Affiliate of the Registrar, of the Base Domain Name.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable
for validating Wildcard Domain Names.“<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal" style="text-autospace:none">
In Section 4.2.1, after the paragraph that begins “After the change to any validation method”, add the following paragraph: “Validations completed using methods specified in Section 3.2.2.4.1 or Section 3.2.2.4.5 SHALL NOT be re-used on or after August 1, 2018.”<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">-- MOTION ENDS –<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">For the purposes of section 4.2.1, the new text added to 4.2.1 from this ballot is “specifically provided in a [this] ballot.”<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">The procedure for approval of this ballot is as follows:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Discussion (7+ days)
<u></u><u></u></p>
<p class="MsoNormal"> Start Time: 2017-01-22 21:30:00 UTC
<u></u><u></u></p>
<p class="MsoNormal"> End Time: Not Before 2017-01-29 21:30:00 UTC<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Vote for approval (7 days)
<u></u><u></u></p>
<p class="MsoNormal"> Start Time: TBD
<u></u><u></u></p>
<p class="MsoNormal"> End Time: TBD<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic&data=02%7C01%7CMike.Reilly%40microsoft.com%7C068849bea0824585f06008d5672c0305%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636528361105059910&sdata=6Mp6NGQn7Bs9wbOt2u7B2x6lVPPLH%2BfZyhOzwD22ELo%3D&reserved=0" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</div>
</blockquote></div><br></div></div></div></div>