[Plants] Re: MTCLogEntry extensibility

[David Benjamin <[e-mail]>]

On Thu, Oct 1, 2026 at 9:51 AM Valery Smyslov <[e-mail]>
wrote:

> H Ilari,
>
> > > My concern is that the type of the MTCLogEntry is not known to the
> relying party.
> > > The relying party needs to reconstruct the MTCLogEntry to validate the
> inclusion proof
> > > and the algorithm in the Section 7.2 blindly assumes that the entry
> > > always has the tbs_cert_entry format. In case this format is extended
> in the future,
> > > how the relying party would know that a particular MTCProof structure
> > > corresponds to a new format (I assume the relying party supports both
> formats)?
> >
> > If the thing RP is processing is a certificate, it is tbs_cert_entry.
> > If it is something else (defined later), then it is something else.
>
> So, the data format for log entries for certificates is fixed forever?
> I think that this can become a limitation in future...
>

Well, log entry is basically a TBSCertificate. In plain X.509, the data
format for a TBSCertificate is fixed forever, and we seem to have managed
OK. :-)

But it actually isn't fixed. *If* we wanted to make tbs_cert_v2 (maybe we
want to tweak the hashing construction for the SPKI), we'd make something
like id-alg-mtcProof-v2 and have that kick in a different verification
process. I don't particularly anticipate needing to do this, but it *is* a
lever we can pull *if* we need it.

Of course, if we were to do that and weren't cycling CAs at the same time,
we'd have to ponder the negotiation path on the transition side. It might
be easiest to transition it by cycling CAs. And then it *really* isn't
fixed because we can always just define MTCv2 and say "this CA is MTCv1 and
that CA is MTCv2", using the same X.509 extension points we did this time
around.


> > E.g., in-tree revocation list could have type of intree_crl_entry.
> >
> >
> > > In my opinion, the MTCProof should include MTCLogEntryType, so that
> > > the relying party would know how to reconstruct MTCLogEntry.
> > > Something along the lines:
> >
> > No, this would be insecure.
>
> Why?
>
> Regards,
> Valery.
>
> >
> >
> >
> >
> > -Ilari
> > _______________________________________________
> > Plants mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> Plants mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>