[Plants] Re: An independent Rust implementation of the -07 formats, interop-tested against demo/

[Angel <[e-mail]>]

Hi all,

A short follow-up. mtc-core is now also measured against OpenSSL's MTC pull
request (openssl/openssl#33014, at ecf0476) and Bob Beck's mtc (c6cdfe2):
certificates in both directions, a TLS 1.3 handshake through s_server and
s_client, and OpenSSL's test/mtc corpus. All verdicts agree except one, and
that one is a question for the draft rather than a bug.

test/mtc/mtc-landmark-1-iana-alg.pem is a -06 landmark certificate with the
IANA id-alg-mtcProof (1.3.6.1.5.5.7.6.67) in both signature fields, while its
issuer keeps the experimental trust anchor ID attribute
(1.3.6.1.4.1.44363.47.3). OpenSSL and mtc accept it, recognising each field on
its own. mtc-core refuses it: it reads the issuer with the attribute of the
OID set that the signature algorithm names, one set per certificate. No CA I
have measured writes this shape, and the proof is unaffected, since the log
entry omits the signature algorithm.

During the OID transition, should a relying party accept a certificate that
mixes the IANA and the experimental OIDs, or require one set per certificate?
If the answer is to accept, I will change mtc-core; if not, the fixture might
want the IANA issuer attribute too.

Details: https://github.com/atoranzo/mtc-core (AUDIT.md §19 to §22).

Thanks,
Ángel

El mié, 30 sept 2026 a las 16:02, Angel
(<[e-mail]>) escribió:
>
> Hi all,
>
> I'd like to report an independent implementation of the current
> draft-ietf-plants-merkle-tree-certs formats and the results of testing it
> against the reference implementation in the working group's repository.
>
> What it is: mtc-core, <https://github.com/atoranzo/mtc-core>, MIT OR
> Apache-2.0. It implements the issuance log (RFC 9162 MTH over SHA-256,
> subtrees, inclusion and consistency proofs), MTCLogEntry /
> TBSCertificateLogEntry, the CosignedMessage and subtree signatures with
> ML-DSA (44/65/87), MTCProof and the certificate, the landmark sequence, the
> CA flow (log, checkpoint, covering subtrees, cosignatures, standalone and
> landmark-relative certificates), the CA certificate with the
> MTCCertificationAuthority extension (unsigned, RFC 9925), and the relying
> party's verification procedure including the single-pass entry hash. It
> targets the working repository as of 2026-09-29, i.e. the OIDs
> draft_oids.md assigns to plants-07 (id-alg-mtcProof = ...47.5).
>
> What was tested:
>
> - The four accumulated test vectors (65,058 cases, trees up to 130 leaves)
>   and the large subtree vectors (2^48-1, 2^63-1, 2^64-1 leaves).
> - Against demo/ at commit 99097c9e (Go 1.27.1), in both directions, with
>   negatives: the 26 certificates demo generates from its own mtc.json
>   (plants-07) get the same 26 verdicts from my verifier as from
>   `demo verify` (21 OK, 5 FAIL, each negative failing for the reason it was
>   built for); 9 certificates from my CA (4 deliberately broken) get the
>   expected verdicts from `demo verify`, with my CA certificate and with
>   demo's own (both CAs use demo's ML-DSA-44 test seed for 32473.1, so key
>   generation and signatures were compared byte for byte); and demo's log of
>   2122 entries rebuilt from its entry tiles reproduces its checkpoint root.
>   The procedure and script are in the repository (interop/), and the run
>   is recorded in AUDIT.md.
>
> If a documented run between two independent codebases is useful for the
> working group's interoperability milestone, everything above is
> reproducible from the repository with the commands in interop/README.md.
>
> Two things I noticed in demo/, filed as issues #341 and #342: the
> checkpoint's signature lines carry a bare subtree signature with timestamp
> zero rather than a tlog-cosignature timestamped_signature, which mtc-tlog
> seems to require; and the sample policy.txt's trusted-subtree hashes do not
> match the output of the shipped mtc.json, so the demo rejects its own
> landmark-relative certificates with the sample policy.
>
> What it is not: it is not audited; cosigners with ECDSA or Ed25519 keys are
> not verified (their cosignatures are ignored); the relying-party policy is
> the minimal "the CA plus a fixed set of cosigners", with no groups; the log
> is not persisted and there is no ACME, CSR parsing or witness client; it is
> not measured at scale. Interoperability is measured against one
> implementation only.
>
> Provenance: the code and prose were written with AI assistance; GENAI.md
> in the repository says how it was used and AUDIT.md records each verified
> change with its counters. I am the only author and accountable for it.
>
> I'm aware of the Note Well. Corrections and questions very welcome,
> especially on the two issues above.
>
> Ángel Toranzo Portela