[Smcwg-public] [External Sender] Re: Allowing a signature made with an S/MIME IV or SV certificate as an additional individual identity validation method

Mon May 13 14:03:31 UTC 2024

Hi Martijn,

I appreciate your concern, but would not the same concern also arise 
with a digital signature made with an eIDAS qualified certificate?

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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20240513/89463b46/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/20240513/89463b46/attachment-0001.p7s>