Re: [Sidrops] what to do when the CRL is hosed?

[George Michaelson <[e-mail]>]

the questions you pose come back down to two things to me

1) high-in-the-tree burdens exist. They're not more complex than
low-in-the-tree but they (by definition) affect more things, and more
people (RPs) -I have suffered failures in my service as Nathalie has,
and I respect her integrity in doing a public disclosure and
root-cause analysis, and I feel a similar burden. You need me to be
able to say "this happened" and I have to accept you saying "what have
you done, to prevent it happening again" just like Nathalie did (and
accepts I believe)

2) "how do you know what it means" is really hard. A lot of statements
about "..and so this means" are post-hoc interpretations of what the
CA and RP *think* the situation means, but the intent is actually not
overt in the situation, its latent. If you cannot point to a document
which clearly says what a situation means, then I feel its undefined.
That is what spec work is for. Thats why we're here.

The CA did not mean to fail to publish a CRL. The RP is faced with
having only out of date CRL. "what does it mean" is really hard to
infer a priori. Is there a documented intent of what it should mean?
Do we all agree?

I feel the CRL situation is like that. There should have been one.
There are only stale ones, or a badly informed one. It is confusing.
Incoherent. It feels like we didn't say very clearly "what does it
mean" in the spec process, if people feel there are open questions and
are free as RP to interpret this, I feel we didn't adequately wire
this down. If thats not true we shouldn't be discussing it, because it
is documented.

if you like, the question for me is 'how did you get to the word
"clearly" here, because it feels like "clearly some mistake let us get
to this discussion" is not a-priori, but is post-hoc reasoning,
because Nathalie told us it was a mistake'.

How do you know, in advance, the bad CRL situation "clearly" is a
mistake? You have to ask "did you make one" and if the CA says yes,
then it is possibly an RP problem, or an attack along the path to the
data, or some other issue. If the CA say "oh no.. that shouldnt have
happened" you "clearly" know its a mistake, but that depends on
asking, and being told.

Remember we now have RSYNC and RRDP, and they do not actually have to
cohere, they are obviously by intent meant to be eventually
consistent, but we have two ways to say what is the state of a
repository. This means there are at least two ways RPs may synchronise
on the state of a repository.  Persisting state measured in hours
around states of a repository do tend to align in both worlds, but I
believe its possible for the persisting state to be incoherent (I
believe this, because I believe it happened in the APNIC repositories)
which is an added complexity.

I think I would like a world which said "if the thing I see is
malformed, and if I can tell its malformed but I can also tell it was
well signed, I will go with operation error, and consider fallbacks"
-but if the thing is missing, or badly signed, it feels more like an
attack, or risk of attack. Well signed, but badly formed is the
special state of "you did this, but it is wrong" and so I do break it
out. I could believe we want some fallback behaviour. I could also
believe "wrong is wrong" is a better place to be.

-G