[Plants] Re: MTCLogEntry extensibility

[Watson Ladd <[e-mail]>]

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

> HI David,
>
>
>
> 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. :-)
>
>
>
>          Log entry is not *exactly* TBSCertificate. It is constructed
> from TBSCertificate using some fancy rules J
>
>
>
> 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.
>
>
>
>          Yes, it is definitely possible. I was thinking more about the
> situation, when tbs_cert_entry and tbs_cert_entry_v2 need to co-exist in
> a single log
>
>          (don’t ask me why, just a thought).
>
>
>
> 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.
>
>
>
>          It is always possible to add another layer of indirection J
>

I don't think this is an extra layer of indirection beyond what exists.

A MTC CA is always going to have entries that have to have specified
meaning to a relying party.  Adjusting the format of those entries for a
validator means adjusting the semantics of what the certificates issued by
the CA means, which mens relying parties also need to change. The best
single way to do this all is to change the CA. Having each tree have one
type of entry simplifies the design of all sorts of tools as the
cross-entry relations don't need to be thought about.


>
>          Regards,
>
>          Valery.
>
>
>
> > 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]
>
> _______________________________________________
> Plants mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 
Astra mortemque praestare gradatim