Cryptography Capabilities — Xferity OpenPGP, Certificates, and Key Management

Cryptography Capabilities

This page is the explicit, structured reference for Xferity’s cryptography capabilities.

OpenPGP operations

Xferity supports the full OpenPGP operation set as part of file transfer flows:

Encryption — encrypt payload before upload to partner
Decryption — decrypt payload after download from partner
Signing — sign payload before upload (detached or inline)
Signature verification — verify partner signature after download
Combined operations — encrypt-and-sign, decrypt-and-verify in one step

OpenPGP execution providers

Xferity supports three provider modes:

Mode	Description
`gopenpgp`	Native Go OpenPGP library — no external binary required
`gnupg`	GnuPG binary — full GnuPG pipeline for enterprise key structures
`auto`	Try native first; fall back to GnuPG only for named compatibility cases

Auto fallback behavior

auto is not a general retry. Fallback only triggers for the named compatibility case compat_enterprise_key_structure.

This covers:

signing-capable key resolution failures
primary key stub or offline primary key layouts
partial secret-key export structures
Workday-style enterprise partner key patterns

Fallback does not trigger for:

missing files
missing keys
wrong passphrase
bad signatures
permission or path errors

Isolated GnuPG execution

When GnuPG is used, Xferity creates an isolated temporary GnuPG home per operation:

no shared keyring between flows or jobs
no GPG agent side effects
no dependency on host user profiles
cleanup failure is surfaced via structured log fields (cleanup_status)

Crypto observability

Every crypto operation emits:

provider — which provider was used
mode — gopenpgp, gnupg, or auto
fallback_used — whether fallback occurred
fallback_reason — why fallback was triggered
fallback_subreason — detailed reason
cleanup_status — whether GnuPG home cleanup succeeded

Certificate (X.509) inventory

Xferity manages X.509 certificates as first-class assets:

Import — load existing certificates from PEM or DER
Generate — create self-signed certificates for AS2 exchange
Store — persist certificates in Postgres backend
Bind — assign certificates to partner roles (AS2 signing, encryption, HTTPS trust)
Expiry tracking — posture engine finds approaching or expired certificates
Capability validation — verify that a certificate supports its intended role
Audit history — all lifecycle changes are recorded

AS2 certificate roles

For AS2 partners, separate certificates can be bound to:

signing — signing outbound messages
verification — verifying inbound signatures
encryption — encrypting outbound messages
decryption — decrypting inbound messages
https_client — mutual TLS client certificate
https_server — HTTPS server trust anchor

PGP Key inventory

Xferity manages PGP keys as first-class assets:

Import — load existing keys (public or private) from armored ASC
Store — persist keys in Postgres backend with capability metadata
Capability verification — verify that a key supports its intended operations (encryption, signing)
Bind — assign keys to partner roles
Audit index — all key usage is indexed for investigation

PGP key capability model

When a key is imported, Xferity evaluates:

whether the key can encrypt
whether the key can sign
whether subkey structure is compatible with native provider or requires GnuPG
enterprise key structure classification

Partner Crypto Policy

For every partner, Xferity exposes a unified Partner Crypto Policy view:

All configured and bound roles in one view
Shows which roles have certificates or keys bound
Shows which roles are missing or have expiry issues
Covers TLS, AS2, and PGP roles in one place

This is the operator’s single source of truth for partner-level crypto posture.

Flow Crypto Requirements

Every flow exposes Flow Crypto Requirements:

Derived from the canonical FlowRoleSpecs() model
The same model is used by: config validation, UI policy views, runtime preflight, runtime crypto resolution
No way for the UI to show a policy different from what the runtime enforces

Runtime preflight validates that all required crypto assets are resolved before the flow executes.

Runtime crypto resolution

At flow execution time, the crypto resolver:

reads flow PGP configuration
applies FlowRoleSpecs() to determine required roles
resolves concrete crypto assets from inventory or inline config
validates that assets meet role requirements
makes resolved assets available to the transport execution

A missing or incorrectly bound asset causes a preflight failure — the flow does not begin execution.

Secrets redaction in crypto logs

The crypto subsystem avoids logging:

passphrases
key material
raw GnuPG stderr when it may contain sensitive values

Logs use structured fields and sanitized output summaries instead.

Capability summary

Xferity cryptography capabilities include:

OpenPGP encryption, decryption, signing, verification
Native Go provider (gopenpgp) — no binary dependency
GnuPG provider — full GnuPG pipeline
Controlled auto-fallback for enterprise key structures
Isolated GnuPG home per operation — no shared keyring
Structured crypto observability fields on every operation
X.509 certificate inventory (import, generate, store, bind, expiry tracking)
AS2 certificate roles: signing, verification, encryption, decryption, HTTPS trust
PGP Key inventory (import, store, capability verify, bind)
Partner Crypto Policy: unified per-partner role view
Flow Crypto Requirements: derived from canonical role model
Runtime crypto resolution with preflight validation
Secrets redaction in all crypto log paths