[Plants] Re: Nits

[David Benjamin <[e-mail]>]

On Thu, Apr 9, 2026, 14:29 Watson Ladd <[e-mail]> wrote:

>
> On Wed, Apr 8, 2026, 4:06 PM David Benjamin <[e-mail]> wrote:
>
>> On Wed, Apr 8, 2026 at 5:20 PM Watson Ladd <[e-mail]> wrote:
>>
>>> Dear gardeners,
>>>
>>> We use an encoding trick to avoid issues with zero based indexing: why
>>> not burn a cert there to avoid complicating things? Very minor.
>>>
>>
>> Do you mean the serial number? We *do* burn a cert, specifically to
>> *avoid* complicating things with an encoding trick. That's why entry
>> zero has to be a null_entry. Or are you talking about something else?
>>
>
> The null_entry isn't a cert. But I guess it doesn't matter either way
> since nothing sees it.
>

Ah sure, I should have said we burn an entry. And yeah it's a bit tidier I
think to just put a null entry, with semantics of "you just certified that
the empty set is vacuously true, cool I guess". Otherwise we have to put an
actual certificate in there and arrange for it to not mean anything and
then teach all the monitors to ignore it, etc.

To that end, the monitors will see it since it's part of the tree. But
since it's just null and we define null to be a no-op entry it's all good.
For bonus points we exercise the entry type extension point a little for
free.


(The Merkle tree really, *really* wants zero-based indices. There's this
>> very nice correspondence between tree structure and the binary
>> representation of the entry's index that only works with zero-based
>> indexing. X.509 technically forbids serial number zero. To solve this
>> annoying conflict, the draft just burns a certificate to avoid thinking
>> about this.)
>>
>>
>>> I'm not sure 503 is the right error code for the landmark-relative cert
>>> in ACME: a 400 series code would make more sense given that some are about
>>> resource conditions. There isn't one that fits though. 503 may complicate
>>> infrastructure monitoring as it is usually a server problem you want to
>>> worry about.
>>>
>>
>> Hmm. I think I picked 503 just because that was the existing semantics
>> for Retry-After paired it with 503. But that is a good point that we don't
>> *really* satisfy the expectations around 503.
>> https://www.rfc-editor.org/rfc/rfc9110#section-10.2.3
>>
>> I've filed https://github.com/ietf-plants-wg/merkle-tree-certs/issues/202
>> to track this. Do folks have thoughts on what it should be instead?
>>
>>
>>> Most seriously I'm not entirely clear on how given the certificate we
>>> find out what trust anchor ranges cover it. I think that there in the
>>> current draft there is some out of bound data required and I think this is
>>> solveable by tossing the landmark ID in the cert. That would simplify
>>> integration as a pile of DER is still all that needs to be parsed by the
>>> server, vs changing the representation.
>>>
>>
>> TLS Trust Anchor IDs defines this CertificatePropertyList structure that
>> contains this kind of CA -> subscriber information, with a PEM
>> serialization and all:
>>
>> https://tlswg.org/tls-trust-anchor-ids/draft-ietf-tls-trust-anchor-ids.html#name-certificate-properties
>>
>> The idea is that we use this as an extensible vehicle for any kind of
>> CA-provided out-of-band information that doesn't need to be in the
>> certificate (relying party doesn't care, would just be a waste of bytes),
>> but that the authenticating party would want to know when using the
>> certificate.
>>
>
> Gotcha. I think this would then mean you need an association between those
> three PEM files (the key, the cert, and the additional information) vs. a
> bag of PEM you all throw in (all the certs one place, all the keys and
> auxilliary info elsewhere). I think the bag of PEM might be a little easier
> for some applications but not that sure. Separately it might be worth me
> writing a PR to put that pointer in where I started wondering how that
> works but I fully understand if we don't want to make a cluster.
>

The current proposal has the aux info and the certs in one PEM blob, but
not the private key, just because ACME is responsible for delivering the
two and not the one. (Maybe the private key doesn't even exist as a PEM
blob because it's locked away on some HSM, I dunno.)

But that's just the interchange at the ACME level. I see no reason why
server software can't concatenate it with the private key, or split them up
fully, or whatever your server uses to store it's config.

And yeah if that wasn't obvious from the spec, PRs sound good! A lot of it
is by reference to the TAI spec, but we should make whatever changes to one
or the other we need to make it clear!


(There's some precedent for this sort of thing in other contexts, like the
>> OpenSSL-specific X509_AUX stuff, or how PKCS#12 blobs can have
>> bagAttributes with your CertBag. For that matter, we could even recast this
>> as ASN.1 Attributes if people prefer, but since that's so far only been
>> applied to PKCS#12, it wasn't clear how much we'd gain from there. CAs, for
>> example, generally don't hand you PKCS#12 blobs because CAs generally
>> aren't in the business of generating your private key.)
>>
>> David
>>
>
>
> Astra mortemque praestare gradatim
>