<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 26/8/2022 1:44 π.μ., Stephen
Davidson via Smcwg-public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01000182d72df315-30e79113-8dcb-4ec9-ae5f-a2d6897d5e07-000000@email.amazonses.com">
<p class="MsoNormal">Suspension is not a well-defined practice
(particularly compared to the recently-defined uses of the other
CRL codes in the Mozilla policy). </p>
</blockquote>
<br>
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>
<br>
<blockquote type="cite"
cite="mid:01000182d72df315-30e79113-8dcb-4ec9-ae5f-a2d6897d5e07-000000@email.amazonses.com">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><br>
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. <br>
</p>
</blockquote>
<br>
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>
<br>
<blockquote type="cite"
cite="mid:01000182d72df315-30e79113-8dcb-4ec9-ae5f-a2d6897d5e07-000000@email.amazonses.com">
<p class="MsoNormal"> 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></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</blockquote>
<br>
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>
<br>
<blockquote type="cite"
cite="mid:01000182d72df315-30e79113-8dcb-4ec9-ae5f-a2d6897d5e07-000000@email.amazonses.com">
<p class="MsoNormal">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.</p>
</blockquote>
<br>
The SMCWG is about to create a new Guideline document with some
industry-agreed principles and policies. The fact that things are
not coordinated <i>today </i>shouldn't prevent us from designing
improvements for <i>tomorrow</i>. Perhaps some Certificate
Consumers will decide to add the necessary development time and
improve the existing implementations based on the SMBRs. <br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
</body>
</html>