[Smcwg-public] Certificate Suspension

[Dimitris Zacharopoulos (HARICA)]

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/70bfb0c0/attachment.html>