Historically, the interpretation of revocation case 4.9.1.1(12) and
other similar reasons that start with "the CA is made aware" or "the CA
determines", leaves some room for the CA to evaluate inputs before
making a final determination. The community and Root Programs can do
their independent evaluations (or "determinations") but the BRs
currently leave the CA some room to "become aware" or to "determine".
The 5-day revocation clock starts when the CA "determines" or "becomes
aware" which can be after the input of the community or the opinion of
Root Programs.
Again, I'm not judging if this is proper or not, but this is how the
current rules are written.
Dimitris.
On 19/6/2024 9:39 π.μ., Watson Ladd wrote:
I'm not sure the community feedback is the relevant part here.
Certainly in a complex situation the CA might be genuinely unsure if
mississuance happened. However it's always safe to revoke and reissue
with a known good procedure. There's a point where this is pointless,
and one where it's necessary, and I'm not going to pretend I know
ahead of time or even afterwards necessarily. But that's why I think
it's important to focus on what the CA believes. We can't reasonably
hold CAs responsible for revoking certs they didn't know were
mississued, unless they really should have. We can hold them
responsible for recovocation they know needs to happen. And I don't
think acquiring that knowledge is necessarily instant (although they
do need to properly investigate).
Asking the community doesn't change that equation.
Sincerely,
Watson Ladd
On Tue, Jun 18, 2024 at 10:21 PM Roman Fischer
<[email protected]> wrote:
Would the situation change if it was
1: A CA suspects they have miss-issued certificates but are not 100% sure about
the interpretation of the regulation
2: They ask for community feedback
3: ...
?
Kind regards
Roman
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Watson Ladd
Sent: Mittwoch, 19. Juni 2024 00:35
To: public <[email protected]>
Subject: Revocation necessity: subjective or objective
Hello,
In a discussion on Bugzilla we approached the following hypothetical scenario:
1: A CA believes they have miss-issued a certificate
2: They fail to revoke in 5 days
3: They discover that in fact they issued correctly.
My question is simple: is the failure to timely revoke a violation of the
baseline requirements? I believe it is for the following reason. A CAs past
behavior is an indication of the degree future trust that can be put in it. How
it acts in this case is evidence of how it acts with other mississuance cases.
It also seems to add a great deal of moral luck if the reason there wasn't a
problem was unknown to the CA.
Imagine that they thought DNS validation wasn't working properly, but in fact
there had been proper DNS checks working all during that time.
They would be safe by accident. I do see how one could read the BRs otherwise,
but I don't think that's as good a reading.
Sincerely,
Watson Ladd
--
Astra mortemque praestare gradatim
--
You received this message because you are subscribed to the Google Groups "CCADB
Public" 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/ccadb.org/d/msgid/public/CACsn0cn-QcPo4QWgZDcmOmCHtCOmchA3wuWb9SXpk1o_Un3eBw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "CCADB
Public" 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/ccadb.org/d/msgid/public/ZR0P278MB0170B1AE2121700FAB11F041FACF2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.
--
You received this message because you are subscribed to the Google Groups "CCADB
Public" 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/ccadb.org/d/msgid/public/e7f3d2dd-86c6-4ebb-b7e7-b3196c4efb93%40harica.gr.
