# Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol

Ty Everett (<ty@projectbabbage.com>)

## 1. Abstract

This document specifies a **peer-to-peer** protocol for **mutual authentication** and **signed data exchange**. The protocol uses **certificates**, **nonce-based challenges**, and **digital signatures** to protect the integrity and authenticity of messages, enabling:

* **Selective field disclosure** of certificates without revealing unnecessary information.
* **Highly extensible message types**, suitable for a variety of use cases such as transaction coordination, identity verification, and arbitrary data sharing.
* **Interchangeable transport layers**, which can be HTTP, NFC, WebSockets, or any mechanism supporting bidirectional message exchange.

The specification provides a standard approach for issuance, storage, retrieval, and verification of identity certificates, as well as the end-to-end handshake and messaging protocols between peers.

## 2. Motivation

Secure interactions among different wallets and services are critical. These interactions typically require:

* **Proving identity** in a privacy-preserving manner, possibly revealing only some data fields (e.g. “I am over 18” without revealing full date of birth).
* **Ensuring that both parties are authenticated** to each other (mutual authentication), reducing the risk of man-in-the-middle or impersonation attacks.

A standard protocol for **mutual authentication** and **certificate exchange** addresses these needs and fosters interoperability between applications, wallets, and vendors.

## 3. Terminology & Definitions

* **Wallet**: An interface or application managing the user’s keys, capable of signing, encrypting, and decrypting data in conformance with [BRC-100](https://bsv.brc.dev/wallet/0100).
* **Certificate**: A data structure that attests to certain user attributes, signed by a **certifier**.
* **Master Certificate**: A special form of certificate that has been encrypted field-by-field, each with a unique symmetric key, stored in an internal keyring.
* **Verifiable Certificate**: A certificate derived from a master certificate, revealing keys for only the fields a particular verifier may see.
* **Peer**: A party participating in communication, using the protocol to exchange messages.
* **Session**: The state tracking an authenticated channel between two peers.
* **Nonce**: A random value used once within a cryptographic exchange to ensure freshness and avoid replay attacks.
* **Signature**: A digital signature produced by the user’s or certifier’s private key.
* **Transport**: The underlying communication medium that relays messages between peers.

## 4. Certificates and Selective Disclosure

### 4.1 Certificate Format

Certificates are stored and transmitted in a **binary format** to optimize size and parsing consistency. We specify each field in table form, together with how it is *conventionally* represented when not in binary. The binary format is always used for signing and verification, but the conventions are useful for human readability. A certificate has the following primary fields:

| Field Name         | Type                             | Description                                                                           |
| ------------------ | -------------------------------- | ------------------------------------------------------------------------------------- |
| Type               | 32-byte (base64) string          | Certificate category identifier (e.g., unique type associated with “social handles”). |
| SerialNumber       | 32-byte (base64) string          | Uniquely identifies this certificate instance.                                        |
| Subject            | 33-byte compressed pubkey (hex)  | The wallet’s (subject’s) public key.                                                  |
| Certifier          | 33-byte compressed pubkey (hex)  | The certifier's public identity key.                                                  |
| RevocationOutpoint | 32-byte TXID + varint output idx | On-chain reference to track revocation (if spent, revoked).                           |
| Fields             | Varint count + repeated pairs    | Pairs of: \<fieldNameLength, fieldName, fieldValueLength, fieldValue>                 |
| Signature          | Varint length + bytes            | Certifier’s signature over all fields (excluding itself).                             |

**Important**: Each certificate field is encrypted with a field-specific key. The encrypted version is signed.

### 4.2 Master Certificate

A **Master Certificate** includes a **master keyring**. Each field in the certificate is encrypted with a unique symmetric key. Those keys, in turn, are encrypted for the certificate holder (subject). Hence, a master certificate is able to decrypt any of its own fields locally but can selectively re-encrypt only some fields for a verifier.

### 4.3 Verifiable Certificate

A **Verifiable Certificate** is derived from a master certificate. It still contains all fields in ciphertext form (so that signatures can be verified) but also includes a “verifier-specific keyring.” For fields the subject wishes to disclose, the subject decrypts the corresponding symmetric key from the master keyring and re-encrypts it for the verifier. Consequently, the verifier can decrypt only those chosen fields.

### 4.4 Selective Field Encryption

1. **Master Keyring Generation**
   * For each field `f`, create a random symmetric key `K_f`.
   * Encrypt the field’s plaintext using `K_f`, store as `Fields[f] = E(K_f, fPlaintext)`.
   * After all fields are encrypted, the certifier signs the assembled certificate, comprising all encrypted fields.
   * The certifier can then encrypt the key `K_f` for the subject’s own identity: `EncryptedKey_f -> E_subject(K_f)`, the subject can store in the master keyring.
2. **Disclosure to a Verifier**
   * When selectively disclosing field `f`, the subject decrypts `EncryptedKey_f`, obtains `K_f`, and re-encrypts `K_f` with the verifier’s identity key, producing `K_f_for_verifier`.
   * The subject includes `K_f_for_verifier` in the **verifier’s** keyring for that verifiable certificate.

### 4.5 Creation and Verification Processes

**Certificate Creation**

1. **User** (subject) or **certifier** forms certificate fields (including `Type`, `SerialNumber`, etc.).
2. Each field is encrypted.
3. The certifier signs the certificate data.

**Certificate Verification**

1. A party verifying a certificate reassembles the binary structure.
2. Checks the signature against the “signature preimage” (all primary certificate fields except the signature itself, and not including their verifier keyring).
3. Considers the `RevocationOutpoint` to confirm the certificate is not on-chain revoked (if it is not 36 zero bytes).

**Selective Disclosure**

* The subject issues a **Verifiable Certificate** containing:
  * Original field ciphertext.
  * Re-encrypted field keys for fields to reveal.
  * The certifier’s signature.

The verifier can decrypt each revealed field’s ciphertext with the provided key, verifying the signature across the entire certificate to ensure authenticity.

## 5. Peer-to-Peer Messaging Overview

### 5.1 Message Types

Each message exchanged between peers contains:

* **Version**: The protocol version string (e.g. “0.1”).
* **MessageType**: One of: `initialRequest`, `initialResponse`, `certificateRequest`, `certificateResponse`, `general`.
* **IdentityKey**: Sender’s public key.
* **Nonce Fields**: For challenge–response patterns (e.g. `yourNonce`, `initialNonce`).
* **Signature**: A digital signature by the sender’s private key over the relevant content.
* **Optional Data**:
  * **Certificates**: A list of verifiable certificates.
  * **RequestedCertificates**: A set specifying certifiers and certificate types with fields.
  * **Payload**: Arbitrary data included in `general` messages.

### 5.2 Transports

The protocol does **not** mandate a specific transport. Any medium that can:

1. **Deliver messages** in a reliable or semi-reliable manner, and
2. **Allow receiving** peer messages,

can be used. HTTP requests, WebSockets, Bluetooth, NFC, or local function calls are all valid.

### 5.3 Session & Nonce Management

A peer typically maintains a **session** record containing:

* **isAuthenticated**: Whether the peer is recognized as fully authenticated.
* **sessionNonce**: A locally generated random 256-bit value.
* **peerNonce**: The peer’s random 256-bit value.
* **peerIdentityKey**: The peer’s public identity key.

A session is created or updated whenever a handshake starts or completes. Nonces and signatures ensure that replaying old messages fails.

## 6. Mutual Authentication Protocol Flow

### 6.1 Handshake Sequence

The handshake typically has **two** messages in the simplest form: an `initialRequest` and an `initialResponse`.

1. **initialRequest**
   * Sender (A) generates a random nonce (A\_Nonce).
   * A sends `initialRequest` containing:
     * `messageType = "initialRequest"`
     * `identityKey = A_publicKey`
     * `initialNonce = A_Nonce`
     * Optionally, a `requestedCertificates` set if A wants B’s certificates.
2. **initialResponse**
   * Receiver (B) verifies the request, creates its own random nonce (B\_Nonce).
   * B sends `initialResponse` containing:
     * `messageType = "initialResponse"`
     * `identityKey = B_publicKey`
     * `initialNonce = B_Nonce` (its own newly created nonce)
     * `yourNonce = A_Nonce` (echoing A’s nonce)
     * Optionally, any certificates B wants to share right away.
     * A **signature** verifying B truly created this message.
   * When A receives this `initialResponse`, it verifies B’s authenticity via the signature over `(A_Nonce + B_Nonce)`, marking the session as authenticated.

### 6.2 Nonce Creation & Verification

* Each party uses a cryptographically secure random generator for the nonce (e.g., 32 bytes).
* The verifying side must ensure the nonce is matched or “echoed” in subsequent messages.
* Optionally, one may use an **HMAC-based** approach to bind nonces to their key, avoiding the need to keep track of all nonces that they created.

### 6.3 Message Signing & Verification

**Signature** ensures authenticity. The signing steps:

1. Collect relevant data from the message. For instance, a `general` message might sign the raw `payload` array plus ephemeral fields such as `(requestNonce + peerNonce)` to bind the message to the session.
2. Use the BKDS-based BRC-100 signature creation and verification mechanisms.
3. Place the resulting signature in the message’s `signature` field.

**Verification**:

1. Recompute the same message preimage.
2. Verify the signature with the alleged **identityKey**.
3. If valid, accept the message. Otherwise, reject or treat as an error.

### 6.4 Certificate Requests & Responses

After or during handshake, a peer may request:

* **`certificateRequest`**: “Please provide certificate(s) of type(s) X, issued by Y (or Z).”
* **`certificateResponse`**: Peer responds by attaching a list of **verifiable certificates** that match the requested type and certifier.

**Request**:

* Contains a `RequestedCertificates` structure:
  * `certifiers`: array of public keys representing permissible certifiers.
  * `types`: a dictionary of `certificateTypeID -> array of fields requested`.

**Response**:

* Contains an array of **VerifiableCertificates**, each possibly containing:
  * Encrypted fields.
  * Re-encrypted keys for the requester.
  * The certifier’s signature.

### 6.5 General Message Exchange

Once both sides have completed the handshake (i.e. set `isAuthenticated=true` in their session records), they can exchange arbitrary data:

* **`messageType = "general"`**
* `payload` can be any binary or text data encoded consistently.
* The message includes a fresh `nonce` and references the peer’s `nonce` for ephemeral binding to the session.
* The `signature` covers the payload plus nonces.

## 7. Error Handling & Security Considerations

1. **Replay Attacks**:
   * Nonces must be unique and used once. The receiver ensures that the same nonce is not accepted more than once.
2. **Man-in-the-Middle**:
   * The handshake uses mutual signature verification. If a middle party tries to modify data, the signature verification fails.
3. **Certificate Revocation**:
   * The `revocationOutpoint` can be polled or monitored in the ledger to confirm it has not been spent. A spent outpoint implies the certificate is revoked Non-zero outpoints must be checked.
4. **Selective Disclosure**:
   * Properly encrypt fields with randomly derived keys.
   * Re-encrypt those keys only for intended verifiers.
5. **Privilege Escalation**:
   * Carefully manage session state to ensure a partially authenticated session does not gain privileges.
6. **Transport Security**:
   * Although each message is authenticated, transport-level encryption (e.g. TLS) can still be beneficial, especially to hide message lengths or frequencies.
   * This protocol does not encrypt any data by itself.

***

## 8. Implementation Notes

* **Data Types**:
  * Nonces are 32 bytes.
  * Public keys are 33 bytes in compressed DER format.
  * Certificate fields may vary in size, so a length-prefix technique (varint) is standard.
* **Storage**:
  * A wallet may store certificates in a local database.
  * A session manager maps `sessionNonce` and `peerIdentityKey` to a single in-memory record.

## 9. Acknowledgments

This protocol is heavily inspired by existing cryptographic handshake approaches (SSH, TLS) and identity-certificate systems (X.509), adapted for a BSV-based environment. Contributors within the ecosystem have refined these ideas to align with BKDS, peer-to-peer exchange, selective disclosure, and other needs.