On Thu, Feb 3, 2022 at 7:24 AM Doug Beattie <[email protected]>
wrote:
> Ryan,
>
>
>
> The intent of my recommendation was not to increase the burden or limit
> the ability of subscribers to revoke keys, it’s setting the
> proper/consistent revocation reason codes. In Kathleen’s proposal, if you
> want to revoke for key compromise but can’t demonstrate pop, then you can
> do that, but it results in just that one cert being revoked (same as
> unspecified). If the CA and CRL show revoked for key compromise (when POP
> is confirmed), then there are other actions to be performed (revoke other
> certs with the key across all subscribers, block further issuance across
> all subscribers).
>
Correct.
> If we’re not doing that all the time then how is the relying party to know
> if this was really a key compromise or not? If we set the reason to
> unspecified (no reason code in CRLs) when POP is not verified everyone will
> have the same understanding of what key compromise means – it was confirmed
> to be compromised and there should not be any active certificates issued
> from that CA with that key (something 3rd parties will surely want to watch
> for)
>
I'm not sure I follow this concern at all? It sounds like your goal is
"KeyCompromise should only mean revocations with proof of possession" - but
if so, I think we disagree on that goal. Is that the case?
As to why that goal may be seen as useful, this sounds like the case of
believing that CA X should be able to watch CA Y's revocations, but I'm not
sure that's necessarily good or positive, because it's an assumption that
CA Y performed all steps correctly. Just like we don't allow CA X to issue
a cert to a Subscriber with {Key 1, Domain} just because CA Y issued a cert
to a Subscriber with {Key 1, Domain}, we shouldn't trust the revocation
information either
>
>
> You mentioned this below:
>
> However, an additional consideration is that keyCompromise revocations
> *are* likely more valuable than other forms of revocations, both in terms
> of efficient and timely delivery and in user risk. A policy that restricts
> when and how Subscribers can request this revocation is thus one that
> limits the value of that, by making it harder, which harms end users more.
> The more barriers placed for Subscribers, the harder it is to get this
> information in a timely fashion.
>
>
>
> Maybe this is where I’m missing an important point. Why is the key
> compromise reason more valuable and why will it happen more efficiently and
> timely than other reasons in the case where the CA cannot validate POP?
> Both can happen “immediately” and the end result is that (just) the
> requested certificate is revoked, so does the reason code matter?
>
>
>
> If we don’t tighten up the processing of key compromise revocations, then
> we have 2 different paths to go down when a subscriber requests revocation
> for key compromise, and we provide a false sense of “security” to those
> that are looking at the CRL (this key is marked as key compromised, but
> it’s OK for it to be in other past and future certificates). If it’s
> compromised, it should be confirmed to be compromised and if we can’t
> confirm that, then it should be revoked with another reason.
>
Hopefully Rob successfully showed why this conclusion is flawed. "It should
be confirmed to be compromised" is wholly unnecessary for relying parties,
and does not grant a false sense of security. Revocation is first and
foremost about a certificate, not about a key; while it's nice to be able
to more affirmatively express something about a key, that's not how the
system works, nor designed, nor needs to.
As to the other part of your questions, didn't Kathleen already address
this with
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SIqvgTmKnno/m/UPsTMDGAAwAJ
? "Why will it happen more efficiently and timely" is precisely because
there are bounds to how effectively one can deliver information to browsers
in an efficient, privacy preserving, data-respecting way. The whole effort
of harmonizing reason codes is to provide consistent expectations that
would allow user agents to prioritize multiple methods of delivery, based
on the semantic meanings of the codes, reflecting the relative importance
and need.
Maybe you can elaborate on how you've been thinking about how this
information is delivered. Have you been thinking solely in terms of OCSP
and CRLs? That may explain the disconnect, given that those are not widely
used directly by end clients.
--
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%3DHGxZM9cULfqw0HYOvK57JR7YnJPQ0-ruLPqb%3DF2Y%2B_DLw%40mail.gmail.com.
