[Sidrops] Re: Notification for draft-spaghetti-sidrops-rpki-ta-tiebreaker

[Martin Hoffmann <[e-mail]>]

Job Snijders wrote:
> 
> An argument in favor of also looking at notAfter is that it is
> possible for CAs to 'freeze' the notBefore at a given point in time,
> meaning that in subsequent issuances the same notBefore continues to
> appear. I've seen some RPKI CAs (unsure about TAs) exhibit this
> behaviour.

I figure we can reasonably trust (ha!) TA operators to be careful.

> I'd also argue that defining a 'complete' tiebreaker procedure at the
> small expense of having a handful of sentences and 4 lines of code* is
> worth it to cover for the edge case of TAs issuing with identical
> notBefore's.

It’s not really complete though, since you still have the case that both
notBefore and notAfter are identical. So you still need to define what
happens if you have two different certificates with identical times.

Worse, if you have identical notBefore dates but differing notAfter
dates, you need to make an arbitrary choice which one of the two
certificates you choose. There just isn’t a “clearly it’s this one”
kind of answer.

So having this additional check doesn’t provide extra safety. I want to
argue that if there’s no benefit, leave it out.

> Another approach is to pick a random URI from the
> TAL (be it HTTPS or rsync), because with the proposed protection
> mechanism rsync becomes less risky. Picking a random URI from the TAL
> has the benefit that if they are hosted on different FQDNs, overall
> resilliency increases.

I still wouldn’t want to use rsync unless HTTPS doesn’t work -- if only
to keep the rsync load on TA operators at a minimum. Whether we should
suggest to randomize URIs (of the same type) is a question I’d would
like some input from the TA operators from. Given that currently there
is always exactly one HTTPS URI and exactly one rsync URI, it’s all a
bit academic. If the operators say that they want to keep it that way,
I’d rather not have to have randomizing code that isn’t actually ever
used.

  -- Martin