Proposal

Summary

Enforce the full lifetime of a segment/beacon is covered by the validity time of
at least one certificate chain.

Background

Problem

Currently, we do not enforce that the certificate chain that is used to verify a
segment is covering the full lifetime of the segment. Rather, we check that the
certificate chain is valid at verification time. This can cause issues if the
signing entity is failing to renew its certificate chains and issues segments
that with a lifetime that is not covered by any certificate chain. If the
segment life time is covered partially by a certificate chain, it can be verified
and will be inserted into segment/beacon storage. If there is a path segment request
that matches this segment, it will be part of the response. As soon as the
certificate chain expires, the segment is no longer verifiable. This causes
all future requests to fail with signature verification errors.

How did we end up here?

Initially, there was an idea floating around that we could renew a certificate
chain for the same public key. In that world, having more lax verification rules
is nice, because the signing entity can create segments with longer lifetimes
even though its certificate chain has not been renewed yet. If the signing
entity succeeds to renew the certificate chain before the previous one expired,
the segment can be verified the whole time, without any issues.

However, this is mostly a theoretical advantage that comes with complexity
drawbacks. There are many more combinations between segment lifetime and
certificate chain validity time. The system also becomes a lot harder to reason
about. Furthermore, in practice each certificate chain authenticates a fresh
public key for better key hygiene.

Solution

There is two sides to this problem. The signing entity and the relying party. To
make this a non-breaking change, we can start with adapting the behavior of
signing entity to ensure that no segments are created with lifetimes that are
not covered by a certificate chain. At a later stage, we can update relying
parties to not accept segments that are not covered by a certificate chain.

Signing entity

The change to the signing entity is fairly small. When creating the hop fields
and peer fields for the AS entry, the expiration time should be chosen such that
the full lifetime is covered by the available certificate chain.

Relying party

The change to the relying party is again fairly small. When a segment is
verified, the relying party additionally checks that the lifetime is fully
covered by the validity of the certificate chain. In theory, this is a breaking
change. However, in practice, segments that will be rejected by this change only
stem from cases where the certificate renewal fails.

Alternatives

As an alternative, we could change the segment lookup and beaconing behavior to
filter out segments that can not be verified at the current time. This would
limit the effects of a missing certificate chain for a segment to one entity.

(Side-note: This check would be good even if we go with the proposal.)

However, this is not enough to behave correctly. Entities need to proactively
fetch certificate chains to fill in the gaps, as they might not learn the new
certificate chains passively. This is a lot of additional complexity that is
currently not implemented and will be hard to get right. It is also hard to
justify this additional complexity if in practice that feature will never be
used due to the rotated private keys on every certificate.