<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 16/5/2024 3:06 μ.μ., Adriano Santoni
via Smcwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100018f814c021b-fd5d49b4-84ae-4062-80b6-698123fcd403-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><font face="Calibri">At any rate, even with </font><font
face="Calibri">a digital signature made with an eIDAS
qualified certificate, you (the CA) cannot tell - in general -
whether the certificate was issued after identifying the
Applicant with the method described in eIDAS Article 24-1a,
rather than 2</font><font face="Calibri">4-1b, </font><font
face="Calibri">or 2</font><font face="Calibri">4-1c, or </font><font
face="Calibri">2</font><font face="Calibri">4-1d. So it is
quite possible that a certain </font><font face="Calibri">an
eIDAS qualified certificate, taken at random, was issued with
any of those 4 methods as regards the individual identity
vetting, AFAIK.<br>
</font></p>
</blockquote>
<br>
There has been a lot of debate on this issue, in ETSI ESI, FESA and
ECATS. The general expectation is that if a TSP is not certain how
the relied-upon certificate has been originally issued, to confirm
that it was issued according to 24-1a or 24-1b, it should not accept
it for 24-1c. Different interpretations may exist but IMO the
Regulation is clear on this issue.<br>
<br>
Obviously the TSP knows how its own certificates have been issued
and can easily apply 24-1c.<br>
<br>
<br>
Dimitris.<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:0100018f814c021b-fd5d49b4-84ae-4062-80b6-698123fcd403-000000@email.amazonses.com">
<p><font face="Calibri"> </font></p>
<p><font face="Calibri">Adriano</font></p>
<p><font face="Calibri"><br>
</font></p>
<div class="moz-cite-prefix">Il 16/05/2024 13:49, Dimitris
Zacharopoulos (HARICA) ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:102989b6-29f9-46f1-8e6b-26fd5333e056@harica.gr">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<title></title>
<div align="center">
<table width="30%" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td valign="top" bgcolor="#ffff00"> <span
style="color: red;">NOTICE:</span> Pay attention -
external email - Sender is <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:dzacharo@harica.gr"
moz-do-not-send="true">dzacharo@harica.gr</a> </td>
</tr>
</tbody>
</table>
<br>
</div>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 13/5/2024 5:03 μ.μ., Adriano
Santoni via Smcwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100018f72443c7c-6dbea188-8c73-47fa-bfd9-913e07cf2929-000000@email.amazonses.com">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<p><font face="Calibri">Hi</font> Martijn<font face="Calibri">,</font></p>
<p><font face="Calibri">I appreciate your concern, but would
not the same concern also arise with a digital signature
made with an eIDAS qualified certificate?<br>
</font></p>
</blockquote>
<br>
Hi Adriano, I missed this thread, apologies my earlier post
didn't take this thread into account, <br>
<br>
If you are referring to eIDAS1 Art. 24-1c this renewal is
allowed only if the relied-upon certificate was issued under
Art. 24-1a or 24-1b. It cannot be used when a request is signed
with a Qualified Certificate issued under Art. 24-1c otherwise
we would fall into the situation that Martijn described. <br>
<br>
<br>
Dimitris. <br>
<br>
<blockquote type="cite"
cite="mid:0100018f72443c7c-6dbea188-8c73-47fa-bfd9-913e07cf2929-000000@email.amazonses.com">
<p>Anyway, it could be addressed by setting a time limit after
which re-validation by other means (to be specified) must be
done, as you suggest.</p>
<p>Regards</p>
<p>Adriano</p>
<p><br>
</p>
<div class="moz-cite-prefix">Il 13/05/2024 15:53, Martijn
Katerbarg ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:SA1PR17MB6503BBDAAB7B5421DAFFFF9CE3E22@SA1PR17MB6503.namprd17.prod.outlook.com">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0cm;
margin-right:0cm;
margin-bottom:8.0pt;
margin-left:0cm;
line-height:115%;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
line-height:normal;
font-size:10.0pt;
font-family:"Courier New";}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:8.0pt;
margin-left:36.0pt;
line-height:115%;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}span.EmailStyle27
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;line-height:115%;mso-fareast-language:EN-US"
lang="EN-US">Hi Adriano,<br>
<br>
My immediate concern would be the scenario where say
in 2024 someone gets an S/MIME IV certificate issued
based on current validation practices. Then in 2 years
time, they renew based on their existing S/MIME
certificate. Then in another two years, again, and yet
again. Soon, we’ll be 10 years since the original
validation took place, and ever since then the CA has
relied upon an existing S/MIME certificate (or CA’s,
if the Subscriber is switching to a different vendor)
without any additional verification.<br>
<br>
Additionally, currently there’s no requirement to
indicate in an SV certificate if an Enterprise RA was
used or not. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;line-height:115%;mso-fareast-language:EN-US"
lang="EN-US">The second item could be solved by adding
an indicator for that into the certificate (See <a
href="https://github.com/cabforum/smime/issues/12"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/cabforum/smime/issues/12</a>),
but I’m not sure how we’d solve the second one, and
I’d be very hesitant on supporting something like
that, without a proper time limit in place at which
point re-validation would need to occur. <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;line-height:115%;mso-fareast-language:EN-US"
lang="EN-US">Regards,<br>
<br>
Martijn<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;line-height:115%;mso-fareast-language:EN-US"><o:p>
</o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div
style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span
style="color:black">From:</span></b> <span
style="color:black">Smcwg-public <a
class="moz-txt-link-rfc2396E"
href="mailto:smcwg-public-bounces@cabforum.org" moz-do-not-send="true"><smcwg-public-bounces@cabforum.org></a>
on behalf of Adriano Santoni via Smcwg-public <a
class="moz-txt-link-rfc2396E"
href="mailto:smcwg-public@cabforum.org"
moz-do-not-send="true"><smcwg-public@cabforum.org></a><br>
<b>Date:</b> Monday, 13 May 2024 at 15:32<br>
<b>To:</b> SMIME Certificate Working Group <a
class="moz-txt-link-rfc2396E"
href="mailto:smcwg-public@cabforum.org"
moz-do-not-send="true"><smcwg-public@cabforum.org></a><br>
<b>Subject:</b> [Smcwg-public] Allowing a
signature made with an S/MIME IV or SV
certificate as an additional individual identity
validation method<o:p></o:p></span></p>
</div>
<div
style="border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt">
<p class="MsoNormal"
style="line-height:12.0pt;background:#FAFA03"> <span
style="font-size:10.0pt;font-family:"Calibri",sans-serif;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.<o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="line-height:normal"> <o:p> </o:p></p>
<div>
<p><span
style="font-family:"Calibri",sans-serif">Hi all,</span><o:p></o:p></p>
<p><span
style="font-family:"Calibri",sans-serif">I already made the
following proposal previously, both in writing
here on the mailing list and also verbally
during the last call (at the very last minutes
as it was not on the agenda, sorry), but I don't
see it mentioned in the call minutes of May 8
below, so I'll try to propose it again.<br>
<br>
Among the methods for the "Validation of
individual identity" (SMBR 3.2.4.2), as part of
the validation process of a request for an
S/MIME IV certificate (or an SV certificate,
where there is no Enterprise RA involved), I
think it would make sense to admit - in addition
to a digital signature based on an eIDAS
compliant qualified certificate - also a digital
signature based on another S/MIME IV or SV
(BR-compliant) certificate of the applicant.
This seems quite logical to me considering the
rigor inherent in the validation requirements
already established by the S/MIME BR to date. </span><o:p></o:p></p>
<p><span
style="font-family:"Calibri",sans-serif">At least in the case
of <i>renewal</i>, I think it would be
completely logical and safe to accept a request
signed by the applicant with his/her current
S/MIME IV or SV certificate (the one soon to
expire) without the need to perform a further
"verification of individual identity" with other
methods. </span><o:p></o:p></p>
<p><span
style="font-family:"Calibri",sans-serif">If this idea for some
reason doesn't seem practical or useful or safe
enough, I'd like someone to explain their
objections or concerns.</span><o:p></o:p></p>
<p><span
style="font-family:"Calibri",sans-serif">Thank you all for
your attention.</span><o:p></o:p></p>
<p><span
style="font-family:"Calibri",sans-serif">Adriano</span><o:p></o:p></p>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal">Il 11/05/2024 22:02, Stephen
Davidson via Smcwg-management ha scritto:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div align="center">
<table class="MsoNormalTable"
style="width:30.0%" width="30%"
cellpadding="0" border="1">
<tbody>
<tr>
<td
style="background:yellow;padding:1.5pt 1.5pt 1.5pt 1.5pt" valign="top">
<p class="MsoNormal"
style="margin-bottom:0cm;line-height:normal"> <span style="color:red">NOTICE:</span>
<span style="color:black">Pay
attention - external email - Sender
is <a
href="mailto:0100018f693fd56b-e31b4721-c8ba-4ae7-a5bb-de9b42be70ce-000000@amazonses.com"
moz-do-not-send="true"
class="moz-txt-link-freetext">0100018f693fd56b-e31b4721-c8ba-4ae7-a5bb-de9b42be70ce-000000@amazonses.com</a></span>
<o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"
style="margin-bottom:0cm;text-align:center;line-height:normal"
align="center"><o:p> </o:p></p>
<p class="MsoNormal"
style="margin-bottom:0cm;line-height:normal"> <o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:0cm">##
Minutes of SMCWG<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">May
8, 2024<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">These
are the Draft Minutes of the meeting described
in the subject of this message. Corrections
and clarifications where needed are encouraged
by reply.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">##
Attendees<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">Abhishek
Bhat - (eMudhra), Adriano Santoni - (Actalis
S.p.A.), Aggie Wang - (TrustAsia), Andrea
Holland - (VikingCloud), Ashish Dhiman -
(GlobalSign), Ben Wilson - (Mozilla), Bruce
Morton - (Entrust), Clint Wilson - (Apple),
Corey Bonnell - (DigiCert), Dimitris
Zacharopoulos - (HARICA), Inaba Atsushi -
(GlobalSign), Inigo Barreira - (Sectigo),
Janet Hines - (VikingCloud), Judith Spencer -
(CertiPath), Keshava Nagaraju - (eMudhra),
Marco Schambach - (IdenTrust), Martijn
Katerbarg - (Sectigo), Morad Abou Nasser -
(TeleTrust), Mrugesh Chandarana - (IdenTrust),
Nome Huang - (TrustAsia), Rebecca Kelly -
(SSL.com), Renne Rodriguez - (Apple), Rollin
Yu - (TrustAsia), Scott Rea - (eMudhra),
Stefan Selbitschka - (rundQuadrat), Stephen
Davidson - (DigiCert), Tadahiko Ito - (SECOM
Trust Systems), Tathan Thacker - (IdenTrust),
Tsung-Min Kuo - (Chunghwa Telecom), Wendy
Brown - (US Federal PKI Management Authority)<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">##
1. Roll Call<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">The
Roll Call was taken.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">##
2. Read Antitrust Statement<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">The
statement was read concerning the antitrust
policy, code of conduct, and intellectual
property rights agreement.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">##
3. Review Agenda<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">Minutes
were prepared by Stephen Davidson.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">##
4. Approval of minutes from last
teleconference<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">The
minutes for the teleconference of April 24
were approved.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">##
5. Discussion<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal">Stephen Davidson noted that
Ballot SMC06 was in IPR until May 11. See <a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fsmcwg-public%2F2024-April%2F000957.html&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C708f7bd916fb456126ba08dc73512026%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512039511762331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BHKcC9wi8xSZNIvCbF96gxjYbCI1d3s1SwRCdNpXMQw%3D&reserved=0"
moz-do-not-send="true">https://lists.cabforum.org/pipermail/smcwg-public/2024-April/000957.html</a>.<o:p></o:p></p>
<p class="MsoNormal">The WG discussed and
approved the change of KeyFactor from an
Interested Party to an Associate Member, Ellie
Schieder as an Interested Party, and Posteo
e.K as a Certificate Consumer.<o:p></o:p></p>
<p class="MsoNormal">The WG reviewed and
discussed a ballot proposed by Martijn
Katerbarg which would bring the S/MIME BR up
to date with a recent ballot at the TLS BR for
logging. See more at <a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fsmime%2Fissues%2F241&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C708f7bd916fb456126ba08dc73512026%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512039511777400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zsu0bwRhIDoxPPlahVUlbI%2B%2FU7VdcyIjSfYHixo1JAk%3D&reserved=0"
moz-do-not-send="true">https://github.com/cabforum/smime/issues/241</a>
<o:p></o:p></p>
<p class="MsoNormal">The WG had an extensive
discussion regarding the migration to
Multipurpose/Strict profiles. Stephen noted
that so far only two points had been raised by
Certificate Issuers:<o:p></o:p></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l1 level1 lfo1">Having adequate time
(such as one year) to allow ERAs using
integration time to adapt.<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0cm;mso-list:l1 level1 lfo1">Concerns relating to the
impact of shorter validity on deployments
using tokens/smartcards.<o:p></o:p></li>
</ul>
<p class="MsoNormal" style="margin-bottom:0cm">Judith
Spencer and Wendy Brown commented that the
shorter validity had real impact on large
(including public sector) deployments that use
tokens/smartcards, including:<o:p></o:p></p>
<ul style="margin-top:0cm" type="disc">
<li class="MsoListParagraph"
style="margin-bottom:0cm;margin-left:0cm;mso-list:l0 level1 lfo2">limited
storage on tokens/smartcards;<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-bottom:0cm;margin-left:0cm;mso-list:l0 level1 lfo2">the
increased burden of key exchange; and<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-bottom:0cm;margin-left:0cm;mso-list:l0 level1 lfo2">and
the costs of support for rekeying.<o:p></o:p></li>
</ul>
<p class="MsoNormal" style="margin-bottom:0cm">The
question was raised whether it would be
feasible to increase the validity for the
Multipurpose profile to 1185 days in general,
or in cases where tokens/smartcards are used.
Clint Wilson spoke about the security and
crypto agility benefits of shorter validity
periods. It was agreed this topic would be
continued in Bergamo.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">##
6. Any Other Business<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">None.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">##
7. Next call<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">Next
call: the teleconference scheduled for May 22
has been cancelled. Next meeting is Bergamo
F2F.<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">##
Adjourned<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:0cm">
<o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;line-height:115%"> </span><o:p></o:p></p>
</div>
<p class="MsoNormal"
style="margin-bottom:0cm;line-height:normal"> <br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Smcwg-management mailing list<o:p></o:p></pre>
<pre><a
href="mailto:Smcwg-management@cabforum.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">Smcwg-management@cabforum.org</a><o:p></o:p></pre>
<pre><a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fsmcwg-management&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C708f7bd916fb456126ba08dc73512026%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512039511787973%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jyn4cbSuAbphPNeqicGutRFnz8pdQU98ccl8W0GxW8Q%3D&reserved=0"
moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/smcwg-management</a><o:p></o:p></pre>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Smcwg-public mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Smcwg-public@cabforum.org" moz-do-not-send="true">Smcwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext"
href="https://lists.cabforum.org/mailman/listinfo/smcwg-public"
moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a>
</pre>
</blockquote>
<br>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Smcwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Smcwg-public@cabforum.org">Smcwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/smcwg-public">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a>
</pre>
</blockquote>
<br>
</body>
</html>