<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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">Cscwg-public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/cscwg-public">https://lists.cabforum.org/mailman/listinfo/cscwg-public</a>
</pre>
</blockquote>
<br>
</body>
</html>