[Cscwg-public] CSCWG Agenda Apr 15, 2021

Wed Apr 21 08:30:50 UTC 2021

Hi Adriano,

See answers inline.

On 21/4/2021 10:34 π.μ., Adriano Santoni via Cscwg-public wrote:
>
> 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.
>

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.

Does that make sense?

> 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.
>

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.

> 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.
>

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 *more specific* requirements of 
the security target. Perhaps the WG could write an article like 
https://cabforum.org/guidance-ip-addresses-certificates/ or 
https://cabforum.org/internal-names/ about how a CA or an auditor can 
find the proper evidence to support the specific requirements of the 
newly proposed section 16.3.

> 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.
>

Is there some document/rule that SSCD/QSCD devices must meet the three 
security features you 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
>

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.

I would rule out SSCDs as they are no longer considered as secure as the 
QSCDs. Most of them have expired certifications.

> 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.
>

I agree.

> Let me know if this answers your question.
>

This is an interesting discussion and I think we can make some good 
progress and improve this section.

Dimitris.

> [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
>
> _______________________________________________
> 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/267c5ecd/attachment.html>