[Smcwg-public] Certificate Suspension

Wed Aug 24 20:43:19 UTC 2022

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> *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>
> *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
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220824/17995591/attachment-0001.html>