TLSNotary signatures

[parkan]

TLSNotary [paper] allows you to prove that a particular TLS/SSL web resource was retrieved at a particular point in time. This might be a good solution for certifying imports of data from existing HTTPS APIs, without involving the 3rd party: we'd retrieve the remote page, attach its contents as a translated_from and use the TLSNotary in place of signature.

Key exchange is handled entirely by normal TLS mechanisms. Of course, the downside is that the remote server has to be up -- we could backup the keys into our infrastructure, but that creates a game o trust whack-a-mole.

[vyzo]

Not sure it's worth the complexity -- what do we gain by it?

[parkan]

The main thing this gets us is deferring to the authority of a party that is not an active system participant, without having to fabricate a cryptographic identity for them or signing anything ourselves. We've generally been talking about it as us "signing things on someone else's behalf", but that's actually quite awkward from the perspective of authority, agency, transfer of control, etc. This is a simple "they said this, here's proof".

I agree that this is a potentially complex/brittle piece, though -- thus [ENHANCEMENT]

[parkan]

Update: we actually have some inbound interest on this from a dApp developer: basically they want us to capture an external API/scraped resource and store it in a namespace. This doesn't require TLSNotary per se, but it nicely closes the trust loop, where we can present a TLSNotary receipt as proof of having pulled down the remote page.

[parkan]

Useful for some special projects, keeping this around