[Smcwg-public] Certificate Suspension

Fri Aug 26 20:37:19 UTC 2022

Hi,

Apple does not support allowing Certificate Suspension for S/MIME certificates in the current draft S/MIME Baseline Requirements.

I don’t personally find some of the discussion here to be productive. While hypothesizing solutions can be a lot of fun and sometimes hits on productive contributions, I don’t think we’ve come anywhere close to a consensus on what the problems are for which any solutions should be discussed. That seems relatively fundamental to the work of identifying proposals for changes. Similarly, it’s likely that only a subset of those problems is even in the scope of this WG or the Forum at large to solve.
As a very quick example, which hopefully illustrates why I think some of the current lines of discussion are not productive, an email client is best served treating content originating with the message as attacker-controlled; that is, things like the signing time cannot simply be “trusted”. Ofc “moar technology”, like timestamping, could help here, but that adds further complexity in practice and implementation, for both recipient and sender. Privacy trade-offs and operational complexity (e.g. distrusting TSAs) would also need much more discussion to explore.

As to some of the concrete concerns and opinions I have with Certificate Suspension:
Certificate Suspension introduces a number of perverse incentives which should be avoided. Specifically, using any form of revocation as a first-line action against a customer that is not fulfilling financial obligations is in no way desirable. While revocation may be the end result of such a conflict, I am very opposed to this practice as a lever to be used so freely as Certificate Suspension would undoubtedly enable. To be very clear, this behavior is the type of thing I had in mind when publishing “Apple accepts and removes root certificates as it deems appropriate at its sole discretion.”
Certificate Suspension introduces complexity in how revocation information is consumed by end users. A single user reading an email on multiple devices, at even slightly different times, might see different results based on a number of factors (such as cached and unexpired CRLs/OCSP responses, local connectivity to obtain fresh data, and any out-of-band revocation information communicated by a vendor.) Attempting to provide a consistent, cross-device experience almost certainly involves some tradeoff of privacy (to fetch fresh results as the message is validated) and user data/bandwidth.
Certificate Suspension gives a great degree of flexibility to CAs in a potentially security-relevant area, and this creates more opportunities for non-compliance — opportunities which, I think we all agree, we want to limit where possible. Unsuspending a certificate requires its removal from the CRL during its unexpired lifetime, an action which if performed on the wrong entry/certificate would cause an incident, requiring further monitoring and additional levels of technical scrutiny by auditors.
Certificate Suspension brings no value to the ecosystem of general email users and email agents as currently specified and implemented. Similarly, current support and use of suspension is not a compelling argument for its value. Alongside the above concerns, it seems clear to me that the benefits of allowing Certificate Suspension in no way offset the associated risks at this time and without substantial additional investment of Forum time and resources.
A bunch of great points have been made already, and of course none of the problems with allowing Certificate Suspension is insurmountable. If the WG wants to take on the work necessary to address those issues which are part of the scope of this WG, I am supportive of that. Personally I don’t think that work is worthwhile, but would minimally prefer that work to be taken up after we have the SBRs published. Ultimately that’s for the group as a whole to decide.

Thanks!
-Clint

> On Aug 26, 2022, at 10:27 AM, Stephen Davidson via Smcwg-public <smcwg-public at cabforum.org> wrote:
> 
> 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 <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 <mailto:dzacharo at harica.gr>> 
> Sent: Friday, August 26, 2022 3:12 AM
> To: Stephen Davidson <Stephen.Davidson at digicert.com <mailto:Stephen.Davidson at digicert.com>>; SMIME Certificate Working Group <smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org>>; Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com>>; Doug Beattie <doug.beattie at globalsign.com <mailto: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.
> _______________________________________________
> Smcwg-public mailing list
> Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org>
> https://lists.cabforum.org/mailman/listinfo/smcwg-public <https://lists.cabforum.org/mailman/listinfo/smcwg-public>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220826/bfff34bf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3621 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220826/bfff34bf/attachment-0001.p7s>