[Smcwg-public] [External Sender] Re: Draft proposal to add eIDAS QES as vetting evidence for individual

Tue Apr 30 06:42:14 UTC 2024

Adriano,

eIDAS2 goes into effect May 20, 2024 and updates specific articles of 
eIDAS1. The proposed changes to the SMBRs don't include specific eIDAS 
articles.

If you are concerned with the justification part of the ballot, we could 
simply state "as amended by Regulation (EU) 2024/1183" which covers all 
changes.

I don't have a "codified" version of the eIDAS2 Regulation (that is the 
final text of eIDAS1 including the changes from eIDAS2). If you have 
such a version, it would help Stephen do a cross-check for any deleted 
articles.

Thanks,
Dimitris.

On 30/4/2024 9:27 π.μ., Adriano Santoni via Smcwg-public wrote:
>
> I agree with Dimitris' suggestions, as far as the eIDAS framework is 
> concerned.
>
> In the meantime, let's note that today eIDAS2 was published in the EU 
> Official Journal as Regulation (EU) 2024/1183 amending the old eIDAS 
> (Regulation (EU) No 910/2014), and some of the original articles have 
> been deleted, so if we intend to insert references to some of the 
> Regulation's articles in the SMBR we should take care to mention the 
> right ones :)
>
> Adriano
>
>
> Il 29/04/2024 18:55, Dimitris Zacharopoulos (HARICA) via Smcwg-public 
> ha scritto:
>> NOTICE: Pay attention - external email - Sender is 
>> 0100018f2ac82989-d0dc56df-6b57-42ca-ade1-b29c429c2344-000000 at amazonses.com 
>>
>>
>>
>>
>> Hi Stephen,
>>
>> After some internal review and based on the fact that eIDAS supports 
>> identity proofing for natural persons AND legal entities, I have some 
>> suggestions.
>>
>> In 3.2.4.1 (4) which is related to "Attribute collection of 
>> individual identity":
>>
>> From:
>>
>> /eIDAS Qualified: The CA MAY rely upon a signature created using a 
>> Qualified Electronic Signature Certificate issued by a trust service 
>> holding the "http://uri.etsi.org/TrstSvc/Svctype/CA/QC" service type 
>> and the "http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/granted" 
>> status on an EU Trusted List. The "GRANTED" status must be effective 
>> at the time of signing (if the signature is associated with a 
>> Qualified time stamp) or at the time of validation (if the signature 
>> is not associated with a Qualified time stamp). The signature 
>> certificate SHALL include the |esi4-qcStatement-6| Qcstatement as 
>> specified in clause 4.2.1 of ETSI EN 319 412-5 incorporating the 
>> |id-etsi-qct-esign| QcType as specified in clause 4.2.3 of ETSI EN 
>> 319 412-5./
>>
>> To:
>>
>> /eIDAS Qualified: The CA MAY rely upon a *digital* signature created 
>> using a *Qualified Certificate for Electronic Signatures* issued by a 
>> trust service *provider* holding the 
>> "http://uri.etsi.org/TrstSvc/Svctype/CA/QC" service type/ /*with 
>> extension 
>> "http://uri.etsi.org/TrstSvc/TrustedList/SvcInfoExt/ForeSignatures",*/ 
>> /and the "http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/granted" 
>> status on an EU Trusted List. The "GRANTED" status must be effective 
>> at the time of signing (if the signature is associated with a 
>> Qualified time stamp) or at the time of validation (if the signature 
>> is not associated with a Qualified time stamp). The signature 
>> certificate SHALL include the |esi4-qcStatement-6| Qcstatement as 
>> specified in clause 4.2.1 of ETSI EN 319 412-5 incorporating the 
>> |id-etsi-qct-esign| QcType as specified in clause 4.2.3 of ETSI EN 
>> 319 412-5./
>>
>> Do we need similar language added in 3.2.4.2 (4) (Validation of 
>> individual identity) or should we refer to 3.2.4.1 (4) as sufficient 
>> to perform the identity validation besides the attribute collection?
>>
>> Similarly, section 3.2.3 (Authentication of organization identity) 
>> could make use of Qualified Certificates for Electronic Seals for 
>> acquiring attributes of organization identity (3.2.3.1), which could 
>> satisfy the organization identity validation (3.2.3.2) as well.
>>
>> The eSeal language would look like the following:
>>
>> /eIDAS Qualified: The CA MAY rely upon a digital signature created 
>> using a Qualified Certificate for Electronic Seals issued by a trust 
>> service provider holding the 
>> "http://uri.etsi.org/TrstSvc/Svctype/CA/QC" service type with 
>> extension 
>> "http://uri.etsi.org/TrstSvc/TrustedList/SvcInfoExt/ForeSeals", and 
>> the "http://uri.etsi.org/TrstSvc/TrustedList/Svcstatus/granted" 
>> status on an EU Trusted List. The "GRANTED" status must be effective 
>> at the time of signing (if the signature is associated with a 
>> Qualified time stamp) or at the time of validation (if the signature 
>> is not associated with a Qualified time stamp). The signature 
>> certificate SHALL include the |esi4-qcStatement-6| Qcstatement as 
>> specified in clause 4.2.1 of ETSI EN 319 412-5 incorporating the 
>> |id-etsi-qct-eseal| QcType as specified in clause 4.2.3 of ETSI EN 
>> 319 412-5./
>>
>>
>> Thoughts?
>> Dimitris.
>>
>> On 25/4/2024 3:06 π.μ., Stephen Davidson via Smcwg-public wrote:
>>>
>>> Hello all:
>>>
>>> As discussed today, here is draft language for consideration to 
>>> allow CAs to rely upon signatures created with eIDAS Qualified 
>>> certificates as evidence supporting validation of individual identity.
>>>
>>> https://github.com/srdavidson/QES-SMIME-BR/blob/master/QES-proposal.md
>>>
>>> I’d be grateful for feedback on this language.
>>>
>>> Best, Stephen
>>>
>>>
>>> _______________________________________________
>>> Smcwg-public mailing list
>>> Smcwg-public at cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>>
>>
>> _______________________________________________
>> Smcwg-public mailing list
>> Smcwg-public at cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/smcwg-public
>
> _______________________________________________
> Smcwg-public mailing list
> Smcwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20240430/20c57cac/attachment-0001.html>