[Plants] Re: MTCLogEntry extensibility

[Valery Smyslov <[e-mail]>]

Hi David.
 
Right, and a type field like this would be risky, redundant, and quite possibly defeat the purpose of extensibility.
 
It is risky because it tempts implementations to copy-paste the type while keeping the entry calculation the same.
 
         Well, I believe this would not be possible if the format of MTCLogEntry changes – it will not validate.
 
It's redundant because you can just define id-alg-mtcProof-v2. We *don't need a type field in there*.
 
         Ah, right, we can define a new AlgorithmIdentifier for a new MTCLogEntry format. 
         This will have the same effect as the type field in MTCProof – the RP will know how to
         re-construct MTCLogEntry. This is an alternative solution, seems that equally functional.
 
And it's likely self-defeating because maybe your fancy new entry format would need a slightly different set of fields in the proof structure.
 
         Maybe. But why it is self-defeating? Proof structure also can be made extensible, depending on the type.
 
         Regards,
         Valery.
 
David
 
On Fri, Oct 2, 2026, 04:58 Angel <[e-mail] <mailto:[e-mail]> > wrote:
Hi Valery,

You're right, and I overstated it. The type is part of the hashed
MTCLogEntry, so a type carried in MTCProof could only match a leaf the CA
logged with that same type, and an RP that only builds entries for the
certificate types it knows would ignore anything else. Carrying it would be
safe.

What remains is whether it is worth a field: the RP has to know a type's
construction rules before the value means anything to it. That is a design
choice for the editors rather than a security question.

Thanks for the correction,
Ángel

El vie, 2 oct 2026 a las 10:51, Valery Smyslov
(<[e-mail] <mailto:[e-mail]> >) escribió:
>
> Hi Ángel,
>
> > Hi Valery,
> >
> > I think the reason is the one in the draft's Extensibility section: the RP
> > builds the MTCLogEntry it expects, so an entry of any other type can never
> > match the proof.
> >
> > If the type came in MTCProof, whoever presents the certificate would choose
> > it. Then a leaf the CA logged under some future type, validated with that
> > type's rules, could be passed off as a certificate, as long as its bytes
> > can be made to line up with a TBSCertificate. The RP would hash exactly what
> > the CA logged and accept it.
>
> The type in MTCProof must be meaningful to the RP, since it defines the rules
> of how MTCLogEntry is constructed from the certificate. Thus, it cannot be
> an arbitrary type, it must be a type associated with a certificate log entry,
> other types will be ignored by RP as meaningless.
>
> Regards,
> Valery.
>
>
> > That's how I implemented it in mtc-core: the RP never reads the type
> > from the wire.
> >
> > Ángel
> >
> > El jue, 1 oct 2026 a las 21:35, Watson Ladd (<[e-mail] <mailto:[e-mail]> >) escribió:
> > >
> > >
> > >
> > > On Thu, Oct 1, 2026 at 7:33 AM Valery Smyslov <[e-mail] <mailto:[e-mail]> > wrote:
> > >>
> > >> HI David,
> > >>
> > >>
> > >>
> > >> On Thu, Oct 1, 2026 at 9:51 AM Valery Smyslov <[e-mail] <mailto:[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] <mailto:[e-mail]> 
> > >> > To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 
> > >>
> > >> _______________________________________________
> > >> Plants mailing list -- [e-mail] <mailto:[e-mail]> 
> > >> To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 
> > >>
> > >> _______________________________________________
> > >> Plants mailing list -- [e-mail] <mailto:[e-mail]> 
> > >> To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 
> > >
> > >
> > >
> > > --
> > > Astra mortemque praestare gradatim
> > > _______________________________________________
> > > Plants mailing list -- [e-mail] <mailto:[e-mail]> 
> > > To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 
>