Hi Yaron, Ilari, all, I think the current PLANTS/MTC point and Usama's motivation question are connected. The draft may be easier to review if it separates the cached commitment from the test that decides whether a later certificate chain satisfies that commitment.
A possible split: - continuity state: the client has cached that this service identity committed to PQC-capable authentication for a bounded period; - credential-class test: the client needs a deterministic way to decide whether the presented chain satisfies the commitment, including the end-entity key/signature and, where relevant, the issuer/signature properties; - failure behavior: if the cached commitment applies and the presented chain does not satisfy it, the client fails closed with a clear error. For MTC/PLANTS, I agree with Ilari that the server-side and client-side views may differ: the AP may not have a simple signal in the MTC itself for the issuer-side algorithm, while the RP may be able to evaluate it from trust-anchor or issuer metadata. Calling that out as an open interaction might be safer than trying to resolve it in this draft immediately. If useful, I can write this up as a small Motivation / Credential-class test text proposal. Best, Songbo Bu On Tue, 9 Jun 2026 22:26:48 +0300, Yaron Sheffer <[email protected]> wrote: > Hi Ilari, > > Understood. We would need to look further at the interaction > between PLANTS and PQC Continuity. Specifically, we would need to > understand the PLANTS trust model better before deciding how the > commitment should apply in that case. > > Thanks, > > Yaron > > On 09/06/2026 22:03, Ilari Liusvaara > wrote: > > On Tue, Jun 09, 2026 at 09:45:07PM +0300, Yaron Sheffer wrote: > > The AP (server, in this case) must be able to determine which > certificate/MTC and corresponding private key to use when > generating CertificateVerify. Therefore, the information needed to > act within its commitment must be available to the AP, even if it > is not explicit within the MTC. > > This only determines the server key algorithm, not the certificate > signature algorithm. The two can differ, and the draft requires both to > be PQC. > > The MTC certificate signature algorithm is implicitly determined > by the issuer. The AP would need some way to look up the algorithm by > issuer. > > (Unless the AP does nasty hacks like assuming any signature that is > over 1kB is post-quantum.) > > Similarly, the MTC is received by the RP (client, in this case) along > with a CertificateVerify that clarifies the nature of the > authentication. So the RP can determine if the server is acting > within its commitment. > > It is not enough to do this (due to the above), but the RP knows the > algorithm for each issuers it trusts, so it can check if it is > allowed or not. > > -Ilari > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
