I'm not really sure about weaking the meaning of keycompromise.
Currently if I saw a cert revoked it by keycompomised then one can throw
its public key into 'leaked keys' bin and propargate key-purging between
CA by pointing other CAs revoke this certifiate with same key as
compromised- like multiple smime certificates from different CAs as
there is no CT and first one who revoked key may not know that second
cert with same key exsit.
although right thing to do such case would be notify the original holder
in first revocation and let subscriber call the key with other CA they
signed or have some kind of central leaked-publickey-here repository.
sent again, to the list this time
2022-02-03 오전 7:35에 Ryan Sleevi 이(가) 쓴 글:
On Wed, Feb 2, 2022 at 7:25 AM Doug Beattie
<[email protected]> wrote:
Will the CA block further issuance when the request for revocation
does not include PoP which could DoS them for renewal using the
same key pair? To me, if the subscriber can’t provide PoP of the
private key the unspecified reason code would be more accurate.
What’s the value to the subscriber, CA and ecosystem to treat that
case as key compromise vs. unspecified?
I’m probably just not understanding the background and value for
the second rule around processing requests for revocation with key
compromise without PoP.
As hopefully my reply to Aaron captured a little, it's about where the
burden rests.
Today, for most TLS issuance, no POP is required. That's because TLS
itself doesn't need a POP, because it's an online protocol - the POP
is delivered in-band, and it's not an identity-attestation system
based on a directory (e.g. compared to S/MIME, where a sender needs to
look up your public key ahead of time to encrypt something to you)
So the functional change of requiring the POP is that very few people,
today, could request keyCompromise without doing more work. That's not
ideal.
Further, however, is that for situations that are not uncommon, such
as malicious deletion or ransomware, there is zero guarantee the
victim would be able to prove keyCompromise at that time.
This is very similar to the discussions in the past of how many hoops
a CA can place to request revocation (i.e. "You can only request
revocation on the fifth Tuesday of every February under the full
moon"). For Subscribers, and users, this matters.
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.
So, to end users, it's ideal where Subscribers can request any
revocation reason that they want (... within reason), and for imposing
obligations on CAs, to use particular revocation reasons when they're
made aware, either internally or by externally reports. That protects
users the most.
However, because there's no POP, that does offer _some_ abuse
scenarios from malicious entities wishing to abuse the policies, and
so some safeguards are needed. The question posed to this group is,
seemingly, do we want to throw the baby out with the bathwater?
Namely, should Subscribers have flexibility to (as easily as possible)
request the method of their choice, or is the risk of abuse too great
to trust them?
I'd like to find a solution where we can empower Subscribers as much
as possible, because that can help protect Users the greatest. I think
you're right that we want to figure out how to narrowly scope the
abuse scenarios, so definitely, thanks for raising 6.1.1.3. We should
try to find a way to best balance things, don't you agree?
--
You received this message because you are subscribed to a topic in the
Google Groups "[email protected]" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/mozilla.org/d/topic/dev-security-policy/RVFnJJRuUag/unsubscribe.
To unsubscribe from this group and all its topics, 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%3DHEaptK1R7PMBFNYvp6_hHcMD4FRL7C3b4OP1yK2YaJFzQ%40mail.gmail.com
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHEaptK1R7PMBFNYvp6_hHcMD4FRL7C3b4OP1yK2YaJFzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/fc5dcfda-d14f-a868-364a-d96341df7563%40gmail.com.
