[Smcwg-public] [EXTERNAL]-Re: Certificate Suspension

Wed Aug 24 21:08:32 UTC 2022

Hello,
In principle I’m against disallowing suspension, because it brings lots of benefits (i.e. suspend a corporate MPKI customer that is not paying, to name an advantage) but I’d have a comment and a question.

My comment… In terms of digital signature, the verification must include to check “if the signing certificate was valid at the moment of the signature”. The same can be considered for signing a document… a digital signature made with a certificate is always valid if the certificate was not revoked and not expired at the moment of the signature, independently if it was later revoked or it expired.

My question.. “What are really doing the certificate consumers?”. Because I’m afraid that the revocation checking for email could be maybe too simplistic and only looking at the immediate status when checking the signature, without  considering the status at the time of the signature creation (i.e. the time the mail was sent).

If I’m wrong and the certificate consumers are actually checking “correctly” the signatures, then there’s no problem with suspension, but if the checking is too basic and not considering the time of signature, then I see a potential problem, because the signature made with a certificate either revoked or suspended, can’t never be considered valid.

Maybe the certificate consumers should explain how they consider the time of creation of the signature when checking revocation, so we can take a proper decision.

To be clear… I never agreed personally with the disallowance of suspension in SSL, because in that case the revocation checking doesn’t need to consider the “signature time”. For S/MIME in general I’m also against disallowing suspension, but we should ensure things are done properly when verifying the signatures.

My two cents…
Pedro

On 24 Aug 2022, at 22:43, Dimitris Zacharopoulos (HARICA) via Smcwg-public <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>> wrote:

Hi Stephen,

On 24/8/2022 10:00 μ.μ., Stephen Davidson via Smcwg-public wrote:
Hi Ben:

Thanks for the comment.

I believe that support for suspension is not appropriate for the publicly-trusted S/MIME for the following reasons:

  *   For S/MIME recipients this could be confusing, for example in the case that a signature on an email could be valid or not on different days, with no explanation. The CABF stance for publicly-trusted certificates has been that once a certificate is "bad" on a CRL it can't be "unbad".

I understand the confusion between different CABF WGs but the SCWG places requirements for TLS Certificates used for server authentication and the SMCWG is about Certificates used for signing S/MIME messages. A signing Certificate that was used to sign a message may be checked/verified more than once at different times.

A signing certificate may become suspended during an investigation by the CA after some third-party report. That means that the signer should refrain from signing until this investigation is concluded. If the signer continues to sign messages during this "suspension" period, the signatures should not be verified as valid.

If the conclusion of the investigation is that the certificate needs to be permanently revoked, then the signatures created using that key and certificate will be permanently invalid from the time the certificate became suspended. If the result is the opposite, then the certificate is reinstated (entry is removed from the CRL) and all signatures will be valid, even during the time of "suspension".

The suspension period is usually reasonably small to minimize this window of "I check something now and it is invalid, but X days later it is valid".

  *
  *   For Certificate Issuers, this could also create undesired inconsistency in revocation handling across publicly-trusted certificate types, particularly in light of the changes implemented recently to create CRL consistency under the Mozilla policy for TLS.

I'm not sure why you are bringing in the server TLS policy. This is the S/MIME WG and we should focus on rules that reasonably apply to S/MIME Certificates. If a CA wants to issue different types of certificates (TLS, Code Signing, S/MIME), they need to follow different rules and policies. CAs can certainly follow different policies for different certificate types as we've seen in the past, or use the strictest rules among various policies and apply for all types. For example, there are currently no global rules for performing identity validation for S/MIME Certificates and there are plenty CAs are not using the documented identity validation policies described in the the TLS or CodeSigning BRs to validate identity in S/MIME Certificates.

The revocation handling discussion and decision by Mozilla was focused on TLS Certificates, not S/MIME. The S/MIME use cases were not considered in the discussion.

  *
  *   For Certificate Consumers, we have no known “default” for how revocation checking is performed in client software, or how the certificateHold revocation code is treated.

Isn't this already described in RFC 5280? If an implementation decides not to follow the RFC and considers a signing certificate as "valid" despite being listed in a CRL with revocationReason "certificateHold", then IMHO it's a problematic implementation.

I recall the WG did review this draft section about a year ago, but as there was no comment (often the case with ‘pick ups’ from other CABF standards) the topic is not specifically acknowledged in the minutes.

It's quite possible that other topics have not been reviewed in depth because, realistically, there are too many topics to cover :-) I'm glad that Ben brought this up and gave the opportunity for other members to take a closer look.

FWIW, certificate suspension is a challenging topic but not an option we should disallow from the very beginning. The WG has agreed to be more inclusive and cover use cases that are currently in existence. Certificate suspension is one of those cases.

Thanks,
Dimitris.

Best, Stephen

From: Smcwg-public <smcwg-public-bounces at cabforum.org><mailto:smcwg-public-bounces at cabforum.org> On Behalf Of Ben Wilson via Smcwg-public
Sent: Wednesday, August 17, 2022 2:44 PM
To: SMIME Certificate Working Group <smcwg-public at cabforum.org><mailto:smcwg-public at cabforum.org>
Subject: [Smcwg-public] Certificate Suspension

Question - did we previously discuss and decide on "Certificate Suspension"?

The draft I'm looking at says, "### 4.9.13 Circumstances for suspension
The Repository SHALL NOT include entries that indicate that a Certificate is suspended."

Don't some legacy implementations allow suspension?

Thanks,

Ben

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org<mailto:Smcwg-public at cabforum.org>
https://lists.cabforum.org/mailman/listinfo/smcwg-public<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwMDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=G511WYM6qJcrVrdeVVJsESdL-phvJNmoC_4Ba1kvsJQ&s=gPCnxQiq2OcvJ043KE5Ew-ubjxhhOhHk7lwQedIcgps&e=>

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org<mailto:Smcwg-public at cabforum.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=G511WYM6qJcrVrdeVVJsESdL-phvJNmoC_4Ba1kvsJQ&s=gPCnxQiq2OcvJ043KE5Ew-ubjxhhOhHk7lwQedIcgps&e=

WISeKey SA
Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790
Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
Stay connected with WISeKey<http://www.wisekey.com>

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

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