[Smcwg-public] [External Sender] Re: Re: Allowing a signature made with an S/MIME IV or SV certificate as an additional individual identity validation method
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu May 16 12:12:11 UTC 2024
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20240516/37d82810/attachment-0001.html>
More information about the Smcwg-public
mailing list