<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Calibri">Dimitris,</font></p>
<p>although the QSCD/SSCD issue may not be germane to this
discussion .... can you point me to any QSCD device whose CC
certification is based on a PP other than the one I mentioned? Or
put another way, can you explain what are the differences between
QSCDs and SSCDs? I am asking this candidly: I do not know, so I'd
love to learn.<br>
</p>
<p>Coming back to the "core" issue: <br>
</p>
<p>I will give a concrete example of a device which, although it can
be said (with a lot of poetic license, IMO) that it has a CC
certification, I believe it does not meet the requirements of
§16.3 (as I understand them). The "Nitrokey" product mentioned
by
Tomas some time ago is actually a family of devices with very
different characteristics from each other. One of these, called
"Nitrokey Pro", is based on a microcontroller (i.e. the HW
component) with CC EAL5 + certification [1]. AFAIK, it is a very
good microchip that has been used a lot, albeit now obsolete.
Well, that microchip /in itself/ doesn't have any functionality to
1) generate RSA or ECC keys, 2) execute signatures with those
keys, 3) protect those keys. These features are (more or less)
implemented by the Nitrokey firmware, which has no CC
certification (please note: I am not saying that such firmware is
or is not secure). If I am saying something wrong, I'd love to be
corrected.<br>
</p>
<p>In short, in my opinion that device - although in practice it may
be used and perhaps works very well - does not comply with §16.3,
unless we clarify that the CC certification mentioned in §16.3
is
to be understood as referring to any part of the device, and
without reference to any particular functionality (if this is the
interpretation that the WG prefers).</p>
<p>[1]
<a class="moz-txt-link-freetext" href="https://www.commoncriteriaportal.org/files/epfiles/0555a_pdf.pdf">https://www.commoncriteriaportal.org/files/epfiles/0555a_pdf.pdf</a><br>
</p>
<p>Adriano</p>
<p><br>
</p>
<div class="moz-cite-prefix">Il 21/04/2021 19:55, Dimitris
Zacharopoulos (HARICA) ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:320c7141-099b-8e66-1da8-9790aa2c4a64@harica.gr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<br>
<br>
<div class="moz-cite-prefix">On 21/4/2021 4:07 μ.μ., Adriano
Santoni via Cscwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01000178f48b387f-ae072308-6dbf-48d5-bed5-613665e8870f-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p><font face="Calibri">Hi Dimitris,</font></p>
<p>I am certainly /not/ a Common Criteria expert. However I
believe it is appropriate for my role to try and get
acquainted with at least the basics of such matter, also in
order to be able to provide satisfactory answers to auditors
:) <br>
</p>
<p>On the other hand, similar questions may also arise with
regard to the HSMs used for signing certificates (and
timestamps): the standards (both CABF and ETSI) require the
CA/TSA to use an HSM with either FIPS o CC security
certification, but when it comes to CC not all certifications
are equivalent, so a minimum of analysis and discernment is
required by those who select those HSMs. Therefore, I expect
that in every responsible CA organization there is at least
one person who knows "just enough" about this subject (without
necessarily being an expert), namely FIPS 140-2 and CC
certifications, to be able to make or suggest a sensible
choice, and one that is tenable in front of an auditor.</p>
<p>Coming to your questions and comments:<br>
</p>
<p>* I like the idea of a guidance web page, like the one you
mentioned.<br>
</p>
<p>* I disagree that a QSCD is more secure than an SSCD; my
understanding is that QSCD is essentially a new name for an
old thing (the SSCD), and in fact the devices referred to as
QSCD on <a class="moz-txt-link-freetext"
href="https://esignature.ec.europa.eu/efda/notification-tool/#/screen/browse/list/QSCD_SSCD"
moz-do-not-send="true">https://esignature.ec.europa.eu/efda/notification-tool/#/screen/browse/list/QSCD_SSCD</a>
are often "in SSCD configuration" as shown by the relevant STs
(see for example <a class="moz-txt-link-freetext"
href="https://www.ssi.gouv.fr/uploads/2020/08/anssi-cible-cc-2020_73en"
moz-do-not-send="true">https://www.ssi.gouv.fr/uploads/2020/08/anssi-cible-cc-2020_73en</a>.
pdf, but there are many others) and their STs refer to the
old, obsolete but still used "Protection Profiles for Secure
Signature Creation Device" (see for example <a
class="moz-txt-link-freetext"
href="https://www.sogis.eu/documents/cc/pp/sc/sscd/obsolete/pp0059a.pdf"
moz-do-not-send="true">https://www.sogis.eu/documents/cc/pp/sc/sscd/obsolete/pp0059a.pdf</a>)<br>
</p>
</blockquote>
<br>
This is not my understanding at all. Some chips/components may be
the same, but the certification is new. It's not a
re-certification.<br>
<br>
<blockquote type="cite"
cite="mid:01000178f48b387f-ae072308-6dbf-48d5-bed5-613665e8870f-000000@email.amazonses.com">
<p> </p>
<p> </p>
<blockquote type="cite"> Is there some document/rule that
SSCD/QSCD devices must meet the three security features you
listed?</blockquote>
No, and I have not said that there exists any. <br>
<p>What I am proposing is that CAs make sure the crypto modules
used by their Subscribers (for Code Signing purposes) have a
CC certification (unless they have a proper FIPS 140-2
certification) whose Security Target includes those three
security features. These latter may not be expressed with
exactly the same words that I used, because there is no such
requirement for a ST (AFAIK). So, yes, it's up to the CA to
figure out (or have someone figure out for them) if the ST of
some crypto module includes those three security features.
It's not always straightforward, but some guidance can be
provided. <br>
</p>
<p>For example, regarding QSCDs/SSCDs, their CC certifications
are usually based on STs claiming conformance to the
"Protection profiles for secure signature creation device -
Part 2: Device with key generation" (<a
class="moz-txt-link-freetext"
href="https://www.commoncriteriaportal.org/files/ppfiles/pp0059b_pdf.pdf"
moz-do-not-send="true">https://www.commoncriteriaportal.org/files/ppfiles/pp0059b_pdf.pdf</a>).
This PP mandates the following security functions:</p>
<p>* 10.2.2.1 FCS_CKM.1 Cryptographic key generation (page 28)</p>
<p>* 10.2.2.3 FCS_COP.1 Cryptographic operation (page 28)</p>
<p>* 10.2.3 User data protection (FDP) (page 29 and on)</p>
<p>Note that I am not suggesting that we should recommend
QSCDs/SSCDs, it's just one of a number of alternatives.<br>
</p>
<p>Another example can be made for Java Card -based devices,
whose ST usually claims conformance to the Java Card
Protection Profile (<a class="moz-txt-link-freetext"
href="https://www.commoncriteriaportal.org/files/ppfiles/ANSSI-CC-profil_PP-2010-03en.pdf"
moz-do-not-send="true">https://www.commoncriteriaportal.org/files/ppfiles/ANSSI-CC-profil_PP-2010-03en.pdf</a>).
This PP mandates the following security functions:</p>
<p>* FCS_CKM.1 Cryptographic key generation (page 71)<br>
</p>
<p>* FCS_COP.1 Cryptographic operation (page 72)</p>
<p>* FCS_CKM.3 Cryptographic key access (page 71) => refers
to the Java Card API that imply PIN-based user authentication</p>
<p>Again, I want to emphasize that I am no expert, not trying to
propose myself as one, and these are just proposals, based on
my own comprehension of the matter, and any discussion on them
is more than welcome.<br>
</p>
</blockquote>
<br>
I will let others chime in and provide feedback if they expect
this type of information to be clear and unambiguous for a CA and
an auditor that has to examine certifications and security target
documents for specific crypto devices.<br>
<br>
My opinion is that without the proper guidance from this group,
this is too complicated and will cause mistakes and confusion.<br>
<br>
<br>
Dimitris.<br>
<br>
<blockquote type="cite"
cite="mid:01000178f48b387f-ae072308-6dbf-48d5-bed5-613665e8870f-000000@email.amazonses.com">
<p> </p>
<p>Adriano</p>
<p><br>
</p>
<div class="moz-cite-prefix">Il 21/04/2021 10:31, Dimitris
Zacharopoulos (HARICA) via Cscwg-public ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:01000178f38dd465-2b85776e-001d-4d97-803e-cd9eb7e902b2-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<br>
Hi Adriano,<br>
<br>
See answers inline.<br>
<br>
<div class="moz-cite-prefix">On 21/4/2021 10:34 π.μ., Adriano
Santoni via Cscwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01000178f359feef-42c042b1-601d-4514-90ce-65532288a221-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p><font face="Calibri">Hi Dimitris,</font></p>
<p><font face="Calibri">to avoid misunderstandings: I am not
at all suggesting to impose "additional"</font><font
face="Calibri">requirements on crypto modules for Code
Signing (by the Subscriber), but only to consider those
devices that include the thhree security functions I
have listed, which after all are quite common.<br>
</font></p>
</blockquote>
<br>
<font face="Calibri">Perhaps I wrote it in an unclear way. I
agree that most probably these are not "additional"
requirements but more "specific" requirements that should
already be fulfilled by existing certified crypto modules.
My concern is how auditors/CAs will find supporting evidence
that describes that these "specific" requirements are met.<br>
<br>
Does that make sense?<br>
<br>
<br>
</font>
<blockquote type="cite"
cite="mid:01000178f359feef-42c042b1-601d-4514-90ce-65532288a221-000000@email.amazonses.com">
<p><font face="Calibri"> </font></p>
<p><font face="Calibri">For most cases it seems a relatively
simple task to me. I'd prefer not to name products,
however, if not absolutely necessary. I will try and
provide some hints below. If this is not enough to
clarify, I will provide some specific links.<br>
<br>
First of all, it is useful to remember that a complete
list of devices such as smart cards that have a CC
certification can be found on the website <a
class="moz-txt-link-freetext"
href="https://www.commoncriteriaportal.org/products/"
moz-do-not-send="true">https://www.commoncriteriaportal.org/products/</a>,
and for each of them there is a link to download the
Security Target. <br>
</font></p>
</blockquote>
<br>
As you know, reviewing the Security Target is a very
challenging task. Most of these documents are quite long (more
than 100 pages). Even the certifications themselves are often
10-30 pages long.<br>
<br>
<blockquote type="cite"
cite="mid:01000178f359feef-42c042b1-601d-4514-90ce-65532288a221-000000@email.amazonses.com">
<p><font face="Calibri"> </font></p>
<p><font face="Calibri">That said, many of the devices
listed here are (or are based on) Java Cards platforms
conforming to the relevant Oracle specifications [1],
and in that case we already know that the three security
functions that I have listed are certainly implemented
(as they are part of those specifications). For example,
devices based on the NXP's "JCOP" platform fall into
this category. The same applies to devices based on
Thales' (formerly Gemalto) "MultiApp" platform,
G&D's SmartCafé platform and several others.<br>
</font></p>
</blockquote>
<br>
<blockquote type="cite"
cite="mid:01000178f359feef-42c042b1-601d-4514-90ce-65532288a221-000000@email.amazonses.com">
<p><font face="Calibri"> However, there also are "native"
(non Java Card-based) Card Operating Systems, such as
e.g. Atos' (formerly Siemens) "CardOS", also featuring
those three security functions, as it can be easily
inferred from the related STs.<br>
<br>
</font></p>
</blockquote>
<br>
I understand that there are experts like yourself that are
familiar with these terms but I'm afraid without the proper
guidance from the CSBRs or the Code Signing WG, CAs and
auditors will certainly have difficulties proving that certain
devices meet these <b>more specific</b> requirements of the
security target. Perhaps the WG could write an article like <a
class="moz-txt-link-freetext"
href="https://cabforum.org/guidance-ip-addresses-certificates/"
moz-do-not-send="true">https://cabforum.org/guidance-ip-addresses-certificates/</a>
or <a class="moz-txt-link-freetext"
href="https://cabforum.org/internal-names/"
moz-do-not-send="true">https://cabforum.org/internal-names/</a>
about how a CA or an auditor can find the proper evidence to
support the specific requirements of the newly proposed
section 16.3.<br>
<br>
<blockquote type="cite"
cite="mid:01000178f359feef-42c042b1-601d-4514-90ce-65532288a221-000000@email.amazonses.com">
<p><font face="Calibri"> Another simple rule of thumb for
understanding which devices are eligible is to consider
devices that are certified as "secure signature devices"
according to EU regulations (eIDAS), i.e. as SSCD / QSCD
devices, because this implies (let me simplify the
reasoning) having the three security features I have
listed. <br>
</font></p>
</blockquote>
<br>
Is there some document/rule that SSCD/QSCD devices must meet
the three security features you listed?<br>
<br>
<blockquote type="cite"
cite="mid:01000178f359feef-42c042b1-601d-4514-90ce-65532288a221-000000@email.amazonses.com">
<p><font face="Calibri"> </font></p>
<p><font face="Calibri">A list of devices already selected
according to this criterion can be found at <a
class="moz-txt-link-freetext"
href="https://esignature.ec.europa.eu/efda/notification-tool/#/screen/browse/list/QSCD_SSCD"
moz-do-not-send="true">https://esignature.ec.europa.eu/efda/notification-tool/#/screen/browse/list/QSCD_SSCD</a>,
. For the reasons above, I would consider all the
smartcard-type devices listed therein as (potentially)
suitable Subscriber devices for Code Signing <br>
</font></p>
</blockquote>
<br>
I support adding a normative rule that CAs MAY consider that
devices listed as Qualified Signature Creation Devices (QSCDs)
as defined in point 23 of Article 2 of Regulation (EU)
910/2014, meet the technical specifications and requirements
of section 16.3. Then they can use the list you provided to
simplify the evidence proof.<br>
<br>
I would rule out SSCDs as they are no longer considered as
secure as the QSCDs. Most of them have expired certifications.<br>
<br>
<blockquote type="cite"
cite="mid:01000178f359feef-42c042b1-601d-4514-90ce-65532288a221-000000@email.amazonses.com">
<p><font face="Calibri"> </font></p>
<p><font face="Calibri">Of course, having considered some
devices based on the above criteria, it remains to be
verified if they do support RSA keys up to 3072 bits or
at least ECC P256 keys, which is not true for all of
them, and if they are accompanied by suitable drivers
(i.e. PKCS#11 and CSP/Minidriver). But these are not
matters for the WG to discuss.<br>
</font></p>
</blockquote>
<br>
I agree. <br>
<br>
<blockquote type="cite"
cite="mid:01000178f359feef-42c042b1-601d-4514-90ce-65532288a221-000000@email.amazonses.com">
<p><font face="Calibri"> </font></p>
<p><font face="Calibri">Let me know if this answers your
question.<br>
</font></p>
</blockquote>
<br>
This is an interesting discussion and I think we can make some
good progress and improve this section.<br>
<br>
<br>
Dimitris.<br>
<br>
<blockquote type="cite"
cite="mid:01000178f359feef-42c042b1-601d-4514-90ce-65532288a221-000000@email.amazonses.com">
<p><font face="Calibri"> </font></p>
<p><font face="Calibri">[1] <a
class="moz-txt-link-freetext"
href="https://www.oracle.com/java/technologies/javacard-specs-downloads.html"
moz-do-not-send="true">https://www.oracle.com/java/technologies/javacard-specs-downloads.html</a><br>
</font></p>
<p><font face="Calibri">Regards,<br>
</font></p>
<p><font face="Calibri">Adriano</font></p>
<p><br>
</p>
<div class="moz-cite-prefix">Il 20/04/2021 13:26, Dimitris
Zacharopoulos (HARICA) via Cscwg-public ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:01000178ef083b82-742a3605-7f6d-4e62-8d3c-a640a77022ed-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<br>
Adriano,<br>
<br>
Can you please share some examples of public
certifications of equipment (HSMs and/or crypto-tokens)
that contain this additional TOE security requirements
information? This will be helpful for CAs and subscribers
when deciding what equipment to purchase, but also
auditors that will check that this equipment meets the
compliance requirements.<br>
<br>
<br>
Thank you,<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 19/4/2021 4:31 μ.μ.,
Adriano Santoni via Cscwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01000178ea5447e9-fee2f4ca-e086-49f1-a998-1452c2f12b02-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p><font face="Calibri">All,</font></p>
<p>as agreed during the last CSWG call, I am attaching
to this post a first attempt to revise CSBR §16.3
aimed at clarifyng what kind of CC certifications can
reasonably be considered acceptable of a hardware
crypto module for code signing (by the Subscriber).</p>
<p>I cannot help but observe, however, that the third
option (bullet) in §16.3, although later on is "not
recommended", is still allowed although antithetical
to the second. Basically, this is saying: "you must
use a certified device, but not necessarily". From a
logical point of view, it seems to me that it makes no
sense. I suppose there is a rationale, probably
discussed a long time ago ...<br>
</p>
<p>Regards</p>
<p>Adriano</p>
<p><br>
</p>
<div class="moz-cite-prefix">Il 14/04/2021 22:08, Bruce
Morton via Cscwg-public ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:01000178d2002b3c-ce36f3c2-c273-4e71-8213-e07814efd27b-000000@email.amazonses.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:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</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]-->
<div class="WordSection1">
<p class="MsoNormal">MINUTE TAKER: <b>??</b><o:p></o:p></p>
<ol style="margin-top:0in" type="1" start="1">
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">Roll
Call<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">Antitrust
statement<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">Approval
of prior meeting minutes (8 April 2021)<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">Cross-sign
Roots (Corey)<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">Certificate
Policy OID for Time-stamping (Bruce)<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">Common
Criteria requirement – update required for
CSBRs?<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">CSCWG-6
ballot - status/questions (Ian) <o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">Clean-up
ballot – status (Bruce) – SAN, CRL, FIPS 140-<b>2</b>,
Root/SubCA Key size, Cross-certificate, TS
SHA-1, Interoperability verification<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">Any
other business<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo3">Next
Meeting Apr 22<sup>nd</sup> <o:p></o:p></li>
</ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal"><b>Bruce.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Cscwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cscwg-public@cabforum.org" moz-do-not-send="true">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Cscwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cscwg-public@cabforum.org" moz-do-not-send="true">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Cscwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cscwg-public@cabforum.org" moz-do-not-send="true">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Cscwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cscwg-public@cabforum.org" moz-do-not-send="true">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Cscwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cscwg-public@cabforum.org" moz-do-not-send="true">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Cscwg-public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cscwg-public@cabforum.org" moz-do-not-send="true">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
</blockquote>
</body>
</html>