<div dir="ltr"><span id="gmail-docs-internal-guid-2f7c5511-7fff-86c7-338b-d2d38eb7b589"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Hi Roman,</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">This proposal aims to strengthen the security of applicable domain validation practices by making them more resistant to equally-specific prefix attacks. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">While these are network attacks, they represent opportunities for attackers to exploit weaknesses in BR-approved domain validation methods that can result in certificate mis-issuance. At Face-to-Face 58, we heard from a Salesforce representative who observed real-world exploits that covered 21 hijacks over the last 16 months, with over 6 million USD in losses. 11 fraudulent certificates were used in the attacks, issued from 3 different CA owners. </span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"> </span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">While I’m not familiar with the notary server example you shared, it is my opinion that the </span><a href="https://drive.google.com/file/d/15e4Z9InYbThwJsDuH0oS7vfXKvdSBzi9/view" style="text-decoration-line:none"><span style="font-family:Arial;color:rgb(74,110,224);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">presentation</span></a><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"> (</span><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-style:italic;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">note: this is not the recording from the F2F, but offers a similar overview of the problem space</span><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">) and corresponding research from the Princeton Team [</span><a href="https://arxiv.org/abs/2302.08000" style="text-decoration-line:none"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">1</span></a><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"> and </span><a href="https://www.usenix.org/system/files/sec21-birge-lee.pdf" style="text-decoration-line:none"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">2</span></a><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">] and others [</span><a href="https://dl.acm.org/doi/10.1145/3460120.3484815" style="text-decoration-line:none"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">3</span></a><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"> and </span><a href="https://dl.acm.org/doi/10.1145/3243734.3243790" style="text-decoration-line:none"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">4</span></a><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">] identifies an opportunity for the Forum to help better protect site owners - and that this opportunity is worth exploring. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Regarding your comments on S/MIME, for now, this proposal is specific to the TLS BRs - though other Working Groups may choose to consider a similar implementation.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">I hope this helps.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">- Ryan</span></p></span><br class="gmail-Apple-interchange-newline"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 3, 2023 at 12:47 AM Roman Fischer via Validation <<a href="mailto:validation@cabforum.org">validation@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg8863619706935960104">





<div lang="DE" style="overflow-wrap: break-word;">
<div class="m_8863619706935960104WordSection1">
<p class="MsoNormal">Dear List-Members,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span lang="EN-US">I was unfortunately not able to participate in the last meeting as the Webex Link in the CA/B wiki was outdated… So please forgive if my questions have been discussed but haven’t made it to the minutes yet.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Multi-point validation: Maybe a stupid question, but aren’t we trying to solve a network-layer problem on the application layer? I remember a project some years ago that tried to run “notary services” on servers all over
 the world with a browser plugin that would use these notary servers to check if server certificates were valid… essentially doing the same as this proposal, just from the client instead of from the CA. It never gained traction… maybe because such attacks really
 don’t happen often enough to justify the effort or because it’s the wrong approach to the problem… I don’t know.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Also, to use DNS for mailbox ownership validation seems to me like an abuse of DNS (how would I get Gmail to include something in their DNS just so that I can get an S/MIME certificate on my Gmail email address?).<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">IMHO, extending CAA to cover S/MIME certificates is however a good and necessary step as the owner of a domain can then decide which CA the email-users of that domain can use.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Kind regards<br>
Roman<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Martijn Katerbarg via Validation<br>
<b>Sent:</b> Mittwoch, 21. Juni 2023 22:08<br>
<b>To:</b> Pedro FUENTES <<a href="mailto:pfuentes@WISEKEY.COM" target="_blank">pfuentes@WISEKEY.COM</a>>; CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>>; Ryan Dickson <<a href="mailto:ryandickson@google.com" target="_blank">ryandickson@google.com</a>><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL]-Re: Question about MPDV and CAA<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Pedro,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Just adding my thoughts here. In my opinion items 1, 2 and 3 all tie together.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Say that Company X wants their domains completely secured. They lock in on 1 CA, thus setting a CAA record allowing issuance only by CA A.
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">They’ve chosen CA A, because CA A has disabled DCV through email validation (or, have found a way to make this MPDV compliant) and has implemented MPDV for both CAA record checking,
 as well as their DCV options.<br>
<br>
So far so good.<br>
<br>
But now, Attacker wants to try to obtain a certificate for one of Company X their domains. Upon investigation, they notice that Company X only allows issuance by CA A, and due to MPDV, they cannot use BGP hijacking as an attack vector.<br>
<br>
So, Attacker goes instead to CA B. CA B has implemented MPDV for several options, but not for email validation. Since Attacker can perform a BGP hijack on CA B, they’re able to reroute the email to their own servers.  Now as Attacker has done BGP Hijacking,
 they’re also able to spoof the CAA DNS record, thus, showing CA B a valid CAA record, for CA B to issue the certificate.<br>
<br>
As such, while Company X has taken all precautions, a weak link in this chain, can circumvent the entry of the checks.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">(And as such, in time I expect we will see Email DCV go away, but probably not as the first step of enabling MPDV)<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US">Regards,<br>
<br>
Martijn<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Validation <<a href="mailto:validation-bounces@cabforum.org" target="_blank">validation-bounces@cabforum.org</a>>
<b>On Behalf Of </b>Pedro FUENTES via Validation<br>
<b>Sent:</b> Wednesday, 21 June 2023 19:19<br>
<b>To:</b> Ryan Dickson <<a href="mailto:ryandickson@google.com" target="_blank">ryandickson@google.com</a>><br>
<b>Cc:</b> CA/Browser Forum Validation SC List <<a href="mailto:validation@cabforum.org" target="_blank">validation@cabforum.org</a>><br>
<b>Subject:</b> Re: [cabf_validation] [EXTERNAL]-Re: Question about MPDV and CAA<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div style="border:1pt solid black;padding:2pt">
<p class="MsoNormal" style="line-height:12pt;background:rgb(250,250,3)"><span lang="EN-US" style="font-size:10pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender
 and know the content is safe.<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi Ryan, <u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">Thanks for the reply. This make things much clear to me.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">My interpretation of your risk scenarios are:<u></u><u></u></span></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal">
<span lang="EN-US">Enabling a CA that allows email validation… this implies that the attacker not only hijacks the network, but also controls the validation email. For me this risk effectively exists, but I’d assume low likelihood (else the email validations
 methods should be considered insecure and disallowed in the BR).<u></u><u></u></span></li><li class="MsoNormal">
<span lang="EN-US">Disabling CAA checks such as account binding… considering that MPDV must still be used to prove domain control, I still fail to see the risk here…For example, the attacker could skip some ACME security features… but I’d say that the issuance
 would still be prevented thanks to MPDV.<u></u><u></u></span></li><li class="MsoNormal">
<span lang="EN-US">“no-issue” CAA record… again, given than MPDV must still be used, I fail to see the risk.<u></u><u></u></span></li></ol>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Can you please elaborate your comments con scenarios #2 and #3… How the issuance could succeed given the fact that MPDV must be still used for domain control validation? <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Any security countermeasure must necessarily exist to mitigate a risk that, not only exists, but it has a level (combination of impact and likelihood) that justifies its mitigation… it’s evident that the impact is very
 high (misissuance), but I’d like to fully understand the risk level.<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Just in case… we are fine deploying distributed CAA checks if required, but I’d like to fully understand the rational here… mostly because CA systems that are more complex and with critical components distributed in the
 cloud will also increase the attack surface and risks for the CA itself.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Best,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Pedro<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span lang="EN-US"><u></u> <u></u></span></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal"><span lang="EN-US">On 21 Jun 2023, at 15:18, Ryan Dickson <</span><a href="mailto:ryandickson@google.com" target="_blank"><span lang="EN-US">ryandickson@google.com</span></a><span lang="EN-US">> wrote:<u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi Pedro,<br>
<br>
Thanks for taking the time to review the proposal - and for your question. Also, sorry for the delayed response - I’ve been out of the office for a few days. 
<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><br>
The researchers at Princeton initially advised us to evaluate both domain validation challenges and CAA records to add resilience to the issuance process. Specifically, the goal was to make it more difficult for an adversary to launch what they described as
 a “downgrade attack.”<br>
<br>
For example, let’s consider a domain owner who used CAA to restrict issuance to a set of CAs that do not support email-based domain control validation because they do not want to allow validation of their domain to occur via email. Also, suppose we aren’t checking
 CAA from multiple Network Perspectives. In this case, it’d be easier for an adversary to downgrade the issuance process because they would only need to launch one successful attack (the perspective used by the CA to establish the primary determination) to
 subvert CAA and allow a CA not included in the set of CAs permitted to issue a certificate to the domain to do so. In contrast, if CAA was checked across multiple Network Perspectives, the adversary would need to launch a global BGP attack to obtain a certificate
 for the target domain (harder to accomplish and not always viable by the adversary, for example, they might only have the means to accomplish a local or regional attack).<br>
<br>
We also see layers of security built on top of CAA, for example, Account Binding and Validation Method Binding as specified by RFC 8657. These extensions allow organizations to restrict issuance to specific 1) account IDs or 2) ACME domain validation methods.
 Not checking CAA records from multiple perspectives allows an adversary to more easily downgrade these additional security measures (based on the same approach described above) and then target the added attack surface these records were intended to eliminate.<br>
<br>
The “no-issue” CAA record (i.e., CAA 0 issue “;”) is another example where the CAA record has a significant impact on issuance behavior. If CAA is not being checked from multiple perspectives, this is another security control that can be more easily downgraded
 than if CAA is being checked from multiple perspectives. <br>
<br>
As always, other considerations and perspectives are welcome! <br>
<br>
Thanks,<br>
Ryan<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">On Fri, Jun 16, 2023 at 6:43 AM Pedro FUENTES via Validation <</span><a href="mailto:validation@cabforum.org" target="_blank"><span lang="EN-US">validation@cabforum.org</span></a><span lang="EN-US">> wrote:<u></u><u></u></span></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin:5pt 0cm 5pt 4.8pt">
<div>
<p class="MsoNormal"><span lang="EN-US">Hello, <u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">Sorry as most likely this has been already discussed, but as I came “late to the party”, there are things that I surely missed.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">About the need to consider CAA also in the MPDV… I’m thinking about this and I fail to see the risk we’re managing by doing it. My rational is that MPDV, once verifies the domain ownership/control, would also imply that
 records in the DNS (i.e. CAA) are legit.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">The only situation I see where this could apply, is when someone could trick a CAA record during the reuse period of a previously validated domain, so MPDV could verify proper domain control, but the CAA check that must
 be done for each issuance is faked, but I’d say that faking the CAA could have as only logic purpose to enable another CA to issue the certificate, and that CA would also need to check the domain control using MPDV.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">When you decided to include CAA in the game… what was the logic behind?<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Most likely there’s a good reason that clever people has discussed already, so I’d appreciate if you can help me understand better.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Thanks!<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Pedro<u></u><u></u></span></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:8.5pt;color:rgb(246,36,0)"><br>
WISeKey SA</span></b><span lang="EN-US"><u></u><u></u></span></p>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:8.5pt">Pedro Fuentes<br>
</span></b><span lang="EN-US" style="font-size:8.5pt">CSO - Trust Services Manager</span><span lang="EN-US" style="font-size:9pt"><br>
</span><span lang="EN-US" style="font-size:7.5pt">Office: </span><span style="font-size:7.5pt"><a href="tel:+41%2022%20594%2030%2000" target="_blank"><span lang="EN-US">+ 41 (0) 22 594 30 00</span></a></span><span lang="EN-US" style="font-size:7.5pt"><br>
Mobile: + 41 (0) </span><span lang="EN-US" style="font-size:10pt">791 274 790</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:7.5pt">Address: Avenue Louis-Casaï 58 | </span><span lang="EN-US" style="font-size:10pt">1216 Cointrin | Switzerland</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><b><span lang="EN-US" style="font-size:9pt">Stay connected with </span></b><b><span style="font-size:9pt"><a href="http://www.wisekey.com/" target="_blank"><span lang="EN-US" style="color:rgb(246,36,0)">WISeKey</span></a></span></b><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:7.5pt;color:rgb(120,166,0)">THIS IS A TRUSTED MAIL</span></b><span lang="EN-US" style="font-size:7.5pt;color:rgb(120,166,0)">: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey
 please check the signature to avoid security risks</span><span lang="EN-US" style="font-size:9pt"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9pt"><u></u> <u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:7pt;color:darkgray">CONFIDENTIALITY: </span></b><span lang="EN-US" style="font-size:7pt;color:darkgray">This email and any files transmitted with it can be confidential and it’s intended solely
 for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender</span><span lang="EN-US" style="font-size:9pt"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:7pt;color:darkgray">DISCLAIMER: </span></b><span lang="EN-US" style="font-size:7pt;color:darkgray">WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability
 for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail
 are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.</span><span lang="EN-US" style="font-size:9pt"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US">_______________________________________________<br>
Validation mailing list<br>
</span><a href="mailto:Validation@cabforum.org" target="_blank"><span lang="EN-US">Validation@cabforum.org</span></a><span lang="EN-US"><br>
</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_validation&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc&m=DsWs3jyPLw-2N-fE3sPErWvVPxoF-LYnrcdR9WhZMYA&s=GNSe8xPelzQlUicnJyZ8iRap81lwJpyA2HYpTw9jJsI&e=" target="_blank"><span lang="EN-US">https://lists.cabforum.org/mailman/listinfo/validation</span></a><span lang="EN-US"><u></u><u></u></span></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:8.5pt;color:rgb(246,36,0)"><br>
WISeKey SA</span></b><span lang="EN-US"><u></u><u></u></span></p>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:8.5pt;color:black">Pedro Fuentes<br>
</span></b><span lang="EN-US" style="font-size:8.5pt;color:black">CSO - Trust Services Manager</span><span lang="EN-US" style="font-size:9pt;color:black"><br>
</span><span lang="EN-US" style="font-size:7.5pt;color:black">Office: <a href="tel:+41%2022%20594%2030%2000" value="+41225943000" target="_blank">+ 41 (0) 22 594 30 00</a><br>
Mobile: + 41 (0) </span><span lang="EN-US" style="font-size:10pt;color:black">791 274 790</span><span lang="EN-US" style="color:black"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:7.5pt;color:black">Address: </span><span lang="EN-US" style="font-size:7.5pt">Avenue Louis-Casaï 58 | </span><span lang="EN-US" style="font-size:10pt">1216 Cointrin | Switzerland</span><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><b><span lang="EN-US" style="font-size:9pt;color:black">Stay connected with </span></b><b><span style="font-size:9pt;color:black"><a href="http://www.wisekey.com/" target="_blank"><span lang="EN-US" style="color:rgb(246,36,0)">WISeKey</span></a></span></b><span lang="EN-US"><u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:7.5pt;color:rgb(120,166,0)">THIS IS A TRUSTED MAIL</span></b><span lang="EN-US" style="font-size:7.5pt;color:rgb(120,166,0)">: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey
 please check the signature to avoid security risks</span><span lang="EN-US" style="font-size:9pt;color:black"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span lang="EN-US" style="font-size:9pt;color:black"><u></u> <u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:7pt;color:darkgray">CONFIDENTIALITY: </span></b><span lang="EN-US" style="font-size:7pt;color:darkgray">This email and any files transmitted with it can be confidential and it’s intended solely
 for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender</span><span lang="EN-US" style="font-size:9pt;color:black"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:9pt;color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:7pt;color:darkgray">DISCLAIMER: </span></b><span lang="EN-US" style="font-size:7pt;color:darkgray">WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability
 for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail
 are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.</span><span lang="EN-US" style="font-size:9pt;color:black"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>

_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><br>
</div></blockquote></div>