[Smcwg-public] [External Sender] Re: Re: Re: Allowing a signature made with an S/MIME IV or SV certificate as an additional individual identity validation method
Adriano Santoni
adriano.santoni at staff.aruba.it
Thu May 16 12:24:52 UTC 2024
I am not entirely convinced of the objections that have been raised so
far, however I see that the topic is receiving little interest, so I
will take some time to reflect on it more calmly, and possibly return to
it later on.
Adriano
Il 16/05/2024 14:12, Dimitris Zacharopoulos (HARICA) via Smcwg-public ha
scritto:
> NOTICE: Pay attention - external email - Sender is
> 0100018f81516e02-6e8cf1f2-17e3-4e41-a6e4-9bba971c2720-000000 at amazonses.com
>
>
>
>
>
>
> On 16/5/2024 3:06 μ.μ., Adriano Santoni via Smcwg-public wrote:
>>
>> At any rate, even with a digital signature made with an eIDAS
>> qualified certificate, you (the CA) cannot tell - in general -
>> whether the certificate was issued after identifying the Applicant
>> with the method described in eIDAS Article 24-1a, rather than 24-1b,
>> or 24-1c, or 24-1d. So it is quite possible that a certain an eIDAS
>> qualified certificate, taken at random, was issued with any of those
>> 4 methods as regards the individual identity vetting, AFAIK.
>>
>
> There has been a lot of debate on this issue, in ETSI ESI, FESA and
> ECATS. The general expectation is that if a TSP is not certain how the
> relied-upon certificate has been originally issued, to confirm that it
> was issued according to 24-1a or 24-1b, it should not accept it for
> 24-1c. Different interpretations may exist but IMO the Regulation is
> clear on this issue.
>
> Obviously the TSP knows how its own certificates have been issued and
> can easily apply 24-1c.
>
>
> Dimitris.
>
>
>
>> Adriano
>>
>>
>> Il 16/05/2024 13:49, Dimitris Zacharopoulos (HARICA) ha scritto:
>>> NOTICE: Pay attention - external email - Sender is dzacharo at harica.gr
>>>
>>>
>>>
>>>
>>>
>>> On 13/5/2024 5:03 μ.μ., Adriano Santoni via Smcwg-public wrote:
>>>>
>>>> Hi Martijn,
>>>>
>>>> I appreciate your concern, but would not the same concern also
>>>> arise with a digital signature made with an eIDAS qualified
>>>> certificate?
>>>>
>>>
>>> Hi Adriano, I missed this thread, apologies my earlier post didn't
>>> take this thread into account,
>>>
>>> If you are referring to eIDAS1 Art. 24-1c this renewal is allowed
>>> only if the relied-upon certificate was issued under Art. 24-1a or
>>> 24-1b. It cannot be used when a request is signed with a Qualified
>>> Certificate issued under Art. 24-1c otherwise we would fall into the
>>> situation that Martijn described.
>>>
>>>
>>> Dimitris.
>>>
>>>> Anyway, it could be addressed by setting a time limit after which
>>>> re-validation by other means (to be specified) must be done, as you
>>>> suggest.
>>>>
>>>> Regards
>>>>
>>>> Adriano
>>>>
>>>>
>>>> Il 13/05/2024 15:53, Martijn Katerbarg ha scritto:
>>>>>
>>>>> Hi Adriano,
>>>>>
>>>>> My immediate concern would be the scenario where say in 2024
>>>>> someone gets an S/MIME IV certificate issued based on current
>>>>> validation practices. Then in 2 years time, they renew based on
>>>>> their existing S/MIME certificate. Then in another two years,
>>>>> again, and yet again. Soon, we’ll be 10 years since the original
>>>>> validation took place, and ever since then the CA has relied upon
>>>>> an existing S/MIME certificate (or CA’s, if the Subscriber is
>>>>> switching to a different vendor) without any additional verification.
>>>>>
>>>>> Additionally, currently there’s no requirement to indicate in an
>>>>> SV certificate if an Enterprise RA was used or not.
>>>>>
>>>>> The second item could be solved by adding an indicator for that
>>>>> into the certificate (See
>>>>> https://github.com/cabforum/smime/issues/12), but I’m not sure how
>>>>> we’d solve the second one, and I’d be very hesitant on supporting
>>>>> something like that, without a proper time limit in place at which
>>>>> point re-validation would need to occur.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Martijn
>>>>>
>>>>> *From:* Smcwg-public <smcwg-public-bounces at cabforum.org> on behalf
>>>>> of Adriano Santoni via Smcwg-public <smcwg-public at cabforum.org>
>>>>> *Date:* Monday, 13 May 2024 at 15:32
>>>>> *To:* SMIME Certificate Working Group <smcwg-public at cabforum.org>
>>>>> *Subject:* [Smcwg-public] Allowing a signature made with an S/MIME
>>>>> IV or SV certificate as an additional individual identity
>>>>> validation method
>>>>>
>>>>> CAUTION: This email originated from outside of the organization.
>>>>> Do not click links or open attachments unless you recognize the
>>>>> sender and know the content is safe.
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I already made the following proposal previously, both in writing
>>>>> here on the mailing list and also verbally during the last call
>>>>> (at the very last minutes as it was not on the agenda, sorry), but
>>>>> I don't see it mentioned in the call minutes of May 8 below, so
>>>>> I'll try to propose it again.
>>>>>
>>>>> Among the methods for the "Validation of individual identity"
>>>>> (SMBR 3.2.4.2), as part of the validation process of a request for
>>>>> an S/MIME IV certificate (or an SV certificate, where there is no
>>>>> Enterprise RA involved), I think it would make sense to admit - in
>>>>> addition to a digital signature based on an eIDAS compliant
>>>>> qualified certificate - also a digital signature based on another
>>>>> S/MIME IV or SV (BR-compliant) certificate of the applicant. This
>>>>> seems quite logical to me considering the rigor inherent in the
>>>>> validation requirements already established by the S/MIME BR to date.
>>>>>
>>>>> At least in the case of /renewal/, I think it would be completely
>>>>> logical and safe to accept a request signed by the applicant with
>>>>> his/her current S/MIME IV or SV certificate (the one soon to
>>>>> expire) without the need to perform a further "verification of
>>>>> individual identity" with other methods.
>>>>>
>>>>> If this idea for some reason doesn't seem practical or useful or
>>>>> safe enough, I'd like someone to explain their objections or concerns.
>>>>>
>>>>> Thank you all for your attention.
>>>>>
>>>>> Adriano
>>>>>
>>>>> Il 11/05/2024 22:02, Stephen Davidson via Smcwg-management ha scritto:
>>>>>
>>>>> NOTICE: Pay attention - external email - Sender is
>>>>> 0100018f693fd56b-e31b4721-c8ba-4ae7-a5bb-de9b42be70ce-000000 at amazonses.com
>>>>>
>>>>>
>>>>> ## Minutes of SMCWG
>>>>>
>>>>> May 8, 2024
>>>>>
>>>>> These are the Draft Minutes of the meeting described in the
>>>>> subject of this message. Corrections and clarifications where
>>>>> needed are encouraged by reply.
>>>>>
>>>>> ## Attendees
>>>>>
>>>>> Abhishek Bhat - (eMudhra), Adriano Santoni - (Actalis S.p.A.),
>>>>> Aggie Wang - (TrustAsia), Andrea Holland - (VikingCloud),
>>>>> Ashish Dhiman - (GlobalSign), Ben Wilson - (Mozilla), Bruce
>>>>> Morton - (Entrust), Clint Wilson - (Apple), Corey Bonnell -
>>>>> (DigiCert), Dimitris Zacharopoulos - (HARICA), Inaba Atsushi -
>>>>> (GlobalSign), Inigo Barreira - (Sectigo), Janet Hines -
>>>>> (VikingCloud), Judith Spencer - (CertiPath), Keshava Nagaraju
>>>>> - (eMudhra), Marco Schambach - (IdenTrust), Martijn Katerbarg
>>>>> - (Sectigo), Morad Abou Nasser - (TeleTrust), Mrugesh
>>>>> Chandarana - (IdenTrust), Nome Huang - (TrustAsia), Rebecca
>>>>> Kelly - (SSL.com), Renne Rodriguez - (Apple), Rollin Yu -
>>>>> (TrustAsia), Scott Rea - (eMudhra), Stefan Selbitschka -
>>>>> (rundQuadrat), Stephen Davidson - (DigiCert), Tadahiko Ito -
>>>>> (SECOM Trust Systems), Tathan Thacker - (IdenTrust), Tsung-Min
>>>>> Kuo - (Chunghwa Telecom), Wendy Brown - (US Federal PKI
>>>>> Management Authority)
>>>>>
>>>>> ## 1. Roll Call
>>>>>
>>>>> The Roll Call was taken.
>>>>>
>>>>> ## 2. Read Antitrust Statement
>>>>>
>>>>> The statement was read concerning the antitrust policy, code
>>>>> of conduct, and intellectual property rights agreement.
>>>>>
>>>>> ## 3. Review Agenda
>>>>>
>>>>> Minutes were prepared by Stephen Davidson.
>>>>>
>>>>> ## 4. Approval of minutes from last teleconference
>>>>>
>>>>> The minutes for the teleconference of April 24 were approved.
>>>>>
>>>>> ## 5. Discussion
>>>>>
>>>>> Stephen Davidson noted that Ballot SMC06 was in IPR until May
>>>>> 11. See
>>>>> https://lists.cabforum.org/pipermail/smcwg-public/2024-April/000957.html
>>>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fsmcwg-public%2F2024-April%2F000957.html&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C708f7bd916fb456126ba08dc73512026%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512039511762331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=BHKcC9wi8xSZNIvCbF96gxjYbCI1d3s1SwRCdNpXMQw%3D&reserved=0>.
>>>>>
>>>>> The WG discussed and approved the change of KeyFactor from an
>>>>> Interested Party to an Associate Member, Ellie Schieder as an
>>>>> Interested Party, and Posteo e.K as a Certificate Consumer.
>>>>>
>>>>> The WG reviewed and discussed a ballot proposed by Martijn
>>>>> Katerbarg which would bring the S/MIME BR up to date with a
>>>>> recent ballot at the TLS BR for logging. See more at
>>>>> https://github.com/cabforum/smime/issues/241
>>>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fsmime%2Fissues%2F241&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C708f7bd916fb456126ba08dc73512026%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512039511777400%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zsu0bwRhIDoxPPlahVUlbI%2B%2FU7VdcyIjSfYHixo1JAk%3D&reserved=0>
>>>>>
>>>>>
>>>>> The WG had an extensive discussion regarding the migration to
>>>>> Multipurpose/Strict profiles. Stephen noted that so far only
>>>>> two points had been raised by Certificate Issuers:
>>>>>
>>>>> * Having adequate time (such as one year) to allow ERAs
>>>>> using integration time to adapt.
>>>>> * Concerns relating to the impact of shorter validity on
>>>>> deployments using tokens/smartcards.
>>>>>
>>>>> Judith Spencer and Wendy Brown commented that the shorter
>>>>> validity had real impact on large (including public sector)
>>>>> deployments that use tokens/smartcards, including:
>>>>>
>>>>> * limited storage on tokens/smartcards;
>>>>> * the increased burden of key exchange; and
>>>>> * and the costs of support for rekeying.
>>>>>
>>>>> The question was raised whether it would be feasible to
>>>>> increase the validity for the Multipurpose profile to 1185
>>>>> days in general, or in cases where tokens/smartcards are
>>>>> used. Clint Wilson spoke about the security and crypto
>>>>> agility benefits of shorter validity periods. It was agreed
>>>>> this topic would be continued in Bergamo.
>>>>>
>>>>> ## 6. Any Other Business
>>>>>
>>>>> None.
>>>>>
>>>>> ## 7. Next call
>>>>>
>>>>> Next call: the teleconference scheduled for May 22 has been
>>>>> cancelled. Next meeting is Bergamo F2F.
>>>>>
>>>>> ## Adjourned
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Smcwg-management mailing list
>>>>>
>>>>> Smcwg-management at cabforum.org
>>>>>
>>>>> https://lists.cabforum.org/mailman/listinfo/smcwg-management <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fsmcwg-management&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7C708f7bd916fb456126ba08dc73512026%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638512039511787973%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=jyn4cbSuAbphPNeqicGutRFnz8pdQU98ccl8W0GxW8Q%3D&reserved=0>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20240516/851a1d47/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4620 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20240516/851a1d47/attachment-0001.p7s>
More information about the Smcwg-public
mailing list