[Servercert-wg] Concrete revocation reason proposal based on Ben Wilson's F2F presentation
Aaron Gable
aaron at letsencrypt.org
Wed Oct 9 16:06:04 UTC 2024
On Wed, Oct 9, 2024 at 4:31 AM Wendy Brown - QT3LB-C <wendy.brown at gsa.gov>
wrote:
> I disagree with your categorization of 5 / cessationOfOperation
> Only the subscriber might know if they have decided to stop operating the
> system for which the certificate was issued and should be able to request
> revocation for that reason. It does not necessarily mean that the CA messed
> up.
>
Completely agreed, under the traditional interpretation of that reason
code. This is why I said that my proposal "means departing somewhat from
the original reason code definitions as laid out by ITU-T X.509". We would
be redefining cessationOfOperation away from "the subject entity has ceased
operating" and instead to "the certificate has ceased operating". This
change of meaning might have some surprising consequences that we should
talk through, but that's exactly why I started this email thread.
On Wed, Oct 9, 2024 at 5:59 AM Lahtiharju, Pekka <
pekka.lahtiharju at teliacompany.com> wrote:
> Hi,
>
>
>
> I would like to discuss the case 3 / affiliationChanged. What if
> Subscriber has changed their O name and want to replace their current now
> invalid certificates. Today we have instructed them to use 3 /
> affiliationChanged but the described new proposal would deny that. I think
> that Subscriber initiated 3 / affiliationChanged is better in this use case
> than 4 / superseded (or 0 / unspecified).
>
If the Subscriber has changed their Organization name and replaced their
old certificates with new ones that contain the updated Subject
Information, then the old certificates can (in my opinion) be accurately
described as "superseded".
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20241009/71ff7534/attachment.html>
More information about the Servercert-wg
mailing list