sunlight: require binary comparison in chain building

[FiloSottile]

See https://groups.google.com/a/chromium.org/d/msgid/ct-policy/c1734f89-d5fa-4342-8542-04c5cbf5bfb3%40app.fastmail.com.

[benlaurie]

In my experience it is not always possible to build a chain from available information. This level of ad-hocness makes me unhappy. Why stop requiring a correct chain?

[FiloSottile]

@benlaurie I'm not sure I understand. We'd still require a correct chain on submission. We would additionally require simple Issuer/Subject comparison, to make it easier for monitors to rebuild the chain from a list of issuers, instead of including them with every leaf, which wastes a lot of bandwidth.

[benlaurie]

On Sun, 7 Apr 2024 at 18:11, Filippo Valsorda ***@***.***> wrote: @benlaurie <https://github.com/benlaurie> I'm not sure I understand. We'd still require a correct chain on submission. We would additionally require simple Issuer/Subject comparison, to make it easier for monitors to rebuild the chain from a list of issuers, instead of including them with every leaf, which wastes a lot of bandwidth.

How do the issuers get the cert in the chain?

…

— Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAJY3GQALM7IELO44ENAVLY4HHCTAVCNFSM6AAAAABF2WWZEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGYZTSMZXGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[FiloSottile]

How do the issuers get the cert in the chain?

Chains are built and submitted like usual, no changes there. Sunlight logs take every issuer (roots and intermediates) from every chain that was submitted to the log, deduplicate them, and present them in the issuers bundle.

[aditsachde]

I've been looking at the feasibility of adapting a sunlight log to the RFC 6962 monitoring interface using a proxy, as proposed in sunlight.md, mostly as a learning exercise. The complexity mentioned by @AGWA on ct-policy@ shows up here as well, and I found that the best way to solve it is to just have the proxy store the fingerprints of the certificates in the chain. Other approaches add too much compute overhead relative to the cost of just storing the fingerprints and introduce a risk of not being able to exactly rebuild the submitted chain.

Looking at the number of entries in the Argon 2023 (1831993885) and Xenon 2023 (2079641353) shards, considering an average of 2 certificates/fingerprint in the chain, and 32 bytes per fingerprint, the additional storage overhead for a yearlong shard would be under 0.15 TB, or less than $4 per month on S3 (and less on average if considering the full life of the log). It seems like the ecosystem would be better served by Sunlight logs directly storing and serving fingerprints of the certificates that make up the submitted chain.

[benlaurie]

On Mon, 8 Apr 2024 at 02:47, Filippo Valsorda ***@***.***> wrote: How do the issuers get the cert in the chain? Chains are built and submitted like usual, no changes there. Sunlight logs take every issuer (roots and intermediates) from every chain that was submitted to the log, deduplicate them, and present them in the issuers bundle.

I see. I am curious how big that is?

…

— Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAJY3C2QCOOWVP7JJHCTS3Y4JDPZAVCNFSM6AAAAABF2WWZEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSGA3TQNRVHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>