[Plants] Re: MTCLogEntry extensibility

[Angel <[e-mail]>]

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.

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]>) escribió:
>
>
>
> 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
> _______________________________________________
> Plants mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]