MIME-Version: 1.0
References: <1db301dd51ab$db1cfb30$9156f190$@gmail.com>
In-Reply-To: <1db301dd51ab$db1cfb30$9156f190$@gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 1 Oct 2026 10:06:23 -0400
Message-ID: 
 <CAF8qwaCuHX0y=Ck0q1W1J3jhquc8ZHpSNGi22QDqnVZevOWFYw@mail.gmail.com>
To: Valery Smyslov <smyslov.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c8c289065cc7ecee"
Message-ID-Hash: IEK5WGSNXUGQHGZGSJFZYWHPF7FS4QHK
CC: ilariliusvaara@welho.com, plants@ietf.org
Precedence: list
Subject: [Plants] Re: MTCLogEntry extensibility
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/plants/aOFxSLhcneoiG84Xv6BIGFHcq2k>

--000000000000c8c289065cc7ecee
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 1, 2026 at 9:51=E2=80=AFAM Valery Smyslov <smyslov.ietf@gmail.c=
om>
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 th=
e
> 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 -- plants@ietf.org
> > To unsubscribe send an email to plants-leave@ietf.org
>
> _______________________________________________
> Plants mailing list -- plants@ietf.org
> To unsubscribe send an email to plants-leave@ietf.org
>

--000000000000c8c289065cc7ecee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare=
nt">On Thu, Oct 1, 2026 at 9:51=E2=80=AFAM Valery Smyslov &lt;<a href=3D"ma=
ilto:smyslov.ietf@gmail.com">smyslov.ietf@gmail.com</a>&gt; wrote:</span></=
div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">H Ilari,<br>
<br>
&gt; &gt; My concern is that the type of the MTCLogEntry is not known to th=
e relying party.<br>
&gt; &gt; The relying party needs to reconstruct the MTCLogEntry to validat=
e the inclusion proof<br>
&gt; &gt; and the algorithm in the Section 7.2 blindly assumes that the ent=
ry<br>
&gt; &gt; always has the tbs_cert_entry format. In case this format is exte=
nded in the future,<br>
&gt; &gt; how the relying party would know that a particular MTCProof struc=
ture<br>
&gt; &gt; corresponds to a new format (I assume the relying party supports =
both formats)?<br>
&gt; <br>
&gt; If the thing RP is processing is a certificate, it is tbs_cert_entry.<=
br>
&gt; If it is something else (defined later), then it is something else.<br=
>
<br>
So, the data format for log entries for certificates is fixed forever?<br>
I think that this can become a limitation in future...<br></blockquote><div=
><br></div><div>Well, log entry is basically a TBSCertificate. In plain X.5=
09,=C2=A0the=C2=A0data format for a TBSCertificate is fixed forever, and we=
 seem to have managed OK. :-)</div><div><br></div><div>But it actually isn&=
#39;t fixed. <i>If</i>=C2=A0we wanted to make tbs_cert_v2 (maybe we want to=
 tweak the hashing construction for the SPKI), we&#39;d make something like=
 id-alg-mtcProof-v2 and have that kick in a different verification process.=
 I don&#39;t particularly anticipate needing to do this, but it <i>is</i>=
=C2=A0a lever we can pull <i>if</i> we need it.</div><div><br></div><div>Of=
 course, if we were to do that and weren&#39;t cycling CAs at the same time=
, we&#39;d have to ponder the negotiation path on the transition side. It m=
ight be easiest to transition it by cycling CAs. And then it <i>really</i>=
=C2=A0isn&#39;t fixed because we can always just define MTCv2 and say &quot=
;this CA is MTCv1 and that CA is MTCv2&quot;, using the same X.509 extensio=
n points we did this time around.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
&gt; E.g., in-tree revocation list could have type of intree_crl_entry.<br>
&gt; <br>
&gt; <br>
&gt; &gt; In my opinion, the MTCProof should include MTCLogEntryType, so th=
at<br>
&gt; &gt; the relying party would know how to reconstruct MTCLogEntry.<br>
&gt; &gt; Something along the lines:<br>
&gt; <br>
&gt; No, this would be insecure.<br>
<br>
Why?<br>
<br>
Regards,<br>
Valery.<br>
<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; -Ilari<br>
&gt; _______________________________________________<br>
&gt; Plants mailing list -- <a href=3D"mailto:plants@ietf.org" target=3D"_b=
lank">plants@ietf.org</a><br>
&gt; To unsubscribe send an email to <a href=3D"mailto:plants-leave@ietf.or=
g" target=3D"_blank">plants-leave@ietf.org</a><br>
<br>
_______________________________________________<br>
Plants mailing list -- <a href=3D"mailto:plants@ietf.org" target=3D"_blank"=
>plants@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:plants-leave@ietf.org" ta=
rget=3D"_blank">plants-leave@ietf.org</a><br>
</blockquote></div></div>

--000000000000c8c289065cc7ecee--