<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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">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">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">https://www.sogis.eu/documents/cc/pp/sc/sscd/obsolete/pp0059a.pdf</a>)<br>
</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>
<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">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">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>
<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">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>
</body>
</html>