PastWipe S.L.

Marbella Spain info@pastwipe.com

The Reputation Security Protocol (RepSec) defines a lightweight, extensible, and secure method for exchanging digital reputation and security-state information across the Internet. RepSec follows the design philosophy of SMTP (simplicity) and SNMP (extensibility). Entities can register, verify, remove, and audit reputation data in an interoperable and standardized way.

Current approaches to reputation and security metadata are fragmented and proprietary. RepSec provides a standardized protocol for secure, interoperable exchange of this information. The protocol is designed to be simple to implement, secure by default, and extensible for future needs, drawing on SMTP's command/response model and SNMP's extensible object framework. Goals: - Simple, JSON-based message exchange
- Secure by default (TLS mandatory)
- Extensible command set and object schemas
- Open and free to implement

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in and when, and only when, they appear in all capitals, as shown here.

RepSec uses a client/server request–response model. Transport: TCP with mandatory TLS (TLS 1.2 or later; TLS 1.3 SHOULD be supported).
Port: TBD by IANA (proposed: 4655).
Encoding: UTF-8 JSON for commands and responses.
Status Codes: Numeric, modeled after SMTP.

Client: entity initiating RepSec commands.
Server: entity providing RepSec services.
Entity: subject of registration (domain, IP, userID, organization, etc.).
Message: JSON-encoded RepSec command or response.
Extension: optional module that defines new commands and/or schemas.

All RepSec traffic MUST be transmitted over TLS. Servers SHOULD support TLS 1.3. Messages MUST be encoded as UTF-8 JSON objects. If compression is used, it MUST be negotiated at the TLS layer; TLS record compression is NOT RECOMMENDED.

The minimum interoperable command set is shown below. Commands are JSON objects with a "command" field and command-specific parameters.

Registers an entity with RepSec.

Verifies authenticity of registered data.

Removes registered data.

Retrieves entity history (audit log).

Checks server availability and round-trip.

Responses MUST include a numeric status code and a human-readable message. Additional fields are allowed.

Example:

All RepSec sessions MUST use TLS with server authentication; mutual authentication via client certificates or token-based schemes is RECOMMENDED. Implementations MUST provide replay protection (e.g., timestamps and nonces) and SHOULD employ rate limiting and abuse detection. Privacy by design: servers MUST NOT expose unnecessary metadata and SHOULD minimize data retention.

RepSec supports extensions similar to SMTP EHLO and SNMP MIBs. Extensions MAY define new commands and/or JSON schemas (RepSec Object Definitions). Servers SHOULD advertise supported extensions during capability discovery (future work).

IANA is requested to assign a new TCP port for RepSec (suggested: 4655) and to create a new "RepSec Parameters" registry containing: - Registered RepSec Commands (Specification Required)
- Registered RepSec Extensions (Specification Required)
- Status Codes (Standards Action)

This specification is made available under the IETF Trust Legal Provisions Relating to IETF Documents (TLP). Implementations may be licensed under permissive or copyleft licenses (e.g., Apache-2.0, GPL/LGPL), provided interoperability with the open standard is maintained. "RepSec" may be used as a trademark to indicate interoperable implementations.

RepSec was inspired by the simplicity of SMTP and the extensibility of SNMP, with the goal of creating an open, non-proprietary Internet standard for reputation security.