[Smcwg-public] Certificate Suspension

[Inigo Barreira]

I agree with Tim´s concerns with the signatures and would like to know what consumers think. But the same could happen with any signature performed by any certificate, and for example, for code signing, the solution was to ban the suspension option.

 

But IMO the main issue is that standards allow it somehow. Even though it´s not reflected directly (for example, in OCSP there are only 3 values: good, revoked and unknown. The revoked can have in its revocation reason the certificateHold, that means a temporary suspension, but in any case, the first response you´ll see is “revoked”). This may mean that because it´s in the standards, you have to allow it and it´s no that easy. I also agree with Dimitris to fix it but IMO it´s not feasible and not scalable maybe (what if MS does it and Mozilla does not).

 

Regards

 

De: Smcwg-public <smcwg-public-bounces at cabforum.org> En nombre de Tim Hollebeek via Smcwg-public
Enviado el: viernes, 26 de agosto de 2022 16:26
Para: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; Stephen Davidson <Stephen.Davidson at digicert.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org>; Doug Beattie <doug.beattie at globalsign.com>
Asunto: Re: [Smcwg-public] Certificate Suspension

 

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.

 

I would love to hear from Certificate Consumers whether they are / are not interested in improving suspension in these ways.  If they are, then perhaps this is worth working on.  If they aren’t, then it would likely be a wasted effort.

 

While thinking about this a bit more last night, I realized that the experience is probably even more a nightmare than I had anticipated, as the correct implementation would need to check whether the certificate was suspended at the time the email was signed, not whether the certificate is currently suspended.  I doubt it currently works that way in all current mail clients.  Otherwise you can retroactively invalidate a whole bunch of signatures that happened way before whatever event triggered the need for temporary suspension.  I don’t even want to think about all the games you can play with asking for your certificate to be suspended temporarily whenever you want to manipulate whether your historical signatures validate successfully or not.

 

-Tim

 

The SMCWG is about to create a new Guideline document with some industry-agreed principles and policies. The fact that things are not coordinated today shouldn't prevent us from designing improvements for tomorrow. Perhaps some Certificate Consumers will decide to add the necessary development time and improve the existing implementations based on the SMBRs. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220826/cbf3c2ab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6853 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220826/cbf3c2ab/attachment.p7s>