<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><font size="2" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Hi,</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Apple does not support allowing Certificate Suspension for S/MIME certificates in the current draft S/MIME Baseline Requirements.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">As to some of the concrete concerns and opinions I have with Certificate Suspension:</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""></font><ol style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><li class=""><font size="2" class="">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.”</font></li><li class=""><font size="2" class="">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.</font></li><li class=""><font size="2" class="">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.</font></li><li class=""><font size="2" class="">Certificate Suspension brings no value to the ecosystem of general email users and email agents <i class="">as currently specified</i> 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.</font></li></ol><font size="2" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">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 </span><i style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">after </i><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">we have the SBRs published. Ultimately that’s for the group as a whole to decide.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Thanks!</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">-Clint</span></font><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 26, 2022, at 10:27 AM, Stephen Davidson via Smcwg-public <<a href="mailto:smcwg-public@cabforum.org" class="">smcwg-public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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.<span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">In my view, current use of certificateHold exemplifies the uncertainties and variance of practice that the BR are intended to prevent.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">--<span class="Apple-converted-space"> </span><a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG" style="color: rgb(5, 99, 193); text-decoration: underline;" class="">https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG</a><o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">(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.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0in 0in;" class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class="">From:</b><span class="Apple-converted-space"> </span>Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr" style="color: rgb(5, 99, 193); text-decoration: underline;" class="">dzacharo@harica.gr</a>><span class="Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Friday, August 26, 2022 3:12 AM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Stephen Davidson <<a href="mailto:Stephen.Davidson@digicert.com" style="color: rgb(5, 99, 193); text-decoration: underline;" class="">Stephen.Davidson@digicert.com</a>>; SMIME Certificate Working Group <<a href="mailto:smcwg-public@cabforum.org" style="color: rgb(5, 99, 193); text-decoration: underline;" class="">smcwg-public@cabforum.org</a>>; Tim Hollebeek <<a href="mailto:tim.hollebeek@digicert.com" style="color: rgb(5, 99, 193); text-decoration: underline;" class="">tim.hollebeek@digicert.com</a>>; Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" style="color: rgb(5, 99, 193); text-decoration: underline;" class="">doug.beattie@globalsign.com</a>><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [Smcwg-public] Certificate Suspension<o:p class=""></o:p></div></div></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p><div class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">On 26/8/2022 1:44 π.μ., Stephen Davidson via Smcwg-public wrote:<o:p class=""></o:p></div></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Suspension is not a well-defined practice (particularly compared to the recently-defined uses of the other CRL codes in the Mozilla policy). <o:p class=""></o:p></div></blockquote><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><br class="">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.<br class=""><br class=""><br class=""><o:p class=""></o:p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><br class="">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.<o:p class=""></o:p></div></blockquote><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><br class="">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.<br class=""><br class=""><br class=""><o:p class=""></o:p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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”.<o:p class=""></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div></blockquote><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><br class="">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.<br class=""><br class=""><br class=""><o:p class=""></o:p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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.<o:p class=""></o:p></div></blockquote><div style="margin: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><br class="">The SMCWG is about to create a new Guideline document with some industry-agreed principles and policies. The fact that things are not coordinated<span class="Apple-converted-space"> </span><i class="">today<span class="Apple-converted-space"> </span></i>shouldn't prevent us from designing improvements for<span class="Apple-converted-space"> </span><i class="">tomorrow</i>. Perhaps some Certificate Consumers will decide to add the necessary development time and improve the existing implementations based on the SMBRs.<span class="Apple-converted-space"> </span><br class=""><br class=""><br class="">Thanks,<br class="">Dimitris.<o:p class=""></o:p></div></div><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Smcwg-public mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="mailto:Smcwg-public@cabforum.org" style="color: rgb(5, 99, 193); text-decoration: underline; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Smcwg-public@cabforum.org</a><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" style="color: rgb(5, 99, 193); text-decoration: underline; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a></div></blockquote></div><br class=""></body></html>