<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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/">https://cabforum.org/guidance-ip-addresses-certificates/</a> or
<a class="moz-txt-link-freetext" href="https://cabforum.org/internal-names/">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">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>