On Tue, Mar 14, 2023 at 1:47 PM Watson Ladd <watsonbl...@gmail.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
