[Smcwg-public] Certificate Suspension
Tim Hollebeek
tim.hollebeek at digicert.com
Thu Aug 25 18:48:09 UTC 2022
Well, the problem is that no existing mail clients do this, and mail clients probably never will. The example you provide shows just how horrible the user experience for suspension really is. The practical effect is that it causes transient validation errors that users cannot possibly understand, which will inevitably cause users to conclude that validation errors happen randomly and can safely be ignored.
On the other hand, I'm aware that lots of CAs out there currently support suspension, for the reasons Dimitris has mentioned. So, based on the principles we've sort of agreed to, it should at least live on in the legacy profile.
As a general industry trend, I usually see new ecosystems moving away from suspension as allowed, as it is much easier to handle security systems things only ever go from good to bad, and never the reverse. Whether the additional complexity suspension introduces is necessary or good is in my opinion debatable. The biggest factor to me for the S/MIME BRs is whether it is important enough that certificate consumers will commit the resources to make it work reliably and understandably, perhaps by implementing the sorts of improvements Doug suggested.
I generally think it's better that suspension is something that goes away over time, but I won't lose sleep over it if others disagree. As Russ correctly notes, this is probably something we will still be discussing in 2050.
-Tim
From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Doug Beattie via Smcwg-public
Sent: Thursday, August 25, 2022 1:44 PM
To: SMIME Certificate Working Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] Certificate Suspension
Then maybe it could/should work like this?
- Sender sends a signed message
- The Sender's certificate gets suspended
- Recipient tries to verify the signature and is told that the Sender's certificate is SUSPENDED
- The Sender's certificate gets unsuspended
- Recipient tries to verify the signature from a save folder and is told that the signature is fine
-----Original Message-----
From: Smcwg-public <smcwg-public-bounces at cabforum.org<mailto:smcwg-public-bounces at cabforum.org>> On Behalf Of Russ Housley via Smcwg-public
Sent: Thursday, August 25, 2022 1:30 PM
To: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto:dzacharo at harica.gr>>
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>
Subject: Re: [Smcwg-public] Certificate Suspension
Dimitris:
>> I tend to agree with Stephen. I am unaware of any S/MIME client software that would handle a certificate suspension any differently that a revocation.
>
> Which is perfectly fine and expected when a certificate is "suspended" (i.e. not to be trusted at time of verification). If a S/MIME client software wants to provide some kind of different UI message like "this certificate is currently suspended" instead of "the signing certificate is revoked" and explain what that means, IMO that would be an improvement similar to what's happening with the server TLS user agents providing different user experience depending on the revocationReason code.
This is a topic that has been discussed over and over since the mid 1990s. It never gets consensus in either direction. I predict that will be the case here too.
I worry about the following series of events leads to confused user:
- Sender sends a signed message
- The Sender's certificate gets suspended
- Recipient tries to verify the signature and is told that the Sender's certificate is revoked
- The Sender's certificate gets unsuspended
- Recipient tries to verify the signature from a save folder and is told that the signature is fine
A normal human will not understand what happened.
Russ
_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org<mailto: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/20220825/9890a9a1/attachment.html>
More information about the Smcwg-public
mailing list