On Mon, Feb 7, 2022 at 4:40 PM Corey Bonnell <[email protected]>
wrote:
> > If I understand correctly, you’re pointing out that unless there’s an
> explicit mandate, the lifecycle is done, while I’m trying to highlight that
> without an explicit dispensation, the lifecycle isn’t done.
>
> > I suppose this is a variation of “default allow” vs “default deny”, or
> half empty/half full: we may disagree based on perspective, even when
> looking at the same thing.
>
>
>
> I am unaware of any stated obligation for CAs to update revocation
> metadata (in particular, reasonCodes) after initial publication of the
> revocation. So, I’m struggling to see how it can be argued this is
> currently a requirement unless one subscribes to a “default MUST” reading
> of requirements, where all possible requirements are in force unless
> explicitly stated otherwise.
>
Aren't we talking about introducing a requirement/obligation for CAs to
ensure a certificate is revoked with a particular reasonCode, and thus,
implies updating the reasonCode?
I think we might have crossed our messages at some point, so to try to
recapture:
- In the status quo of today's requirements, I don't think there's
language to support that "So, in terms of the current written requirements
today, the ecosystem baseline is that revocation completes the certificate
lifecycle."
- The closest one can argue would be 5.4.3, which allows the shorter
date of (revocation or expiration), although the record archival still
fully exceeds the validity period of the certificate
- We do have explicit language (e.g. 4.10.1) that make it clear that
revoked certificates still remain operationally in scope for some
requirements
- Nothing prohibits CAs today from updating reasonCodes, and some
actively do update revocation metadata (e.g. for S/MIME)
- In the context of a hypothetical future requirement (e.g. to revoke a
certificate with a particular reasonCode), I understood your argument being
"This doesn't mean you have to update existing revocations"
- If I understood your proposal correctly, you were saying that the
new language would have to explicitly state the need to update the
revocation code, and without that, CAs could ignore existing revocations
- My response was that I didn't see any language that would support
that an already revoked certificate (with reason A) wouldn't need to be
updated to be revoked with Reason B, even in the absence of such an
explicit requirement
I suspect we're more in alignment than not, particularly that under the
status quo today, there isn't such an explicit requirement.
However, where I think we're disagreeing was what degree of new language
would be needed. I understood you to be arguing that explicit language was
*necessary*, but I was suggesting that it wasn't necessary, even if it may
be useful clarifications.
Aaron's response, I think, focused on "revoke a certificate", but may have
missed the context of "revoke a certificate with reason X"; if we say
"revoke a certificate with reason X", and it's already revoked, my argument
was that the default reading of that would be "update the reason to X, if
it's already revoked", as the active form of action, not "no action
required".
As an example for understanding obligations under the current BRs, let's
say that a Subscriber has lapsed in their Subscriber Agreement, such that
the CA revoked it, under 4.9.1.1 paragraph 2, item 3: "The CA is made aware
that a Subscriber has violated one or more of its material obligations
under the Subscriber Agreement or Terms of Use;"
Now the CA receives a Problem Report, under 4.9.5, regarding suspected key
compromise of this certificate.
1. Is the CA required to respond with a preliminary report, under 4.9.5?
2. Is the CA required to take any action, based on that Problem Report,
such as treating it as a known compromised key, as discussed in 6.1.1.3?
I'm not sure I've got a correct mental model of your position on these two
questions. If the argument is "the lifecycle is complete", then it seems
like the answer is "1. No, 2. No" for those two. But I don't think you'd be
that extreme? So it's unclear if the answer is "1. Yes, to respond it's
already revoked, and 2. No, because the problem report was deemed invalid
because the lifecycle is complete" or "1. Yes, to respond it's already
revoked, and 2. Yes, because it's still knowledge of a key compromise"
I think that may help me understand a bit more the position about whether
updating a revocation code should be seen as the default action for "Revoke
with reason X", even if the certificate is already revoked.
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHERzL8v2Lo%3D7Sk%2B3AVWPDqWoih5dvykwx4qAft9uoR1wg%40mail.gmail.com.
