Requirements for Gordian UR Signing & Auth Discussions

[ChristopherA]

This thread is for our initial discussion of requirements (and hopefully soon a straw-man proposal) for a QR/UR-based crypto-request, that is suitable and safe for purposes such as auth requests like sign-in-with-Bitcoin, signature requests for other kinds of messages, signing of hashes by constrained devices & silicon chips, and compatibility/update for specs for PSBT signing requests.

[ChristopherA]

Potential Requirement: Various options for partial failure. For instance, a constrained signing device should be able to respond "I can't parse that to hash it, but give me a hash of it with our session id (already authenticated and trust out-of-band) and I'll sign it. This is a common pattern with JavaCard devices.

(if you like this requirement, upvote this post)

[simonratner]

For ed25519 signature, there is no "sign a hash" operation, the original message is required to generate a valid signature. In that case, instead of providing a hash to sign, the verifier could provide the original message plus a digest with some key (e.g. hmac-sha-256) to ensure the same message has been parsed/verified/approved by user.
Also applies to this, except when there is already full trust and a secure channel between verifier and controller, a digest isn't needed.

[ChristopherA]

Potential Requirement: The controller (the secure element or device with private keys) fully trusts the verifier (the secure UX) out-of-band, and the controller has no state. In this case, the verifier gives the controller a hash, some sig hints (kind of sig, maybe contributes to nonce, and what master key ID and path. Or any key or any path) the controller returns the signature, key ID, path, and maybe a nonce exfiltration proof, or an error (It doesn’t have that key).

[ChristopherA]

Potential Requirement: I'd like to see that a signing requests can optionally include Anti-Exfiltration[https://blog.blockstream.com/anti-exfil-stopping-key-exfiltration/] data, and that signed responses can optionally return proofs (which may be used in the future for other kinds of zk-proofs that the requests were properly performed).

cc/ @apoelstra @jonasnick

[ChristopherA]

Potential Requirement: The verifier (the trusted UX device, which may or may not have private keys, but does have trusted UX to user, and also can parse and hash) trusts a requesting device completely (out-of-band). The requestor sends something to sign, some key hints, maybe some metadata. The verifier parses what is being requested to sign, confirms with user to sign, hashes unsigned message, and either signs or passes the hash to a controller device to sign.

[ChristopherA]

Potential Requirement: Ability for devices (controller, verifier, requester) to establish persistent TOFU (trust on first use) pairing with each other, and be able present that authentication in-band with requests.

[ChristopherA]

What other kinds of pairing? ECDH? Public Key?

[ChristopherA]

There should probably also be TTL (time to live) for TOFU pairings.

[ChristopherA]

See also Wallet Connect 2.0 for changes on how pairing TTL has changed.

[ChristopherA]

We may want to investigate registering a specific SLIP-44 "coin-type" for use to generate unique TOFU and pairing public keys.

[simonratner]

Dual auth modes:

• controller and verifier A may have established trust out of band, so there is an existing high-trust channel for this or this
• controller may also want to sign requests from verifier B using an ad-hoc, time- or capability-limited channel

Example: a hardware signer (cold wallet, keycard, ...) has a permanent high trust pairing with its own companion phone app and is willing to be a blind signer for requests from that channel; same hardware signer may also want to sign requests from other verifiers (by other implementers) through a user-established pairing like TOFU, which may be time- or capability-limited.

[ChristopherA]

Potential Requirements: We need be able to handle key derivation hints where:

• The requestor does not care what key fingerprint, or path is signed, but needs the response to say what was used.
• The requestor does care that a specific key fingerprint is used, and offers a hint as to path requested (for instance cosigning `48, segwit, account # 0 ), but the signing device may choose to sign with another path (for instance, a particular account is TOFU'ed to another device, and to prevent xpub reuse, is assigning a different child key such as account # 2.
• The requestor needs the key fingerprint and path to match before signing.

[ChristopherA]

Potential Requirement: Current request techniques only work for single-sig. It would be great to support BIP-322 signatures, or at least spec to future proof, such that any P2SH or more advanced style signature can also be requested.

[ChristopherA]

Potential Requirement: Support requests for Schnorr signatures of the unsigned messages payload rather than a ECDH signature.

[ChristopherA]

Potential Requirement: Possibly sign with with partial taproot tree?

[ChristopherA]

Potential Requirement: Compatibility option for signing old legacy bitcoin messages.

[ChristopherA]

Potential Requirement: Some type of explicit "proof purpose", that verifiers with trusted UX can relay to users. for instance, i.e. sign a transaction, sign for an auth, sign for capability, etc.

[ChristopherA]

Potential Requirement: Future proof to allow for requests like "sign a phase 1 FROST quorum initiation request", or "Use the key for a non-signature zk-proof that requires a private key".

cc/ @jesseposner

[ChristopherA]

Potential Requirement: Simple uses cases should not require more than 1 round trip (request, response).

[ChristopherA]

Potential Requirement: Good error cases, including ability to resolve and continue previous session.

[simonratner]

Related: ability to hand-off to another controller (i.e. "I can't sign it with the key you ask, but I know this other controller that can").

[ChristopherA]

Potential Requirement: When signing auths (or capabilities) there should be a requirement for TTL (time-to-live). However, many signers don't have a clock. How can we do that?

Some (say the Proxy ring) the controller (the ring) doesn't have a clock, but the verifier does (a mobile phone).

[ChristopherA]

See also Wallet Connect 2.0 changes for TTL.

[ChristopherA]

Potential Requirement: Most controller devices (have private keys) today have no or very limited state. Others have counters that can increment, or sessions ids, or can have a lot of state. We need to design for this range, and error out appropriately, or be able delegate to a higher trusted verifier device, when state is required.

[ChristopherA]

Potential Requirement: Not all verifiers (may or may not have private keys) have network access. When validation of a transaction or other parsable messages requires network access to fully validate, but partial validation is possible, we need API and UX guidance as to what should be told the user or the requester.

[ChristopherA]

Sign-in-with-Ethereum variants have a concept of domain binding, which they can do because all wallets are connected to the internet, and usually have some way of validating a URL from its https certificate. Our airgapped wallets can't do that. a) some can, so what do we do? b) those that can't, what can they do?

[ChristopherA]

Potential Requirement: It should be possible to create request to participate a multisig, which means presentation of an public key to form a descriptor, which likely should signed by the private key to demonstrate possession of the private key. Likely optional nonces should also be incorporated, so that some device-in-the-middle attacks can be mitigated.

[simonratner]

This means ability to reference a previously presented public key in a signing request. Or alternatively, for hd keys only, the public key could come with a key fingerprint and derivation path which can be reference by a future signing request (e.g. each multi-sig descriptor setup may use a newly derived key at a child path).

[ChristopherA]

Potential Requirement: Though there is not a desire to try to be compatible with Wallet Connect and current Sign-In with Ethereum, we would like to future proof in case other coins (in particular other UTXO-style coins like Monero or Chia) want to join in. Wallet Connect 2.0 tries to be both coin and chain agnostic

[ChristopherA]

Potential Requirements: We have to avoid replay attacks, which requires special handing of nonces.

[ChristopherA]

Our first virtual meeting on this topic will be this Friday, February 24, at 10am PT via Zoom

If you are not already in the Signal group, you can invite yourself

[ChristopherA]

Potential Requirement: Prevent key reuse, support key rotation. One of the biggest problems with Sign-In-With-Ethereum is that they use the same keys for everything. In there, with BIP-32, keys in Bitcoin are not reused. However, given experience with Lightning and multisig, public keys for nodes and xpubs for different multisig accounts are often persistent, and thus key reuse will be come more and more of a problem. Also, there is no way to rotate a Lightning node address.

[ChristopherA]

One potential solution for this is to find other ways to leverage BIP-32, or other key derivation techniques, to create derived child keys. The address of child keys of a parent could be deterministic yet unique (say using a partial hash), preventing reuse. Verification could confirms the parent's pubic key matches the signed child private key, thus allowing key rotation.

[simonratner]

Definitions

• requester: relying party that made the signing request
• verifier: has trusted interface to the user, able to verify that message being signed matches user intent
• controller: has control of private key material needed for signing

(feel free to incorporate at top level and delete this)