On Wed, Mar 04, 2026 at 10:44:43AM -0500, David Benjamin wrote:
>
> In MTC, landmarks are not global. They're CA-specific and allocated per CA.
> Thus, if your CA is 32473.1, then your landmarks for that CA
> are 32473.1.1, 32473.2, 32473.1.3, etc. A landmark ID specifies *both* the
> landmark *and* the issuer and identifies the thing the relying party must
> trust to accept this certificate. That works with TAI as-is without any
> fuss.
>
> The invariant this is encoding is simply that, in a CA with 100 live
> landmarks, every client which supports 32473.1.200 can also be assumed to
> know about 32473.1.{101-199}. Thus, in a certificate issued by 32473.1.101,
> the CA can be defined (in the MTC spec) to set trust_anchor = 32473.1.101
> and additional_trust_anchor_ranges = 32473.1.{102-200}. Then the relying
> party only needs to send 32473.1.{latest-for-this-CA} to capture the whole
> range.
1) If client trusts some landmarks, it probably trusts the parent log
as well (cases where it does not are expected to be exceptional), so
needing to duplicate the parent identifier wastes space.
Data scoping constraints make it difficult for trusted log identifier
sets to not be server-global for initial advertisment, so there can be
more than a few of those.
2) The client could send 32473.{1-3}. If the server implements ranges
as lexicographic compares, this goes badly wrong, as it will match any
landmark issued by 32473.1 or 32473.2, even ones too new for the
client.
3) And even if client only uses ranges for landmarks, the lexicographic
compares go wrong in some edge cases (crossing to 2^14, 2^21, 2^28,
...). If log issues landmarks once per hour, it takes about 22 months to
reach 2^14.
-Ilari
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
