[Smcwg-public] [External Sender] 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 11:49:09 UTC 2024
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20240516/bb5f3b81/attachment-0001.html>
More information about the Smcwg-public
mailing list