On Wed, Oct 9, 2024 at 4:31 AM Wendy Brown - QT3LB-C <[email protected]> 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 < [email protected]> 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
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
