[Smcwg-public] Certificate Suspension

Stephen Davidson Stephen.Davidson at digicert.com
Fri Aug 26 17:27:28 UTC 2022


While suspension is described in eIDAS, it is only to note that it was a legacy practice of some TSPs in some member states (see below). While a policy carve out may exist for Certificate Issuers, a corresponding implementation in client software, that is consistent across Certificate Consumers, may not.



I do not know how practically an end user can determine eIDAS’ “precise period of time during which the certificate has been suspended” – and thus the end user has no way of determining if the certificate was suspended when the private key was used to sign.



In my view, current use of certificateHold exemplifies the uncertainties and variance of practice that the BR are intended to prevent.



-- https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG

(53) The suspension of qualified certificates is an established operational practice of trust service providers in a number of Member States, which is different from revocation and entails the temporary loss of validity of a certificate. Legal certainty calls for the suspension status of a certificate to always be clearly indicated. To that end, trust service providers should have the responsibility to clearly indicate the status of the certificate and, if suspended, the precise period of time during which the certificate has been suspended. This Regulation should not impose the use of suspension on trust service providers or Member States, but should provide for transparency rules when and where such a practice is available.







From: Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
Sent: Friday, August 26, 2022 3:12 AM
To: Stephen Davidson <Stephen.Davidson at digicert.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org>; Tim Hollebeek <tim.hollebeek at digicert.com>; Doug Beattie <doug.beattie at globalsign.com>
Subject: Re: [Smcwg-public] Certificate Suspension





On 26/8/2022 1:44 π.μ., Stephen Davidson via Smcwg-public wrote:

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


   Then let's fix that :) The revocationReason issue was equally challenging and not well-defined. It took some time until a decent proposal was put on the table that covers most use cases. I'm sure some corner cases will come up that might require an update in the revocationReason language in the Mozilla Root Store Policy but it all starts with documenting some real use cases and creating the proper language to support those use cases in a secure manner.





   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.


   I don't agree with that assumption. As already mentioned, Certificate suspension is described in European and National Law which already affects millions of Relying Parties. If they are not understood, again, that's something we should improve as an ecosystem. RPs didn't understand several TLS errors in the past but this has been improved. Some RPs still don't understand why these errors appear but that doesn't mean revocation should not be used.




   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 think that's the information we are looking for in order to capture existing use cases. eIDAS describes some of those cases too. I'm not sure about the 2nd use case  (“the certificate holder went on leave for a few weeks”) but the 1st and 3rd use cases are real for "signing" certificates and could be supported by the use of certificateHold. I've only seen the 2nd use case apply to clientAuth Certificates. It doesn't make much sense to be used for "signing" certificates because -as others pointed out- the status of the signing certificate must be checked at time of signing of the signed email/document.




   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.


   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.


   Thanks,
   Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220826/bd5ce179/attachment-0001.html>


More information about the Smcwg-public mailing list