[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
Adriano Santoni
adriano.santoni at staff.aruba.it
Thu May 16 12:06:18 UTC 2024
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.
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20240516/4683db64/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/4683db64/attachment-0001.p7s>
More information about the Smcwg-public
mailing list