<div dir="ltr">Let's Encrypt performs multi-perspective CAA checking during initial validation, when we are also performing multi-perspective domain control validation. We do not see any particular increase in failure rates due to CAA checking specifically. It is worth noting that Let's Encrypt does not do any Authorization Domain coalescing: if a certificate request contains 50 domains all under the same base domain, we will still conduct validation for all 50 domains individually. So multi-perspective CAA is not causing us to perform 51 queries instead of 1, it's causing us to perform 100 queries instead of 50 (from each perspective).<div><br></div><div>However, if certificate issuance is occurring more than 8 hours after initial validation, and CAA needs to be re-checked, we then do that re-checking only from our primary vantage point. This is because many ACME clients do not support asynchronous finalization, so the CAA recheck has to happen while the client is maintaining an open connection during its Finalize call.</div><div><br></div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 26, 2023 at 2:30 AM Dimitris Zacharopoulos (HARICA) 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>
<br>
After revisiting this issue, I somewhat agree with Pedro's
assessment that for the "Agreed-upon change to website" and "DNS"
methods, checking CAA DNS records from multiple vantage points is
redundant and will only create additional cost and delays without
any significant security improvements.<br>
<br>
To give an example, assume a CA receives a request to include 50
Domain Names and the Applicant chooses to use the "DNS Change"
Domain Validation method. Some of those Domain Names may contain the
same Base Domain Name. In that case, it is likely that the CA will
only need to validate the Base Domain Names, but the CAA query must
take place for all Domain Names requested.<br>
<br>
The DNS checks for the Random Value or Request Token would be
optimized and would result to the least amount of traffic and delay.
MPDV would protect against BGP hijacking so the Domain Validation is
covered, even if the CAA records are assumed to be "hijacked".<br>
<br>
If the CA is using 3 locations for MPDV (in addition to the main
audited location), the CAA checks will result in 4 times more
traffic (200 queries instead of 50), just for the CAA. And that's
just for 1 certificate. <br>
<br>
Therefore, I would recommend removing the mandatory requirement to
check CAA records via multiple vantage points in the first
implementation of the MPDV concept, in order to first evaluate the
effectiveness and possible issues that will come up. If the group
determines that MPDV works as designed/expected and that the
additional traffic caused is not an issue, we could explore adding
multiple vantage point checks for CAA records as well, but focusing
more on the non-DNS/agreed-upon change to website methods.<br>
<br>
It would also be helpful to hear from CAs that already implement
MPDV (Let's Encrypt ?) if they also query CAA records from multiple
vantage points for each issuance and how this has affected their
traffic volume and resources.<br>
<br>
<br>
Best regards,<br>
Dimitris.<br>
<br>
<div>On 21/6/2023 11:38 μ.μ., Pedro FUENTES
via Validation wrote:<br>
</div>
<blockquote type="cite">
Thanks, Martin, for the additional insights.
<div><br>
</div>
<div>Yes, tricking CAA to use mail validation is the risk I can
see, as other methods would rely on MPDV and issuance seems to
be prevented as far I can see. I was trying to figure out the
other situations identified below.</div>
<div><br>
</div>
<div>Now about “Since Attacker can perform a BGP hijack on CA B,
they’re able to reroute the email to their own servers”… I think
this is not so straightforward as it sounds, because nowadays is
more and more rare that companies run their own mail servers,
but there’s a trend to use cloud services for email… so the BGP
hijack would need to attack the service provider (Amazon,
Microsoft and the like), and that’s not so easy as just
rerouting IP traffic in the CA endpoint.</div>
<div><br>
</div>
<div>Anyway, if the conclusion here is that the reason to apply
MPDV to CAA is that we thunk that e-mail based DCV is unsafe,
then I guess we’re opening up a Pandora Box… :)</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Pedro<br>
<div><br>
<blockquote type="cite">
<div>On 21 Jun 2023, at 22:08, Martijn Katerbarg <a href="mailto:martijn.katerbarg@sectigo.com" target="_blank"><martijn.katerbarg@sectigo.com></a>
wrote:</div>
<br>
<div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Pedro,<u></u><u></u></span></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"><u></u> <u></u></span></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><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></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"><u></u> <u></u></span></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><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.<span> </span><u></u><u></u></span></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><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></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"><u></u> <u></u></span></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><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></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"><u></u> <u></u></span></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Regards,<br>
<br>
Martijn<u></u><u></u></span></div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="en-SE"><u></u> <u></u></span></div>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0cm 0cm">
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span lang="EN-US">From:</span></b><span lang="EN-US"><span> </span>Validation
<<a href="mailto:validation-bounces@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">validation-bounces@cabforum.org</a>><span> </span><b>On
Behalf Of<span> </span></b>Pedro
FUENTES via Validation<br>
<b>Sent:</b><span> </span>Wednesday,
21 June 2023 19:19<br>
<b>To:</b><span> </span>Ryan
Dickson <<a href="mailto:ryandickson@google.com" style="color:blue;text-decoration:underline" target="_blank">ryandickson@google.com</a>><br>
<b>Cc:</b><span> </span>CA/Browser
Forum Validation SC List <<a href="mailto:validation@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">validation@cabforum.org</a>><br>
<b>Subject:</b><span> </span>Re:
[cabf_validation] [EXTERNAL]-Re: Question about
MPDV and CAA<u></u><u></u></span></div>
</div>
</div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<div style="border:1pt solid black;padding:2pt">
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif;line-height:12pt;background:rgb(250,250,3)"><span style="font-size:10pt">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></div>
</div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">Hi Ryan,<span> </span><u></u><u></u></div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">Thanks for the
reply. This make things much clear to me.<u></u><u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">My
interpretation of your risk scenarios are:<u></u><u></u></div>
</div>
<div>
<ol style="margin-bottom:0cm" type="1" start="1">
<li class="MsoNormal" style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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></li>
<li class="MsoNormal" style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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></li>
<li class="MsoNormal" style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">“no-issue” CAA record… again, given
than MPDV must still be used, I fail to see the
risk.<u></u><u></u></li>
</ol>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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></div>
</div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">Best,<u></u><u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">Pedro<u></u><u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><br>
<br>
<u></u><u></u></div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">On 21 Jun
2023, at 15:18, Ryan Dickson <<a href="mailto:ryandickson@google.com" style="color:blue;text-decoration:underline" target="_blank">ryandickson@google.com</a>>
wrote:<u></u><u></u></div>
</div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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. <span> </span><u></u><u></u></div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><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.<span> </span><br>
<br>
As always, other considerations and
perspectives are welcome!<span> </span><br>
<br>
Thanks,<br>
Ryan<u></u><u></u></div>
</div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">On Fri, Jun 16, 2023 at
6:43 AM Pedro FUENTES via Validation
<<a href="mailto:validation@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">validation@cabforum.org</a>>
wrote:<u></u><u></u></div>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">Hello,<span> </span><u></u><u></u></div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">When you decided to
include CAA in the game… what was
the logic behind?<u></u><u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">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></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">Thanks!<u></u><u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">Pedro<u></u><u></u></div>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:8.5pt;color:rgb(246,36,0)"><br>
WISeKey SA</span></b><u></u><u></u></div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:8.5pt">Pedro Fuentes<br>
</span></b><span style="font-size:8.5pt">CSO - Trust Services Manager</span><span style="font-size:9pt"><br>
</span><span style="font-size:7.5pt">Office:<span> </span><a href="tel:+41%2022%20594%2030%2000" style="color:blue;text-decoration:underline" target="_blank">+
41 (0) 22 594
30 00</a><br>
Mobile: + 41
(0) </span><span style="font-size:10pt">791 274 790</span><u></u><u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:7.5pt">Address: Avenue Louis-Casaï 58 | </span><span style="font-size:10pt">1216 Cointrin | Switzerland</span><u></u><u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:9pt">Stay connected with <a href="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wisekey.com%2F&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C453206dbe65948fc195908db727b9eea%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638229647491007545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RCkHjL9dW1XoPxlnQis2WJJq6Lo%2BOnG%2FU4BGa7yTwTE%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank"><span style="color:rgb(246,36,0)">WISeKey</span></a><br>
</span></b><span style="font-size:7.5pt;color:darkgray"><br>
<br>
</span><u></u><u></u></div>
</div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:7.5pt;color:rgb(120,166,0)">THIS IS A TRUSTED
MAIL</span></b><span 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 style="font-size:9pt"><u></u><u></u></span></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:9pt"><u></u> <u></u></span></div>
</div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:7pt;color:darkgray">CONFIDENTIALITY: </span></b><span 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 style="font-size:9pt"><u></u><u></u></span></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:9pt"><u></u> <u></u></span></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:7pt;color:darkgray">DISCLAIMER: </span></b><span 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 style="font-size:9pt"><u></u><u></u></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>
</div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif">_______________________________________________<br>
Validation mailing list<br>
<a href="mailto:Validation@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">Validation@cabforum.org</a><br>
<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__lists.cabforum.org_mailman_listinfo_validation%26d%3DDwMFaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DAFTYu1HAQdkStwzgxyDbKOLyDwTHEezL5yeqoxeZ0fc%26m%3DDsWs3jyPLw-2N-fE3sPErWvVPxoF-LYnrcdR9WhZMYA%26s%3DGNSe8xPelzQlUicnJyZ8iRap81lwJpyA2HYpTw9jJsI%26e%3D&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C453206dbe65948fc195908db727b9eea%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638229647491007545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KdHwP%2F6wqizcIHozfWKf022XyDxDxTYfjYhPTLDdXtg%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a><u></u><u></u></div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:8.5pt;color:rgb(246,36,0)"><br>
WISeKey SA</span></b><u></u><u></u></div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:8.5pt">Pedro Fuentes<br>
</span></b><span style="font-size:8.5pt">CSO - Trust
Services Manager</span><span style="font-size:9pt"><br>
</span><span style="font-size:7.5pt">Office: + 41 (0)
22 594 30 00<br>
Mobile: + 41 (0) </span><span style="font-size:10pt">791
274 790</span><span><u></u><u></u></span></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:7.5pt">Address: </span><span style="font-size:7.5pt">Avenue
Louis-Casaï 58 | </span><span style="font-size:10pt">1216
Cointrin | Switzerland</span><u></u><u></u></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:9pt">Stay connected
with <a href="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wisekey.com%2F&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C453206dbe65948fc195908db727b9eea%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638229647491007545%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RCkHjL9dW1XoPxlnQis2WJJq6Lo%2BOnG%2FU4BGa7yTwTE%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank"><span style="color:rgb(246,36,0)">WISeKey</span></a><br>
</span></b><span style="font-size:7.5pt;color:darkgray"><br>
<br>
</span><u></u><u></u></div>
</div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:7.5pt;color:rgb(120,166,0)">THIS
IS A TRUSTED MAIL</span></b><span 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 style="font-size:9pt"><u></u><u></u></span></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:7pt;color:darkgray"><br>
<br>
</span><span style="font-size:9pt"><u></u><u></u></span></div>
</div>
<div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:7pt;color:darkgray">CONFIDENTIALITY: </span></b><span 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 style="font-size:9pt"><u></u><u></u></span></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:9pt"><u></u> <u></u></span></div>
</div>
<div>
<div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span style="font-size:7pt;color:darkgray">DISCLAIMER: </span></b><span 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></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<div>
<div dir="auto" style="text-align:start;text-indent:0px">
<div dir="auto" style="text-align:start;text-indent:0px">
<div dir="auto" style="text-align:start;text-indent:0px">
<div style="text-align:start;text-indent:0px">
<div style="text-align:start;text-indent:0px">
<div style="text-align:start;text-indent:0px">
<div style="text-align:start;text-indent:0px">
<div style="text-align:start;text-indent:0px">
<div style="text-align:start;text-indent:0px">
<div style="text-align:start;text-indent:0px"><font style="color:rgb(0,0,0);letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;line-height:normal;text-align:start;text-indent:0px"><b><font style="font-size:11px" color="#f62400"><br>
WISeKey SA<br>
</font></b></font>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-variant:normal;line-height:normal;text-align:start;text-indent:0px"><font style="color:rgb(0,0,0);font-size:12px;font-weight:normal;font-style:normal"><span style="font-size:11px"><b>Pedro Fuentes<br>
</b>CSO - Trust Services Manager</span><br>
<font size="1">Office: + 41 (0) 22 594
30 00<br>
Mobile: + 41 (0) </font></font><span style="color:rgb(0,0,0);font-size:x-small;font-weight:normal;font-style:normal">791 274 790</span></div>
<div style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;line-height:normal;text-align:start;text-indent:0px"><font style="color:rgb(0,0,0);font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><font size="1">Address: </font></font><font size="1">Avenue Louis-Casaï 58 | </font><span style="font-size:x-small">1216
Cointrin | Switzerland</span></div>
<div style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;line-height:normal;text-align:start;text-indent:0px"><font><font style="color:rgb(0,0,0);font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" size="1"><b>Stay connected with <a href="http://www.wisekey.com" target="_blank"><font color="#f62400">WISeKey</font></a><br>
</b></font></font><span style="color:rgb(169,169,169);font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br>
</span></div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;line-height:normal;text-align:start;text-indent:0px">
<div style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;line-height:normal"><span><font size="1" color="#78a600"><b>THIS
IS A TRUSTED MAIL</b>: This
message is digitally signed with a
WISeKey identity. If you get a
mail from WISeKey please check
the signature to avoid security
risks</font></span></div>
<div style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;line-height:normal"><span style="font-size:9px"><font color="#a9a9a9"><br>
</font></span></div>
<div style="font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;line-height:normal">
<div><font style="font-size:9px" color="#a9a9a9"><b>CONFIDENTIALITY: </b>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</font></div>
<div><font style="font-size:9px" color="#a9a9a9"><br>
</font></div>
<div><font style="font-size:9px" color="#a9a9a9"><b>DISCLAIMER: </b>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.</font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Validation mailing list
<a href="mailto:Validation@cabforum.org" target="_blank">Validation@cabforum.org</a>
<a href="https://lists.cabforum.org/mailman/listinfo/validation" target="_blank">https://lists.cabforum.org/mailman/listinfo/validation</a>
</pre>
</blockquote>
<br>
</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>
</blockquote></div>