# 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](/brc/wallet/0100.md).
* **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

BRC-103 uses the certificate formats, signature preimage, field encryption rules, master keyrings, and verifier keyrings defined by [BRC-52](/brc/peer-to-peer/0052.md). BRC-103 messages MUST NOT define an alternate certificate binary layout or alternate certificate signature preimage.

When BRC-103 carries a certificate in JSON, it carries a BRC-52 core certificate plus any applicable BRC-52 unsigned extension members, such as a verifier `keyring`. When BRC-103 carries a certificate in binary, it carries either BRC-52 `CertificateBinary` or a BRC-52 length-prefixed certificate-with-keyring envelope, as required by the surrounding message encoding.

### 4.2 Master Certificate

A **Master Certificate** is a BRC-52 core certificate plus a complete master keyring. It is normally stored by the wallet and is not sent to ordinary verifiers.

### 4.3 Verifiable Certificate

A **Verifiable Certificate** is derived from a master certificate and contains the BRC-52 core certificate plus a verifier-specific `keyring`. It still contains all encrypted fields so the verifier can check the certifier signature over the complete certificate, but it only includes field revelation keys for fields disclosed to that verifier.

### 4.4 Selective Field Encryption

BRC-103 selective disclosure is the BRC-52 selective revelation process:

1. The holder keeps a master certificate whose master keyring can decrypt all fields.
2. For a verifier, the holder decrypts the selected field revelation keys from the master keyring.
3. The holder re-encrypts those field revelation keys for the verifier and includes them in the verifiable certificate `keyring`.

### 4.5 Creation and Verification Processes

Certificate creation, signature verification, field decryption, and revocation checks MUST follow BRC-52. The verifier MUST verify the BRC-52 core certificate signature before accepting any decrypted field and MUST treat a spent non-sentinel `revocationOutpoint` as revoked.

## 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hub.bsvblockchain.org/brc/peer-to-peer/0103.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.