On Fri, Mar 10, 2023 at 05:09:10PM -0500, David Benjamin wrote: > > I've just uploaded a draft, below, describing several ideas we've > been mulling over regarding certificates in TLS. This is a draft-00 > with a lot of moving parts, so think of it as the first pass at > some of ideas that we think fit well together, rather than a > concrete, fully-baked system. > > Thoughts? We're very eager to get feedback on this.
Some quick comments / ideas: - I think it would be easier for subscribers to get inclusion proofs from transparency service than certificate authority. This is because issuance is heavily asynchronous, whereas most servers assume ACME is essentially synchronous. If certificates are canonicalized (this is mostly matter of ensuring the names are always sorted), this could be endpoint to download known inclusion proofs by certificate hash. Or maybe even have both, and subscribers can use whichever is more convinient. - I don't think there are any sane uses for >64kB claims, so the claim_info length could be shortened to 16 bits. I don't see rule for how claims are sorted within each type, only how different types are sorted. - If each claim was in its own Claim, then one could maybe even shorten it to 8 bits. Similarly, one could merge ipv4/ipv6 and dns/dns_wildcard. This could also simplify sorting: Sort by type, lexicographic sort by claim contents. - I don't think anybody is going to use signatures with >64kB keys, so subject_info length could be shortened to 16 bits. - What does it mean that in this document the hash is always SHA-256? - Apparently issuer id is limited to 32 octets. This could be noted in the definition. - I think it would be easier if lifetime was expressed in batch durations. Then one would not need window size, and especially not handle lifetime / batch_duration not being an integer! - The root hash being dependent on issuer and batch number iff there are multiple assertions looks very odd. Empty assertion list might be special. But this also happens for one assertion. - I think LabeledWindow should add 64 spaces in front, so it reuses the TLS 1.3 signature format. This reduces risks of cross-protocol attack if the key gets reused anyway (despite there being MUST NOT requirement). - Is there reason for type of trust_anchor_data to vary by proof_type? Why not always have MerkleTreeTrustAnchor there? - And proof_data length field should probably be 16 bits. I don't think proof_data will ever exceed 8kB. - For type-independent expiry info to be helpful, this must be somehow plumbed to the TLS server. - Even if ACME itself allows for long processing delays, many (most?) ACME clients do not. - Multiple orders from single newOrder or multiple certificates in single order sounds like it would break assumption made in ACME rather badly, and thus recipe for trouble. - Isn't cert_type deprecated? - "We may need to define a third one.", you men fourth one? - I think the uniform certificate format is already a requirement in TLS 1.3. And OpenPGP format is banned in TLS 1.3 anyway. So parsing to extension blocks without knowing certificate type is no problem. > On Fri, Mar 10, 2023 at 4:38 PM <internet-dra...@ietf.org> wrote: > > > > > A new version of I-D, draft-davidben-tls-merkle-tree-certs-00.txt > > has been successfully submitted by David Benjamin and posted to the > > IETF repository. > > > > Name: draft-davidben-tls-merkle-tree-certs > > Revision: 00 > > Title: Merkle Tree Certificates for TLS > > Document date: 2023-03-10 > > Group: Individual Submission > > Pages: 45 -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
