Re: [TLS] Merkle Tree Certificates

[David Benjamin <[e-mail]>]

On Tue, Mar 14, 2023 at 1:47 PM Watson Ladd <[e-mail]> wrote:

> Come embrace the temptations of the Sea-SIDH!
>
> Intermediate certs are rarely used, so that would achieve 204 byte sig
> on intermediate+ 64 byte intermediate key + 204 byte  sig of EE cert
> since the signing time doesn't matter. Then with SCT and OCSP, it's
> 204 bytes each.
>

I wasn’t able to find a reference to a Sea-SIDH signature scheme. Do you
have a pointer? Do you mean this thing?
https://eprint.iacr.org/2020/1240.pdf

Taking 2 seconds to generate a signature is... certainly a constraint. :-)


> As for the actual proposal, I like the idea of per-protocol subjects.
> I am worried about the way this makes the PKI a more distributed
> system, in the Lamportian sense. A certificate being used successfully
> depends now on the transparency service propagating the batch from the
> CA and the CA creating the batch, and the user-agent, not the site,
> determines what transparency service is used. This makes it much more
> difficult for sites to be sure their certificates will actually work.
>

To some degree, subscribers already rely on this. RPs have various
requirements, and it is up to the CA to provide subscribers with
certificates that meet the requirements. Some requirements can be checked
by the subscriber, but some cannot.

In X.509, the certificate chain and signatures can be checked by the
subscriber. (Although X.509 is so complex and variable that it’s unlikely
the subscriber’s checks exactly matched the RP’s!) But other requirements,
notably future policy actions, cannot. The certificate may later be
revoked, the CA or CT log may be distrusted, etc.

In this proposal, we could have the CA pass the subscriber the signed
window alongside the proof (not currently in the draft, but this is a good
reason to include it). The subscriber can then check the inclusion proof,
hopefully with much less implementation variability than X.509.

The subscriber still needs to know if the RP recognizes that batch. These
are more dynamic than X.509 roots, but are covered by the negotiation
mechanism. On mismatch, you just pick another certificate, such as an X.509
one which is as checkable as before. So this part isn’t so much checked as
made moot. (A negotiation mechanism is ultimately “tell me if the RP will
accept this cert, so I can filter down to the ones that work”.)

Finally, subscriber and RP must agree on what, e.g, root hash #42 was. This
flows from CA to TS to RP, which is indeed hard for the subscriber to
directly check. (Though the subscriber could always fetch hashes from known
TSs to compare.) However, a mismatch here means the CA produced a split
view. The responsibilities have shifted, but analogous misbehavior in X.509
+ CT would typically result in a policy action, something the subscriber
already cannot check offline.

David