Compendium

Cryptography / Key-Handling / Secret-Management DSLs Family Index

15 min read

Cryptography / Key-Handling / Secret-Management DSLs Family Index

type: language-family-index family: cryptography-keys languages_catalogued: 32 tags: [language-reference, family-index, cryptography-keys, openpgp, x509, pkcs, pkcs11, kms, hsm, sops, age, vault, sigstore, slsa, in-toto, tuf, kmip, tpm]

Cryptography / Key-Handling / Secret-Management — Family Index

Family overview

This family catalogues the textual (and a few binary-but-DSL-shaped) languages used to describe cryptographic material itself: how keys, certificates, encrypted payloads, secret bundles, HSM operations, and key-management policies are represented, exchanged, and governed. It sits one layer below the identity-auth-policy family — authorization DSLs decide who can do what, but the formats here decide what the cryptographic object actually is. The defining problem these languages all confront is the algorithm-agility / longevity tension: cryptographic primitives have a half-life of 10–25 years, but the formats that wrap them (PEM blocks, X.509 ASN.1, OpenPGP packets, PKCS#12 bundles) must persist across multiple generations of primitives without re-issuing every certificate, keyring, or signed message. The result is a layered cake of structure (DER/ASN.1, PEM armouring, packet sequences, CBOR) on top of primitive identifiers (OIDs, named curves, JOSE alg strings, OpenPGP algorithm IDs) on top of raw bytes.

The 2024 watershed event is RFC 9580 (“OpenPGP”, July 2024), which obsoletes RFC 4880 (2007) and the related Camellia/ECC extensions, introducing OpenPGP v6 with new SEIPDv2 (AEAD) packets, Argon2 string-to-key, X25519/X448/Ed25519/Ed448 native packets, and a re-thought key fingerprint format. RFC 9580 split the implementer community: GnuPG and a few others backed the parallel LibrePGP draft (a less-disruptive refresh of 4880), while Sequoia, RPM/dnf, Thunderbird, ProtonMail and most of the Rust/Go ecosystem moved to RFC 9580. This is the first true fork in OpenPGP since 1998 and remains unresolved as of May 2026.

The secrets-management ecosystem matured in parallel along two axes: encrypt-at-rest tools for GitOps (Ansible Vault, SOPS, age) and dynamic-secrets brokers (HashiCorp Vault, cloud KMS). SOPS — originally a Mozilla project, donated to the CNCF Sandbox in 2023 under the getsops.io banner with current release v3.12.x (March 2026) — became the de facto GitOps secret-encryption layer, encrypting YAML/JSON/ENV files in place with per-field encryption against AWS KMS, GCP KMS, Azure Key Vault, age, or PGP recipients. age (Filippo Valsorda + Ben Cox, currently v1.3.x) is its minimalist counterpart: an explicit, X25519-based, no-options-no-knobs replacement for GPG file encryption. HashiCorp Vault (current GA 1.20.x, June 2025) is the dynamic-secrets and KMS-broker complement, with its HCL path-capabilities policy DSL as the access-control surface.

Cloud KMS policy DSLs (AWS KMS Key Policies, Azure Key Vault access policies + RBAC, GCP Cloud KMS IAM Conditions with CEL) form the largest deployed slice. Above them sit vendor-neutral abstractions: OASIS KMIP 3.0 (Committee Specification Draft, Aug 2024; public review Sept 2024) is the long-awaited refresh of the 2010-era key-management protocol, and OASIS PKCS#11 v3.2 (Committee Specification Nov 2025, succeeding v3.1 from July 2023) modernises the HSM C API with post-quantum mechanisms. Stacked above everything is the supply-chain provenance wave: TUF 6.0 (March 2025), in-toto Attestation Framework, SLSA v1.1 (with v1.2 in flight), and Sigstore — Cosign v3.0 (released 2025) with keyless signing via Fulcio + Rekor — which together aim to retire long-lived signing keys altogether for OSS distribution. Adopters in 2024–2025 include Homebrew (May 2024), PyPI (Nov 2024), Maven Central (Jan 2025), and NVIDIA NGC model signing (July 2025).

In our deep library

None of these have standalone Tier-2 deep notes — they are formats and protocols rather than general-purpose programming languages.

Cross-reference siblings:

  • identity-auth-policy — JOSE family (JWS/JWE/JWA/JWK/JWKS), OAuth/OIDC, SAML, IAM JSON, Cedar, OPA Rego. JWK and JWS sit at the boundary; this note treats them as authorization-policy artefacts but they cross-list here as key representation formats.
  • api-description — X.509 and KMIP have OpenAPI/Smithy-style schema infrastructure (RFC 5280’s ASN.1 module, KMIP’s normative XML/JSON/TTLV encodings).
  • notation-spec — ASN.1 (the foundation under X.509, PKCS, KMIP), CBOR (under COSE/WebAuthn attestations), and the OID tree all live there as general-purpose notations.
  • build-devops — SLSA, in-toto, Sigstore/Cosign signing, and TUF metadata are all CI/CD-resident artefacts.
  • network-protocol-dsls — TLS 1.3 wire format, cipher-suite naming, and Mozilla SSL config recommendations.
  • config-and-dsl — Ansible Vault, OpenSSL .cnf, ssh_config/sshd_config are config-file DSLs that happen to carry secrets.
  • financial-regulatory / government-civictech — SBOM, supply-chain compliance, and FIPS-140 attestation flows overlap with SLSA + in-toto.

Tier 3 family table — PEM / DER / PKCS / X.509 layer

FormatFirst appearedOriginTypeStatus (2026)URL
PEM (Privacy-Enhanced Mail) encoding1993 (RFC 1421); generalised as RFC 7468 (April 2015)IETFASCII-armoured Base64-wrapped binary; -----BEGIN X----- … -----END X----- delimitersUniversal; RFC 7468 is the canonical “textual encodings of PKIX, PKCS, and CMS” spechttps://www.rfc-editor.org/rfc/rfc7468
DER (Distinguished Encoding Rules)1988 (X.690, ITU-T)ITU-T / ISOCanonical binary encoding of ASN.1; the bytes inside every PEM blockUniversal; underlies essentially every PKI formathttps://www.itu.int/rec/T-REC-X.690
ASN.1 modules (PKIX, PKCS)1984 (ASN.1); PKIX modules 1999+ITU-T / IETF PKIX WGSchema language for the binary structures encoded by DERUniversal; tooling: asn1c, openssl asn1parse, dumpasn1 — see notation-spechttps://www.itu.int/rec/T-REC-X.680
X.509 certificate format + RFC 5280 PKIX profile1988 (X.509v1); v3 in 1996; RFC 5280 in May 2008; updated by RFC 6818, RFC 8398, RFC 8399ITU-T / IETF PKIXDER/ASN.1 with named extensions (BasicConstraints, KeyUsage, EKU, SAN, AIA, CRLDP, etc.)Universal; Web PKI baseline; CA/B Forum Baseline Requirements layer on tophttps://www.rfc-editor.org/rfc/rfc5280
PKCS#1 (RSA Cryptography Standard)1991 (RSA Labs); RFC 8017 in Nov 2016RSA Laboratories → IETFRSA key + signature/encryption padding formats (PSS, OAEP)Active (RFC 8017 is current); RSA itself is being supplemented by ML-DSA / ML-KEMhttps://www.rfc-editor.org/rfc/rfc8017
PKCS#7 / CMS (Cryptographic Message Syntax)1993 (PKCS#7); RFC 5652 in Sept 2009RSA Labs → IETFSigned/enveloped/digested message containers; basis for S/MIME, code signingActive; the universal “signed blob” formathttps://www.rfc-editor.org/rfc/rfc5652
PKCS#8 (Private-Key Information Syntax)1993; RFC 5208 / 5958RSA Labs → IETFAlgorithm-agnostic private-key container; usually PEM-armoured as -----BEGIN PRIVATE KEY-----Universal; default modern private-key formathttps://www.rfc-editor.org/rfc/rfc5958
PKCS#10 (Certification Request Syntax / CSR)1998; RFC 2986 in Nov 2000RSA Labs → IETFThe CSR format every CA consumesUniversalhttps://www.rfc-editor.org/rfc/rfc2986
PKCS#11 v3.2 (Cryptographic Token Interface)1995 v1.0; v3.0 in June 2020; v3.1 in July 2023; v3.2 Committee Spec 01 in Nov 2025RSA Labs → OASIS PKCS 11 TCC API for HSMs/smart cards/TPMs; the CKM_* mechanism + CKA_* attribute namespace is itself a constrained DSLActive; v3.2 adds PQC mechanisms (ML-DSA, ML-KEM, SLH-DSA)https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.2/pkcs11-spec-v3.2.html
PKCS#12 / PFX (Personal Information Exchange)1996; RFC 7292 in July 2014RSA Labs → IETFEncrypted container bundling private key + cert chain (.p12/.pfx)Universal but ageing; legacy KDF (PKCS#12 v1) was retired by RFC 9579 (May 2024) recommending PBKDF2/PBMAC1https://www.rfc-editor.org/rfc/rfc7292
OpenSSL openssl.cnf / req/ca config DSL1998 (OpenSSL 0.9.x)OpenSSL projectINI-flavoured config with [sections], env-var expansion, and DN templates; drives openssl req, openssl ca, openssl x509 -extfileUniversal; the de facto “how do I generate a cert” DSLhttps://docs.openssl.org/master/man5/config/

Tier 3 family table — Email / file encryption (OpenPGP family)

FormatFirst appearedOriginTypeStatus (2026)URL
OpenPGP (RFC 9580, “crypto refresh”)RFC 9580 published July 2024 (obsoletes RFC 4880/5581/6637)IETF OpenPGP WGPacket-based binary format (ASCII-armourable); v6 keys + SEIPDv2 AEAD + Argon2 S2K + X25519/Ed25519 nativeCurrent standard; Sequoia 2.0+, RPM/dnf, Thunderbird, ProtonMail alignedhttps://www.rfc-editor.org/rfc/rfc9580.html
OpenPGP (RFC 4880, classic)RFC 4880 published Nov 2007IETF OpenPGP WGThe 2007 message format; still the deployed baseline for two decades of keyringsLegacy but ubiquitous; obsoleted by RFC 9580 in 2024 — most existing keys are still 4880-stylehttps://www.rfc-editor.org/rfc/rfc4880
LibrePGP draftDraft draft-koch-librepgp (2023–)GnuPG team (Werner Koch)Parallel evolution of 4880 — adopts AEAD/v5 differently than RFC 9580Active fork; GnuPG 2.4.x continues to track LibrePGP rather than RFC 9580; community split unresolvedhttps://datatracker.ietf.org/doc/draft-koch-librepgp/
GnuPG keyring format (pubring.kbx, trustdb.gpg)GnuPG 1.0 (1999); KBX added in 1.4 eraWerner Koch / GnuPGImplementation-specific on-disk container for OpenPGP secrets and trust stateActive; v2.4.x is the current GPG linehttps://www.gnupg.org/documentation/manuals/gnupg/
OpenSSH authorized_keys / known_hostsOpenSSH 1.0 (1999)OpenBSD projectLine-oriented mini-DSL: optional options, key type, base64 key, commentUniversal; the file format every Unix sysadmin learns firsthttps://man.openbsd.org/sshd.8#AUTHORIZED_KEYS_FILE_FORMAT
OpenSSH ssh_config / sshd_configOpenSSH 1.0 (1999)OpenBSD projectNewline-separated Keyword Value config DSL with Host/Match blocksUniversal; client + daemon configurationhttps://man.openbsd.org/ssh_config
OpenSSH certificate format (non-X.509)OpenSSH 5.4 (March 2010)OpenBSD projectLength-prefixed wire format independent of X.509; principals, validity window, critical options, extensionsActive; Smallstep/Vault/Teleport-style SSH CAs all emit thishttps://github.com/openssh/openssh-portable/blob/master/PROTOCOL.certkeys

Tier 3 family table — Secret management at rest

FormatFirst appearedOriginTypeStatus (2026)URL
Ansible Vault2014 (Ansible 1.5)Red Hat (Ansible)AES-256-CTR-encrypted YAML-compatible blocks (!vault | tag) with PBKDF2 key derivationActive; still the default secret format in Ansible playbookshttps://docs.ansible.com/ansible/latest/vault_guide/index.html
SOPS (Secrets OPerationS)2015 at Mozilla; donated to CNCF Sandbox in 2023; v3.12.2 in March 2026Mozilla → CNCF (getsops)Encrypts YAML/JSON/INI/ENV files in place, per-field; multiple KMS backends (AWS/GCP/Azure KMS, age, PGP)Very active; the de facto GitOps-secrets layer (Flux, ArgoCD integrations)https://getsops.io/
age encrypted file format2019 spec draft; v1.0 in March 2021; v1.3.x current (2025)Filippo Valsorda + Ben CoxX25519-based; explicit header with recipient stanzas; payload encrypted with ChaCha20-Poly1305Active; minimalist “no options” GPG replacementhttps://github.com/FiloSottile/age
age recipient strings (age1...)2019 with ageFilippo ValsordaBech32-encoded X25519 public-key identifier; pluggable backends use age1<plugin-name>... formActive; recipient stanza format is also the user-visible identity DSLhttps://age-encryption.org/v1
age-plugin protocolage 1.1 (2022)Filippo ValsordaStdio-protocol DSL for backend plugins (yubikey, sss, tpm, ledger, fido2-prf, passkey)Active; reference plugins: age-plugin-yubikey, age-plugin-tpm, age-plugin-fido2-hmachttps://github.com/FiloSottile/age/blob/main/doc/age-plugin.md

Tier 3 family table — Cloud KMS / HSM policy

FormatFirst appearedOriginTypeStatus (2026)URL
HashiCorp Vault policy HCLVault 0.1 (April 2015); HCL2 since Vault 0.10 (~2018); Vault 1.20.x current (June 2025)HashiCorp (now IBM)Path-capabilities DSL in HCL or JSON: path "secret/data/*" { capabilities = ["read","list"] }, with templated {{identity.entity.aliases.X.name}} blocksActive; cross-list with identity-auth-policyhttps://developer.hashicorp.com/vault/docs/concepts/policies
AWS KMS Key Policy JSONAWS KMS GA (Nov 2014)AWSIAM-style JSON: Statement[].Effect/Principal/Action/Resource/Condition; identical shape to IAM policies but resource-attachedActive; the primary access-control surface on a CMKhttps://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html
Azure Key Vault access policies / RBACKey Vault GA (Jan 2016); RBAC model GA (~2021)Microsoft AzureLegacy: per-vault access-policy objects with keys/secrets/certificates permission verbs. Modern: Azure RBAC role definitions on the vaultActive; Microsoft now recommends RBAC over legacy access policieshttps://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide
GCP Cloud KMS IAM Conditions (CEL)GA 2020Google CloudIAM bindings on KeyRings/CryptoKeys with CEL condition expressions (request.time, resource.name.startsWith(...))Active; CEL covered in identity-auth-policyhttps://cloud.google.com/iam/docs/conditions-overview
OASIS KMIP 3.0KMIP 1.0 (Oct 2010); 3.0 Committee Spec Draft Aug 23 2024, public review Sept 13 2024; expected OASIS Standard 2026OASIS KMIP TCVendor-neutral KMS protocol; TTLV/XML/JSON encodings; attribute language (Cryptographic Algorithm, Usage Mask, State) is itself a managed-object DSLEmerging; 3.0 supersedes 2.1 (Dec 2020); adds richer attribute model and PQC supporthttps://docs.oasis-open.org/kmip/kmip-spec/v3.0/csd01/kmip-spec-v3.0-csd01.html
TPM 2.0 command + attribute DSLTPM 2.0 first spec 2014; TPM 2.0 Library v185 in March 2026; ISO/IEC 11889:2015Trusted Computing GroupCommand codes (TPM_CC_*), object attributes (TPMA_OBJECT_*), algorithm IDs (TPM_ALG_*); tpm2-tools CLI is the user-facing surfaceActive; v185 adds Firmware-Limited Objectshttps://trustedcomputinggroup.org/resource/tpm-library-specification/
AD CS Certificate TemplateWindows Server 2003 R2 (2005)MicrosoftLDAP-stored template object (pKICertificateTemplate); per-template fields control issuance policy, EKU, subject constructionActive in enterprise PKI; well known after the ESC1–ESC15 escalation primitives published by SpecterOpshttps://learn.microsoft.com/en-us/windows-server/identity/ad-cs/manage-certificate-templates
Windows DPAPI / CNG blob formatDPAPI in Windows 2000 (2000); CNG in Windows Vista (2007)MicrosoftOpaque user/machine-scoped encrypted blobs; CNG providers expose key-storage namespace (Microsoft Software Key Storage Provider, Microsoft Smart Card Key Storage Provider)Active; underlies LSA Secrets, EFS, browser credential storeshttps://learn.microsoft.com/en-us/windows/win32/seccng/cng-portal

Tier 3 family table — Supply-chain signatures / provenance

FormatFirst appearedOriginTypeStatus (2026)URL
TLS 1.3 cipher suite namingTLS 1.3 (RFC 8446, Aug 2018)IETF TLS WGTiny DSL: TLS_<AEAD>_<HASH> (e.g. TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256); only 5 mandatory-to-implement suitesUniversal; deliberately drastically narrower than the TLS 1.2 cipher zoohttps://www.rfc-editor.org/rfc/rfc8446#section-B.4
Mozilla SSL Configuration Generator output2015 (ssl-config-generator)Mozilla FoundationGenerates nginx/apache/haproxy/etc configs from {Modern, Intermediate} profile (Old retired in tool v6.0)Active; Intermediate is the recommended default for general-purpose servershttps://ssl-config.mozilla.org/
JOSE family: JWS / JWE / JWA / JWK / JWKSRFCs 7515/7516/7517/7518/7519 (May 2015)IETF JOSE WGJSON-serialised crypto containers: compact/flattened/general; cross-list with identity-auth-policyUniversalhttps://datatracker.ietf.org/wg/jose/about/
JWK Thumbprint URI (RFC 9278)RFC 9278 (Aug 2022)IETFurn:ietf:params:oauth:jwk-thumbprint:sha-256:<base64url> — compact stable JWK identifier built on RFC 7638 thumbprintsStandard; used by OAuth attestation flows, sender-constrained tokenshttps://www.rfc-editor.org/rfc/rfc9278.html
TUF (The Update Framework)TUF 1.0 spec 2017; TUF 6.0 released 11 March 2025NYU Tandon (Justin Cappos) → CNCF GraduatedSigned metadata DSL: root.json, targets.json, snapshot.json, timestamp.json with delegations; threshold-signed JSONActive; underlies Notary v2, Sigstore root-of-trust, RubyGems, PyPI attestation distributionhttps://theupdateframework.io/
in-toto Attestation Frameworkin-toto Spec 0.9 (2019); Attestation Framework v1.0 (2023+)NYU / CNCF (in-toto graduated 2023)Statement + Predicate envelope: _type=https://in-toto.io/Statement/v1, predicateType=<URI>, signed with DSSE envelope (application/vnd.dev.sigstore.bundle+json)Active; the universal supply-chain attestation envelopehttps://github.com/in-toto/attestation
SLSA Provenance v1.0 / v1.1SLSA v1.0 GA April 2023; v1.1 Approved Spec (~2024); v1.2 in flightOpenSSF (Google-incubated)Build-provenance predicate (https://slsa.dev/provenance/v1) carried inside in-toto Statement: buildDefinition, runDetails, externalParametersActive; GitHub Actions, GitLab, Tekton Chains all emit ithttps://slsa.dev/spec/v1.0/provenance
DSSE (Dead Simple Signing Envelope)DSSE v1.0 (2021)Secure Systems Lab → in-toto/SigstoreJSON envelope binding payload + payloadType + signatures; replaced JWS for supply-chain use due to canonicalisation issuesActive; the underlying signature wrapper for all in-toto/SLSA/Sigstore bundleshttps://github.com/secure-systems-lab/dsse
Sigstore Cosign signature / bundleCosign 1.0 (June 2022); Cosign v3.0 (2025) with bundles default-onSigstore (Linux Foundation)Keyless signatures via Fulcio short-lived certs + Rekor transparency log; Cosign v3 unifies output as Sigstore bundle (.sig/.bundle)Active; adopters in 2024–25: Homebrew (May 2024), PyPI (Nov 2024), Maven Central (Jan 2025), NVIDIA NGC (Jul 2025)https://docs.sigstore.dev/cosign/signing/overview/
gitsign / git signing formatgitsign 0.1 (2022)SigstoreDrop-in gpg.format = x509 git signer using Sigstore keyless OIDC flow; signature stored as PKCS#7-in-PEMActivehttps://docs.sigstore.dev/cosign/signing/gitsign/

Notable threads

  • RFC 9580 vs LibrePGP — the first real OpenPGP fork. From RFC 4880 (Nov 2007) to RFC 9580 (July 2024) is 17 years, during which AEAD, Argon2, Curve25519, and SHA-3 all became standard everywhere except OpenPGP. RFC 9580 finally lands all of them — SEIPDv2 with OCB/GCM/EAX, Argon2 string-to-key, v6 keys with X25519/X448/Ed25519/Ed448 native packets, and a new key-fingerprint format. The catch: GnuPG (the dominant 4880 implementation) declined to follow and instead helped author LibrePGP, a parallel less-disruptive evolution. Sequoia, RPM/dnf signing, Thunderbird, ProtonMail, and most of the Rust/Go ecosystem moved to RFC 9580; GnuPG 2.4.x continues to track LibrePGP. As of May 2026 the community remains split — interop between RFC 9580 keyrings and GnuPG can fail silently, which is the first time that has been true since 1998.

  • SOPS + age as the GitOps secret duo. The combination of getsops/sops v3.12.x (March 2026) and age v1.3.x — both small, focused, well-audited tools — has displaced both Ansible Vault (too coarse-grained) and Vault-in-the-loop dynamic secrets (operationally heavy) for the most common case: “I have a YAML/JSON file with a few secret fields and I want to commit it to Git.” Per-field encryption means diffs stay reviewable, age recipients can be team-rotated cheaply, and Flux/ArgoCD ship native SOPS support so the decryption happens at deploy time inside the cluster. The 2023 CNCF Sandbox donation cemented getsops as the canonical fork after Mozilla’s withdrawal.

  • HashiCorp Vault HCL policies vs cloud KMS — the make-vs-buy axis. Vault 1.20.x (June 2025) is the IBM-stewarded current line and the dominant multi-cloud secrets+KMS broker, with its path-capability HCL DSL being a small but expressive policy language. Cloud-native shops typically pick AWS KMS / Azure Key Vault / GCP KMS instead — three non-interoperable JSON dialects (covered also in identity-auth-policy) — and accept lock-in for the operational simplicity. Vault’s value proposition is increasingly “the abstraction that hides which of the three you’re actually talking to.”

  • Sigstore + Cosign keyless signing is eating traditional GPG signing in OSS. The pattern: developer authenticates to Fulcio with an OIDC identity (GitHub/Google/Microsoft), Fulcio issues a 10-minute X.509 cert binding that identity to an ephemeral keypair, the developer signs, the signature event is logged in Rekor (a Merkle-tree transparency log), and the certificate expires. There is no long-lived signing key to lose, leak, or rotate. Cosign v3.0 (2025) made Sigstore bundles the default output format. Adoption in 2024–25 is genuinely broad: Homebrew formula signing (May 2024), PyPI’s attestations index (Nov 2024), Maven Central (Jan 2025), NVIDIA’s NGC model registry (July 2025). The gap remaining is Debian/RPM ecosystem — apt-get/yum still rely on long-lived OpenPGP signing keys, although rpm-sequoia is the bridge for Fedora/RHEL.

  • TUF + in-toto + SLSA as the supply-chain trifecta. Each layer answers a different question. TUF (6.0, March 2025) answers “how do clients securely fetch metadata about updates without trusting a single key?” via role-separated, threshold-signed JSON. in-toto (Attestation Framework, CNCF Graduated 2023) answers “how do I make verifiable claims about how an artefact was built?” via DSSE-signed Statement+Predicate envelopes. SLSA (v1.0 April 2023, v1.1 latest Approved, v1.2 in flight) answers “what does a good build provenance look like?” via the standardised slsa.dev/provenance/v1 predicate. The three compose: PyPI’s 2024 attestation rollout uses in-toto Statement type v1, SLSA-provenance predicates, distributed via TUF metadata.

  • KMIP 3.0 (CSD 2024) as the long-overdue refresh. KMIP 2.1 shipped in December 2020 and was effectively the last major release before a four-year gap. KMIP 3.0 (Committee Specification Draft, 23 Aug 2024; public review 13 Sept 2024) tightens the attribute model and lays the groundwork for post-quantum mechanism registration. It remains the only vendor-neutral KMS protocol — every commercial HSM and KMS (Thales, Entrust, Utimaco, IBM, Fortanix, AWS CloudHSM-with-shim, HashiCorp Vault as a KMIP server) speaks it. Adoption lags the spec by ~3 years historically.

  • TLS 1.3 cipher-suite naming as a tiny DSL with heavy implications. TLS 1.3 deliberately gutted the cipher zoo down to five MTI suites (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, plus the rarely-used TLS_AES_128_CCM_SHA256 / TLS_AES_128_CCM_8_SHA256). The naming format is itself a small DSL — TLS_<AEAD>_<HASH> — and the absence of key-exchange/signature components in the suite name (those moved to supported_groups and signature_algorithms extensions) is a deliberate decoupling that finally killed the algorithm-fragility problem of TLS 1.2’s TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256-style enumeration. Mozilla’s ssl-config-generator v6.0 dropped the “Old” profile entirely in 2024, leaving only Modern (TLS 1.3 only) and Intermediate (TLS 1.2+).

Citations

Graph View