[Cscwg-public] CSCWG Agenda Apr 15, 2021

Wed Apr 21 07:34:17 UTC 2021

Hi Dimitris,

to avoid misunderstandings: I am not at all suggesting to impose 
"additional"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.

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.

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 https://www.commoncriteriaportal.org/products/, and for each of 
them there is a link to download the Security Target.

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.

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.

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.

A list of devices already selected according to this criterion can be 
found at 
https://esignature.ec.europa.eu/efda/notification-tool/#/screen/browse/list/QSCD_SSCD, 
. For the reasons above, I would consider all the smartcard-type devices 
listed therein as (potentially) suitable Subscriber devices for Code 
Signing

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.

Let me know if this answers your question.

[1] https://www.oracle.com/java/technologies/javacard-specs-downloads.html

Regards,

Adriano

Il 20/04/2021 13:26, Dimitris Zacharopoulos (HARICA) via Cscwg-public ha 
scritto:
>
> Adriano,
>
> 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.
>
>
> Thank you,
> Dimitris.
>
> On 19/4/2021 4:31 μ.μ., Adriano Santoni via Cscwg-public wrote:
>>
>> All,
>>
>> 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).
>>
>> 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 ...
>>
>> Regards
>>
>> Adriano
>>
>>
>> Il 14/04/2021 22:08, Bruce Morton via Cscwg-public ha scritto:
>>>
>>> MINUTE TAKER: *??*
>>>
>>>  1. Roll Call
>>>  2. Antitrust statement
>>>  3. Approval of prior meeting minutes (8 April 2021)
>>>  4. Cross-sign Roots (Corey)
>>>  5. Certificate Policy OID for Time-stamping (Bruce)
>>>  6. Common Criteria requirement – update required for CSBRs?
>>>  7. CSCWG-6 ballot -  status/questions (Ian)
>>>  8. Clean-up ballot – status (Bruce) – SAN, CRL, FIPS 
140-*2*,
>>>     Root/SubCA Key size, Cross-certificate, TS SHA-1,
>>>     Interoperability verification
>>>  9. Any other business
>>> 10. Next Meeting Apr 22^nd
>>>
>>> **
>>>
>>> *Bruce.*
>>>
>>>
>>> _______________________________________________
>>> Cscwg-public mailing list
>>> Cscwg-public at cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>>
>> _______________________________________________
>> Cscwg-public mailing list
>> Cscwg-public at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>
>
> _______________________________________________
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/cscwg-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210421/ca825c00/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20210421/ca825c00/attachment-0001.p7s>