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 <[email protected]> on behalf of
Adriano Santoni via Smcwg-public <[email protected]>
*Date: *Monday, 13 May 2024 at 15:32
*To: *SMIME Certificate Working Group <[email protected]>
*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-000...@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
[email protected]
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>
