Add a PSBT per-output field for BIP 353 DNSSEC Proofs

[TheBlueMatt]

When using BIP 353 for on-chain addresses (incl silent payments),
it is useful to be able to include DNSSEC proof information in
outputs of a PSBT, which we enable here by defining a standard
field for it.

[jonatack]

Suggested change

	| An RFC 9102 DNSSEC `Authentication Chain Data` without the `ExtSupportLifetime` field (i.e. a series of RFC 9102 `AuthenticationChain`s) providing a DNSSEC proof to a BIP 353 DNS TXT record.
	| An RFC 9102 DNSSEC <tt>Authentication Chain Data</tt> without the <tt>ExtSupportLifetime</tt> field (i.e. a series of RFC 9102 <tt>AuthenticationChain</tt>s) providing a DNSSEC proof to a BIP 353 DNS TXT record.

[TheBlueMatt]

It seems to render fine either way, no? The <> version makes reading the plaintext much more difficult.

[achow101]

backticks don't render as code formatting, if that was what you were trying to do. Otherwise, I'd suggest using single quotes here instead of backticks.

[TheBlueMatt]

Realized this doesn't actually work without the name itself, so force-pushed that in.

[murchandamus]

Seems reasonable. @achow101, could you take a look please?

[achow101]

A link to the relevant RFC and section would be nice. But I find the RFC to be a bit vague here, so it might be easier to just write out what the serialization is supposed to be?

[achow101]

Since a single RRSIG can cover multiple RRs in the response, those RRs would need to be included in order to verify the signature. Does there need to be any specific handling and/or disallowing of such RRSets?

RRSIG also specifies a validity period for the signature. How should validators deal with those, especially since a PSBT can take a lot of time between updating and signing.

[TheBlueMatt]

A link to the relevant RFC and section would be nice.

You mean like an HTTP link?

But I find the RFC to be a bit vague here, so it might be easier to just write out what the serialization is supposed to be?

Not sure I can be much more accurate. Its basically just "a series of DNS records written out in DNS record format", but that's not exactly clear either...

Since a single RRSIG can cover multiple RRs in the response, those RRs would need to be included in order to verify the signature. Does there need to be any specific handling and/or disallowing of such RRSets?

Those would need to be included. I believe RFC 9102 is clear here - "In either case, the chain of RRsets MUST be accompanied by the full set of DNS records needed to authenticate the TLSA record set or its denial of existence up the DNS hierarchy to either the root zone or another trust anchor mutually configured by the TLS server and client."

RRSIG also specifies a validity period for the signature. How should validators deal with those, especially since a PSBT can take a lot of time between updating and signing.

That's deliberately left undefined here. The library I wrote exposes the proof validity start and end time as well as the TTL, but I imagine most users will ignore the TTL, and probably should, only paying attention to the proof validity start and end times.

[achow101]

Realized this doesn't actually work without the name itself, so force-pushed that in.

Wouldn't the Authentication Chain already contain the name since it has the record itself?

[achow101]

It'd be nice to just go in order... the next field available is 0x09.

[TheBlueMatt]

I liked the DNS port (53) :)
But I can do whatever, it doesn't matter...

[bigspider]

As I understand it, the semantic meaning is to provide a form of authentication of the output, in order to establish "this output belongs to a certain identity".

Perhaps it would be worth having a generic keytype called maybe PSBT_OUT_AUTHENTICATION_PROOF, and use the keydata to label the type of authentication, for example reserving keydata = 0x00 for the DNSSEC_PROOF as per the rest of the specs, and leaving the meaning undefined for any other keydata.
It costs a single additional byte per output, but avoids having to define a new keytype if/when other approaches to the authentication of outputs are proposed.

[TheBlueMatt]

Wouldn't the Authentication Chain already contain the name since it has the record itself?

Technically yes, but the Authentication Chain is just a list of records "in no particular order", which makes it somewhat annoying to figure out the name. If you have a wildcard it could even be impossible.

[achow101]

ACK b0d5a07

[murchandamus]

Looks good to me, merging this as it only adds specification for how to handle PSBTs and adjusts "human-readable address" to "human-readable name in the BIP text. Also has sign-off from BIP 174 author.

[jonatack]

Post-merge lgtm