[Smcwg-public] Certificate Suspension

Thu Aug 25 22:44:36 UTC 2022

Suspension is not a well-defined practice (particularly compared to the
recently-defined uses of the other CRL codes in the Mozilla policy).  

As best I can tell the most common uses of suspension are in
enterprise/internal scenarios where the suspension practices are understood
. versus "inter-public" where they are not.  For example, the use of
certificateHold "for the period between the certificate being issued and
being picked up" is very different from "the certificate holder went on
leave for a few weeks" or "the CA is looking into a problem report about
this cert".

I can see the utility of suspension for certs whose use is "live", such as
authentication, to pause the use of the credential.  But for certs whose
activity creates an artifact with a life of its own (such as a signed
email), it really becomes problematic, particularly if client side handling
is not coordinated amongst Certificate Consumers.

Best, Stephen

From: Smcwg-public <smcwg-public-bounces at cabforum.org> On Behalf Of Tim
Hollebeek via Smcwg-public
Sent: Thursday, August 25, 2022 3:48 PM
To: Doug Beattie <doug.beattie at globalsign.com>; SMIME Certificate Working
Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] Certificate Suspension

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
<mailto: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
<mailto: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/ac02f074/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4999 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220825/ac02f074/attachment-0001.p7s>