<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 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Bradley Hand ITC \;color\:\#0f243e";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
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
{mso-style-priority:99;
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";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">Adrien, you have raised a concern that I had – the non-uniqueness of .onion names and certificates (including names that will appear meaningful, like facebookwwwcore1.onion,
which Facebook is using but which a hacker could also obtain through a brute force approach to generating key pairs).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">I asked before how Tor would resolve a user request to go to the address facebookwwwcore1.onion (or another .onion domain with a random set of characters)
if there were multiple sites/certificates with that name, but I don’t recall whether the question was ever answered.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext">Do you know the answer?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:windowtext"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Adrien Johnson [mailto:adrienj@adrienj.com]
<br>
<b>Sent:</b> Sunday, March 01, 2015 11:47 AM<br>
<b>To:</b> Ryan Sleevi; Kirk Hall (RD-US)<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] FW: [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Thank you Ryan and Kirk,<br>
<br>
I've read through the 5 most recent months of discussion on the .onion proposal and I see that the topic of weakness in the hash algorithm has been brought up already, that up to now the Tor Project has been comfortable using half a SHA-1 to uniquely identify
public keys and guard against impersonation. I also see that upgrading to full SHA-256 .onion domain names is already on the Tor Project's timeline and is expected to be completed within the next 2 years. I don't have the math background to judge how imminent
the threat of impersonation attacks is on current .onion domains using the half-SHA1 hash, so if the Tor Project is comfortable with their transition timeline, I don't see a problem.<br>
<br>
I didn't see the topic of assigning strong SSL certificates to weak .onion certificates discussed in nearly as much depth at all though, and this is the issue I am confident enough to say is an oversight in the security model. You can't build a more robust,
unique identity by assigning an SSL certificate to a Tor hidden service than already exists in the hidden service certificate. Not without serious compromises, such as building a central repository of who 'really' owns which .onion domain after all. Assigning
a strong SSL certificate to a weak .onion certificate is irresponsible at best.<br>
<br>
Imagine for example a weak keypair was used to set up a Tor hidden service at example634563456.onion. A very short key length, or a Debian weak key. Any attacker who wanted to could determine the private key for this onion domain, and thus would have equal
'control' over the domain example634563456.onion as anyone else who had the private key. Every single one of these people is equally entitled to an SSL certificate for that domain. If the SSL certificate uses stronger crypto than is actually provided in the
.onion key, it would mislead anyone who visits a site using that SSL certificate into thinking they are visiting a
<i>unique </i>example634563456.onion. If the SSL certificate uses 4096 bit RSA they might be especially reassured that they are securely communicating with the real example634563456.onion and that their traffic is not being eavesdropped, completely unaware
that multiple CAs may have have issued multiple strong SSL certificates to multiple attackers all for that same domain name.<br>
<br>
You might use certificate transparency to prevent a second organization from obtaining an SSL certificate for the same .onion domain, but there's no way to know whether the first organization to apply for the example634563456.onion is the "real" one, and you
would be effectively creating a repository of 'legitimate' owners of certain .onion domains, which defeats the purpose of the independantly-provable-ownership .onion domain name system.<br>
<br>
Right now a Tor hidden service using a 2048 bit RSA key is secure enough, but the same problem comes up if that 2048 bit .onion site requests a 4096 bit RSA SSL certificate. They wouldn't actually be getting 4096 bits of security, all an attacker would have
to do is compromise the 2048 bit .onion key. The weak point for impersonation attacks is always the .onion key, not the SSL key, even if the SSL key is much shorter, since the SSL certificate can only be used over the .onion tunnel which is guaranteed to securely
connect a visitor to someone who holds the .onion domain's private key. (Assuming the SSL certificate is valid for only .onion domains)<br>
<br>
This is a unique situation. I don't think there has ever been a case where CAs have a definite responsibility to limit the strength of the certificates it issues to applicants. Where an applicant's ownership of their domain name, their verification of identity,
is measured not in research hours and photos of identity documents, but directly in RSA key length. That is the case here though.<br>
<br>
I almost wonder whether it's possible for CA's to sign the .onion certificates directly and have the Tor client pass those on to the browser, instead of issuing parallel SSL certificates that do almost the same thing, but cannot provide any more security than
the .onion certificates. Reduce a certificate to a signature. That's what the SSL certificates would be doing for a .onion anyway, not actually used for additional security (since if the .onion key is compromised duplicate SSL certs can be obtained,) just
there to name the organization that controls the .onion private key. That is the crux of it. The certificate isn't being used as a certificate in this case, it's being used as a signature.<br>
<br>
<br>
However if issuing separate certificates is the path that is taken, the cryptographic strength of the issued SSL certificates should be no greater than the strength of the .onion certificate it is issued to. Anything higher gives a false sense of security.
Kirk, I don't think a blanket "if your .onion certificate is 2048 bits or greater, you may have an SSL certificate of any length" is ideal. If the SSL certificate has higher strength than the 2048 bit .onion certificate, it's still only a false sense of increased
security. But if requiring CAs to limit the strength of the CSRs they sign is too burdensome, it wouldn't be an immediate security concern to allow.<br>
<br>
Ryan, I apologize for barging in with a long wall of text at the end of this months-long discussion and if I've completely overlooked how the system already accounts for this, I will apologize profusely! But I felt I had to speak up.<br>
<br>
Thanks for the chance to participate,<br>
Adrien Johnson<br>
<br>
On 2015-03-01 1:59 PM, Ryan Sleevi wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p>Fair enough.<o:p></o:p></p>
<p>I do, however, hope you take the time to review the past discussion, as it explains why Adrien's analysis and conclusions are not quite correct, and why the distinction of 1024-bit vs 2048-bit or, for that matter, of SHA-1 vs SHA-2, are nowhere near the
critical hole they were presented as. I should also hope that the fact that it is I who am saying that - one of the most ardent opponents of weak crypto - should hopefully assuage some of those concerns.<o:p></o:p></p>
<p>Best<o:p></o:p></p>
<div>
<p class="MsoNormal">On Mar 1, 2015 9:33 AM, "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>> wrote:<o:p></o:p></p>
<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";color:#1F497D">I’m still interested in Adrien’s answer.</span><o:p></o:p></p>
<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";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>]
<br>
<b>Sent:</b> Sunday, March 01, 2015 9:30 AM<br>
<b>To:</b> Kirk Hall (RD-US)<br>
<b>Cc:</b> CABFPub<br>
<b>Subject:</b> Re: [cabfpub] FW: [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names</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>
<p>Kirk, Adrian,<o:p></o:p></p>
<p>I encourage you to read the discussion of and leading to the ballot, which is available on the public list archives. The discussion somewhat quite exhaustively covered these issues, and more importantly, provide a rather detailed explanation why they are
not as critical as Adrian suggests.<o:p></o:p></p>
<p>All the best,<br>
Ryan<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Mar 1, 2015 7:57 AM, "<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>>
wrote:<o:p></o:p></p>
<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"">Very good analysis, Adrien – thanks.</span><o:p></o:p></p>
<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""> </span><o:p></o:p></p>
<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"">Would you otherwise be satisfied with the recent Tor ballot if it required 2048 bit keypair/SHA-256 or higher?
Apparently Tor can only do 1024 bit/SHA-1 right now, but perhaps they can upgrade their security. Do you have any other changes to suggest?</span><o:p></o:p></p>
<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";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><i><span style="font-size:14.0pt;font-family:"Bradley Hand ITC ;color:#0f243e","serif"">Kirk R. Hall</span></i></b><o:p></o:p></p>
<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"">Operations Director, Trust Services</span><o:p></o:p></p>
<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"">Trend Micro</span><o:p></o:p></p>
<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""><a href="tel:%2B1.503.753.3088" target="_blank">+1.503.753.3088</a></span><o:p></o:p></p>
<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";color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:questions-bounces@cabforum.org" target="_blank">questions-bounces@cabforum.org</a> [mailto:<a href="mailto:questions-bounces@cabforum.org" target="_blank">questions-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Adrien Johnson<br>
<b>Sent:</b> Sunday, March 01, 2015 4:11 AM<br>
<b>To:</b> <a href="mailto:questions@cabforum.org" target="_blank">questions@cabforum.org</a><br>
<b>Subject:</b> [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names</span><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>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hello,<br>
I'm writing with serious concerns about the validation rules for .onion domains, which were voted on in
<a href="https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/" target="_blank">
Ballot 144</a> on February 18th 2015. The vote tally was 6 in favor, 2 against, and 13 abstaining, and the motion passed.<br>
<br>
There are some major security concerns which have been overlooked in this document which pose a risk to anyone relying on certificates issued along its procedures.<br>
<br>
These oversights are as follows:<br>
1) The definition of "owning" or "controlling" a .onion domain has not been sufficiently addressed<br>
2) There are no procedures for ensuring that the security of the SSL certificates issued by CAs for .onion domains is not undermined by weaker security in the underlying Tor system<br>
<br>
A .onion domain is unlike a normal global DNS name because it does not have a definite "owner". With normal global DNS names, the owner is clearly defined as the person or organization who holds the registration of the domain at an accredited domain registrar.
CAs can determine in a number of ways of varying rigour that the person/organization they give a certificate to is the legitimate owner of the domain, or their agent. The fundamental contract of the CA is to deliver a certificate to their client which provides
no greater assurance of the client's identity than the CA was able to verify. Verified domain control earns a domain validated certificate, business records earn an EV cert, etc. The idea of ownership is different for .onion domain names. By design there is
no central repository of .onion domain names, they are meant to be independently verifiable. In fact, a .onion domain name is simply an encoded hash of the public key of a Tor hidden service (a Tor service reachable by a .onion domain name.) When a browser
connects to a .onion domain, all it says to the Tor service is "connect me to the server presenting a certificate whose public key has this .onion domain as a hash." Anyone who has a keypair that hashes to a .onion domain can be called the "owner" of that
domain, and if more than one person has such a keypair, there is more than one "owner" and there is nothing to distinguish them.<br>
<br>
By itself this idea of self-evident, cryptographically-provable domain ownership is not a problem, in fact it is more robust than a centrally controlled, centrally corruptible global registry, but it means the highest assurance SSL certificate a CA can responsibly
issue has a fixed upper limit. The contract of the CA is to only certify a site owner's identity or a site visitor's security if the CA has independently verified that information. As I will show though, the maximum verification of identity and security that
can be made of a Tor hidden service is currently alarmingly low, significantly lower than the CA/B Forum's guidelines for certificate issuance.<br>
<br>
What is a .onion domain name? <a href="https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames" target="_blank">
The Tor Project documentation</a> states:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If you decide to run a hidden service Tor generates an RSA-1024 keypair. The .onion name is computed as follows: first the SHA1 hash of the DER-encoded ASN.1 public key is calculated.
Afterwards the first half of the hash is encoded to Base32 and the suffix ".onion" is added. Therefore .onion names can only contain the digits 2-7 and the letters a-z and are exactly 16 characters long.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">This means two things: the .onion domain name is derived from the hidden service's keypair using an already deprecated hash function on public key, and then
<i>half the bits of the hash are discarded</i>. SHA-1 was deprecated by CAs in fear a SHA-1 collision could be used to create a rogue intermediate CA certificate, as was done in 2008 using an MD5 collision. It would be somewhat harder to attack SHA-1 here to
impersonate an already existing .onion domain because it would require a preimage attack instead of an arbitrary collision, as in the rogue CA scenario. Needless to say though, discarding half the bits of the SHA1 hash makes an attack significantly easier.<br>
<br>
The second thing it means is hidden services all use 1024-bit RSA keys for communication and identity. Even if we ignore the weaknesses in the generation of .onion domain names and assume that a colliding keypair cannot be found, it's still only a 1024-bit
RSA keypair, which is also deprecated. Given a 1024-bit public key, calculating the corresponding private key is currently within the reach of government and large corporate attackers, which is why the CA/B Forum has disallowed their issuance. 1024-bit RSA
keys do not provide enough assurance that the holder of the private key is the same person or organization that was issued the legitimate certificate. If the 1024-bit RSA key of the hidden service is cracked or stolen, it cannot be revoked and reissued as
an SSL certificate can. It must be abandoned and the service must move to a new .onion domain/keypair because controlling the 1024-bit RSA key itself is what defines "ownership" of the .onion domain.<br>
<br>
No certificate issued to a .onion domain can currently have greater than 1024-bit RSA security. Even if a 2048-bit or greater key is issued to a .onion domain, the 1024-bit key conferring ownership of the .onion domain is still the weak link. When the 1024-bit
key is defeated, the attacker has just as much ownership of the .onion domain as the first user, and would be able to obtain an SSL certificate for it from any CA issuing .onion SSL certificates, and may even be able to request revocation of the first SSL
certificate.<br>
<br>
Because the Tor system currently limits the certificate hash function used to generate .onion domains to the very weak half-SHA1, and because the maximum identity and security verification a CA can responsibly certify for a .onion domain is limited to 1024-bit
RSA, less than the current CA/B guidelines for certificate issuance, no CA can responsibly issue SSL certificates for .onion domains at this time.<br>
<br>
In order for SSL certificates to be responsibly issued for .onion domains, several changes would need to be made. The hash function used to derive .onion domains from the hidden service's public key should be strengthened to a modern alternative such as SHA-256,
and all the bits of the hash should be encoded in the .onion domain. Tor hidden services should transition to keypairs stronger than the current CA/B Forum guidelines for certificate issuance, and in the SSL certificate issuance process the CA should ensure
that it does not provide a certificate with greater cryptographic strength than the underlying Tor hidden service certificate. This is because the upper limit of identity and security a CA can actually verify for a hidden service is limited by the strength
of the underlying hidden service keys. Any greater strength in the SSL certificate than the hidden service certificate represents a stronger promise of the hidden service's identity and security than is actually possible, and so would violate the CA's contract
to only certify true information.<br>
<br>
I deeply hope that the Tor service moves to stronger cryptography that meets the minimum requirements of the CA/B forum, and I hope modified procedures allowing SSL certificates to be issued to .onion sites are soon adopted, but unfortunately more work needs
to be done before that can happen.<br>
<br>
Regards,<br>
Adrien Johnson<br>
<br>
<o:p></o:p></p>
</div>
</div>
<table class="MsoNormalTable" border="0" cellpadding="0">
<tbody>
<tr>
<td style="background:white;padding:.75pt .75pt .75pt .75pt">
<table class="MsoNormalTable" border="0" cellpadding="0">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt">
<pre> <o:p></o:p></pre>
<pre>TREND MICRO EMAIL NOTICE<o:p></o:p></pre>
<pre>The information contained in this email and any attachments is confidential <o:p></o:p></pre>
<pre>and may be subject to copyright or other intellectual property protection. <o:p></o:p></pre>
<pre>If you are not the intended recipient, you are not authorized to use or <o:p></o:p></pre>
<pre>disclose this information, and we request that you notify us by reply mail or<o:p></o:p></pre>
<pre>telephone and delete the original message from your mail system.<o:p></o:p></pre>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">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>
</div>
</div>
</div>
<table class="MsoNormalTable" border="0" cellpadding="0">
<tbody>
<tr>
<td style="background:white;padding:.75pt .75pt .75pt .75pt">
<table class="MsoNormalTable" border="0" cellpadding="0">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt">
<pre>TREND MICRO EMAIL NOTICE<o:p></o:p></pre>
<pre>The information contained in this email and any attachments is confidential <o:p></o:p></pre>
<pre>and may be subject to copyright or other intellectual property protection. <o:p></o:p></pre>
<pre>If you are not the intended recipient, you are not authorized to use or <o:p></o:p></pre>
<pre>disclose this information, and we request that you notify us by reply mail or<o:p></o:p></pre>
<pre>telephone and delete the original message from your mail system.<o:p></o:p></pre>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>
<table><tr><td bgcolor=#ffffff><font color=#000000><pre><table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table></pre></font></td></tr></table>