ARS-1 -- Generic Archival Reference System

juwan.hwang@proton.me

Applications Independent Submission archival reference deterministic identifier cryptographic reference permalink Base32 HKDF ARS-1 defines a deterministic, human-oriented, cryptographically derived reference protocol for assigning stable public References to durable digital entities. Typical references look like NX-174932, CJ3-106, MR-X4928, or KX4-7B19Q2. ARS-1 defines cryptographic identity, deterministic derivation, namespace management, canonical serialization, variable-length encoding, checksum, optional hardware input, optional digital signature, cryptographic agility, versioning, portability, reference resolution, reference reproduction, and cryptographic migration. The core interoperability property is: identical canonical inputs, identical applicable cryptographic Profile, identical Reference Key material, and identical Hardware Profile output MUST produce exactly the same canonical Reference in every conforming implementation. ARS-1 is designed so that changes in cryptographic algorithms, security parameters, signature schemes, or hardware mechanisms can be introduced through versioned Profiles without requiring the reassignment of historical References.

Status: v1.0-rc2 (Frozen) Protocol class: Generic archival reference and permalink protocol Revision: v1.0-rc2 introduces the formal ARS Profile Registry model, separates Profile Identifier from Profile Version to eliminate semantic redundancy (Identifier ARS1-REF + Version 1 instead of ARS1-REF-1), and adds IANA Considerations. The normative Profile v1 test vector (Section 79) has been regenerated to reflect the split Identifier. All prior rc1 vectors are superseded. The specification is frozen as of v1.0-rc2. Conformance: The normative test vector (Section 79) has been regenerated for v1.0-rc2 following the Profile Identifier split (ARS1-REF + Version 1). The values have been cross-verified by 23 independent implementations producing identical output. This does NOT constitute a cryptographic security audit.

ARS-1 defines a deterministic, human-oriented, cryptographically derived reference protocol for assigning stable public References to durable digital entities. Typical visual forms include:

ARS does not assign business meaning to Prefixes. For example:

Project ]]> is an Application Profile decision, not an ARS-1 rule. ARS-1 defines:

The core interoperability property is: Identical canonical inputs, identical applicable cryptographic Profile, identical Reference Key material, and identical Hardware Profile output MUST produce exactly the same canonical Reference in every conforming implementation. ARS-1 is designed so that changes in cryptographic algorithms, security parameters, signature schemes, or hardware mechanisms can be introduced through versioned Profiles without requiring the reassignment of historical References.

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 . A conforming implementation MUST treat all normative serialization, derivation, encoding, verification, migration, and versioning rules as exact protocol requirements.

ARS-1 defines the protocol.

ARS-1 MUST NOT require any specific:

ARS separates the following mechanisms:

Optional:

Independent:

These mechanisms MUST NOT be treated as interchangeable.

Let:

Then:

MUST satisfy:

Reference derivation MUST NOT depend on hidden runtime state. The following MUST NOT affect Reference derivation unless explicitly included in a canonical protocol field:

The ARS Root Secret is the root symmetric secret from which Reference Keys are deterministically derived. A Reference Cryptographic Profile defines the required Root Secret security level. The ARS-1 Default Reference Cryptographic Profile Version 1 requires:

Root Secret material MUST be generated using a cryptographically secure random number generator. A human password MUST NOT be used directly as a Root Secret or Reference Key. Future Reference Cryptographic Profiles MAY define larger Root Secrets or different approved secret-generation requirements.

Root Secret:

MUST NOT be stored in plaintext in ordinary configuration files.
MUST NOT be committed to source control.
MUST NOT be embedded in frontend code.
MUST NOT appear in ordinary logs.
MUST NOT be exposed through ordinary application exports.

Implementations SHOULD use protected storage such as:

Encrypted backups SHOULD use authenticated encryption. If a password protects an encrypted backup, the backup key SHOULD be derived using an appropriate memory-hard password KDF. The password itself MUST NOT become the Reference Key.

Root Secret MUST NOT be reused directly for unrelated cryptographic purposes. Reference derivation MUST use its own domain-separated cryptographic context. Signing keys MUST be independently defined. Conceptually:

A Signing Private Key MUST NOT be treated as the Root Secret. A Hardware Response Secret MUST NOT be treated as the Root Secret.

A Reference Cryptographic Profile defines the cryptographic construction used to derive a Reference. A Profile MUST define at least:

The Profile is part of the ARS Reference context. A Profile's cryptographic identity is the ordered pair:

The Profile Identifier MUST be explicit, immutable for that Profile definition, and unique within the applicable ARS protocol ecosystem. The Profile Version MUST be explicit. A Profile MUST NOT reuse an existing Identifier + Version pair for a different construction. ARS-1 Default Reference Cryptographic Profile Version 1 is:

The Profile Identifier (ARS1-REF) and Profile Version (1) together form the Profile Identity as defined in Section 9. The Identifier MUST NOT include a version suffix; version is always a separate field. The Security Target is an engineering target, not a permanent cryptographic guarantee. A future Profile MAY define a different Security Target and different cryptographic parameters. The exact construction of Profile Version 1 is specified by later normative sections.

ARS-1 is designed for cryptographic agility. Cryptographic agility means that a conforming deployment can replace or add cryptographic mechanisms while preserving the identity, storage, and operational continuity of previously issued References. A future Reference Cryptographic Profile MAY change:

provided the new Profile is explicitly versioned. A future Signature Profile MAY change:

without altering the associated Public Reference. A future Hardware Profile MAY change:

without altering already issued References. An implementation MUST NOT silently substitute a new cryptographic construction under an existing Profile Version. Cryptographic agility does NOT require two different Cryptographic Profiles to derive the same Reference from otherwise identical inputs. Each historical Reference remains bound to the Cryptographic Profile under which it was issued.

For Reference Cryptographic Profile profile_id, version profile_version, and Reference Key Version v:

Then:

PROFILE_ID_BYTES is the exact canonical UTF-8 byte representation of the Reference Cryptographic Profile Identifier. The Profile Identifier and Profile Version are cryptographically bound to Reference Key derivation. The result is exactly:

ARS-1 Reference Cryptographic Profile Version 1 uses HKDF-SHA-256 . Future Profiles MAY define a different key derivation construction.

Every Reference Key has an explicit version:

Reference Key Version MUST be part of the canonical Reference context. Changing Reference Key Version MUST NOT rewrite historical References. Example:

historical References v2 -> References issued under the new key context ]]> Reference Key Version and Reference Cryptographic Profile Version are distinct dimensions. A Profile Version identifies the cryptographic construction. A Reference Key Version identifies the key-generation context within that construction. Reference Key Version is a public derivation-domain identifier. It does not itself provide forward secrecy or recovery from Root Secret compromise; see Section 84.1.

ARS distinguishes at least:

These values MUST NOT be collapsed into one generic version field. Application Profile ID + Application Profile Version defines application-specific semantics. Reference Cryptographic Profile ID + Reference Cryptographic Profile Version defines cryptographic Reference derivation. Reference Key Version identifies the Reference key context within the selected cryptographic Profile. Hardware Profile ID + Hardware Profile Version defines hardware-derived input construction. Only fields explicitly defined as derivation inputs SHALL affect Reference derivation. Signature Profile Version MUST NOT affect Reference derivation. A conforming implementation MUST NOT infer a Profile solely from a numeric version.

An Application Profile MAY define an Identity Generation value. Default type:

Identity Generation distinguishes different long-lived cryptographic identity contexts. It is NOT:

Example:

After an explicit identity-generation transition:

Every Referenceable Entity MUST have an immutable Entity Identity. Permitted forms MAY include:

Entity Identity is the durable identity of the entity. It does not need to resemble the Public Reference. A database primary key MUST NOT automatically be assumed to be an ARS Public Reference.

First Creation Time is archival metadata describing: the first time an entity became a durable entity in the ARS-enabled system. It MAY be used by the Application Profile as immutable archival metadata. Default representation:

Example:

is represented by its corresponding unsigned 64-bit Unix-millisecond value. First Creation Time is NOT a canonical Reference derivation input in ARS-1 v1. This prevents Reference instability caused by later correction of archival metadata. Therefore:

defines the cryptographic identity of the Reference, while:

remains immutable archival metadata associated with the entity.

ARS-1 does not use:

as permanent cryptographic identity. An implementation MAY use database sequences internally. Such sequences MUST NOT become canonical Reference inputs unless explicitly defined by an Application Profile.

Namespace defines the interpretation scope of a Reference. A Namespace MAY represent:

Namespace semantics are application-defined.

Prefix is a Namespace-local semantic series identifier. ARS-1 syntax:

Recommended length:

ARS-1 does not define global Prefix semantics. Example:

Project CJ3 -> Writing MR -> Media ]]> is valid only when the corresponding Application Profile defines those meanings.

Every deployment SHOULD maintain a Prefix Registry. Within a Namespace:

Prefixes MUST be unique.
A Prefix's semantic meaning MUST remain stable.
A Prefix MUST NOT be silently reassigned.
A retired Prefix MUST NOT be reused for an unrelated meaning.
Historical Prefix meanings MUST remain interpretable.

ARS does not maintain a global registry of business meanings.

A Local Reference has the form:

- ]]> Example:

A Local Reference MAY be embedded directly in a URL:

A system operating across multiple Namespaces MAY use a qualified form:

An implementation MAY represent an ARS reference using a URI-like notation such as:

This notation is defined by , which formally registers the ars URI scheme and defines its complete ABNF grammar , encoding rules, case sensitivity, authority/path semantics, and IANA provisional registration. A Local URL does not need to contain the Namespace if the application context already uniquely identifies it.

The normative ARS-1 alphabet is:

Alphabet indices are:

0 1 -> 1 2 -> 2 3 -> 3 4 -> 4 5 -> 5 6 -> 6 7 -> 7 8 -> 8 9 -> 9 10 -> A 11 -> B 12 -> C 13 -> D 14 -> E 15 -> F 16 -> G 17 -> H 18 -> J 19 -> K 20 -> M 21 -> N 22 -> P 23 -> Q 24 -> R 25 -> S 26 -> T 27 -> V 28 -> W 29 -> X 30 -> Y 31 -> Z ]]> The alphabet contains exactly:

The following characters are excluded:

The alphabet is:

Only uppercase letters are permitted in canonical output.

The alphabet intentionally excludes the visually ambiguous letters:

The characters:

remain part of the canonical alphabet because ARS-1 requires a pure alphanumeric 32-symbol alphabet. Human-facing interfaces SHOULD use a font with clear differentiation between:

even though O, I, and L are not valid ARS-1 characters. Canonical References MUST remain uppercase. User-interface input normalization MAY accept lowercase for convenience, but lowercase MUST NOT constitute a canonical Reference representation.

Variable-length encoding is a core ARS-1 property. ARS-1 does NOT require every Reference to have the same visible Payload length. Examples MAY include:

Length MUST emerge from canonical encoding. Implementations MUST NOT introduce random length. Implementations MUST NOT introduce non-canonical visual padding. Application Profiles define the maximum Payload length and public data domain appropriate to their deployment.

An Application Profile defines:

The selected Reference Cryptographic Profile MUST provide at least that many Reference Material bits. An Application Profile MUST NOT request more public data bits than its selected Reference Cryptographic Profile can produce. A future Reference Cryptographic Profile MAY provide a larger Reference Material domain. The public data domain is independent from the Root Secret security level.

Let the fixed-width Public Data value be D. The data value is encoded using the ARS-1 Base32 alphabet. Leading zero-valued Base32 symbols MUST be omitted. The canonical rule is:

Because alphabet index 0 maps to:

leading 0 symbols are omitted from the canonical representation. The all-zero data value is encoded as:

and never as an empty string.

Let:

A conforming implementation MUST satisfy:

and:

for every accepted canonical string. A decoder MUST reject non-canonical encodings. For example, if:

is canonical, then:

MUST NOT be accepted as an alternative canonical representation.

The canonical Reference record is:

The field order is normative. First Creation Time is intentionally excluded from this record in ARS-1 v1. For all cryptographic operations that reference CanonicalReferenceRecord, the term means the exact binary serialization defined in Section 30. An implementation MUST NOT substitute a JSON, textual, implementation-defined, or otherwise non-normative representation.

All integer values use unsigned big-endian encoding. Canonical field types:

Variable-length fields MUST contain explicit lengths. Implementations MUST NOT concatenate variable-length fields without explicit boundaries. The resulting byte sequence is the normative CanonicalReferenceRecord.

The following textual fields MUST be normalized before serialization:

For ARS-1 core identifiers, the following fields MUST use ASCII bytes only:

Prefix is already restricted by the ARS-1 grammar to ASCII uppercase letters and digits. For Namespace, an Application Profile MUST choose exactly one of:

For Entity Identity, the Application Profile MUST define its exact canonical encoding. If Unicode is permitted, the Profile MUST specify the normalization form and Unicode version. Where Unicode NFC is used, the Unicode version is part of the canonical Application Profile definition and MUST NOT change without a new Application Profile Version. Prefix MUST be canonical uppercase after normalization. No implementation may apply locale-dependent case conversion, locale-dependent normalization, or implementation-specific Unicode processing to a canonical field.

Entity Identity serialization MUST be fixed by the Application Profile. If UUID or UUIDv7 is represented as canonical text, the exact textual form MUST be fixed. For example, only one of the following may be canonical:

or:

The Profile MUST NOT permit both as canonical encodings.

Define:

Then:

For Reference Cryptographic Profile Version 1, the resulting 32-byte digest is the HKDF extraction salt for Reference Material derivation. All variable-length fields in SALT_INPUT MUST use the lengths defined above. The Application Profile Identifier and Application Profile Version are cryptographically bound to the Reference Salt, ensuring that distinct Application Profiles produce distinct salt domains even when they share the same Reference Cryptographic Profile, Namespace, and Prefix. A future Reference Cryptographic Profile MAY define a different salt construction, but MUST use a new Profile Version.

For Reference Cryptographic Profile Version 1, first derive the Reference Key using the exact Reference Cryptographic Profile Identifier and Version:

Then:

For this operation, CanonicalReferenceRecord MUST mean the exact binary serialization defined in Section 30. All operations are deterministic. No random nonce or hidden runtime entropy is permitted. Future Reference Cryptographic Profiles MUST define their own complete derivation construction.

The following domain strings are normative for Reference Cryptographic Profile Version 1:

A new cryptographic purpose MUST use a distinct domain-separated label. Profile identifiers and versions are cryptographic context, not substitutes for domain labels. Both MUST be bound exactly where specified by the Profile construction. A future Profile MUST NOT silently reinterpret an existing domain string under the same Profile Version.

The Application Profile defines data_bits. The Public Data value is the first data_bits of ReferenceMaterial, interpreted in big-endian bit order. An Application Profile MUST specify:

The checksum is 1 symbol (5 bits) as defined by the protocol. The Public Data domain is exactly:

possible values. Increasing the cryptographic strength of the underlying Reference derivation does not automatically increase the public collision domain.

For each 5-bit group:

0 1 -> 1 2 -> 2 ... 9 -> 9 10 -> A 11 -> B 12 -> C 13 -> D 14 -> E 15 -> F 16 -> G 17 -> H 18 -> J 19 -> K 20 -> M 21 -> N 22 -> P 23 -> Q 24 -> R 25 -> S 26 -> T 27 -> V 28 -> W 29 -> X 30 -> Y 31 -> Z ]]> Groups are processed from the most significant bit toward the least significant bit. If the data-bit length is not divisible by 5, the final partial group is padded on the right with zero bits for encoding. A decoder MUST verify that all unused padding bits are zero.

An Application Profile MUST specify:

The ARS-1 checksum is fixed at 1 symbol (5 bits) as defined in Section 42. The maximum Payload length MUST accommodate the profile's full data domain plus 1 checksum symbol. ARS-1 does not define a universal Payload length. A deployment MAY select a short visual Profile, a larger Profile, or another Profile appropriate to its expected issuance volume and identifier requirements. An Application Profile SHOULD prefer data_bits values divisible by 5 for representation efficiency. Non-multiples of 5 are fully valid and MUST use zero padding as specified in Section 37.

For approximately n independently distributed issued values, the birthday-bound approximation is:

for sufficiently small probabilities. An Application Profile MUST evaluate its expected lifetime issuance volume against its selected public data domain. The public collision domain is independent from:

Increasing any of those values does not increase data_bits unless the Application Profile actually exposes additional derived bits. The exact collision probability for n issued References with b = data_bits is:

For small probabilities, this simplifies to:

To determine the required data_bits for a target collision probability P_target and expected lifetime issuance volume n:

= log2(n^2 / (2 * P_target)) ]]> For example, for P_target = 0.5 (50% birthday bound), the exact threshold is:

For data_bits = 40, this yields:

meaning approximately 1.234 million independently distributed issued References are needed to reach a 50% collision probability in a 40-bit public data domain. An Application Profile SHOULD use these formulas to select data_bits based on its expected lifetime issuance volume and acceptable collision probability, rather than relying on fixed thresholds.

Reference derivation is deterministic but MUST NOT be publicly predictable solely from public entity metadata. Without the required secret cryptographic material, observing existing References MUST NOT provide a practical method for predicting Reference Material of unrelated entities under the same Profile. Therefore:

Collision resistance and enumeration resistance are separate security properties. A larger public data domain does not by itself provide authentication or authorization.

A collision between two issued References is an issuance failure. Collision handling is an Application-level issuance invariant. An implementation MUST NOT silently resolve a collision using:

A collision MAY be resolved only by an explicit change of canonical profile inputs, such as:

Such a change creates a distinct canonical Reference context. Applications SHOULD detect collisions before committing a Reference as issued.

ARS-1 defines a deterministic 5-bit hash-derived checksum. For:

calculate:

Take the first 5 bits of digest. Interpret them as an integer from 0 to 31, then map through the ARS-1 alphabet. A future Protocol Version MAY define a checksum mechanism with more symbols or a different construction. Such a change requires a new Protocol Version and MUST NOT be introduced under the same Application Profile Version.

The checksum is the final Payload symbol. The canonical structure is:

- ]]> The checksum is part of the Public Reference but is not part of canonical_data when computing itself.

A verifier performs:

Checksum verification does not require database access.

The checksum provides a 32-state checksum space. Its random collision probability is 1/32. This value MUST NOT be interpreted as an authentication or cryptographic integrity bound. The ARS-1 checksum is a hash-truncation checksum: it takes the first 5 bits of a SHA-256 digest. This is fundamentally different from algebraic checksums (such as Luhn, ISBN-10, or China ID checksums), which use modular arithmetic to structurally guarantee detection of specific error classes. Because the checksum is hash-derived, it has NO deterministic detection guarantee for any specific error class:

Single-symbol substitution: expected miss probability 1/32, no guarantee
Adjacent-symbol transposition: expected miss probability 1/32, no guarantee
Arbitrary transposition: expected miss probability 1/32, no guarantee

Under the standard pseudorandom-function / random-oracle model for SHA-256, a truncated 5-bit checksum of a non-identical input is expected to behave as a uniformly random 5-bit value, yielding an expected collision probability of 1/32 for all error classes. This is a probabilistic expectation, not a proven equality for every specific error transformation. The key distinction is: the checksum has no algebraic structure that would provide deterministic detection of any error class, nor is there evidence of systematic bias toward or against any particular error type. An Application Profile that requires guaranteed detection of specific error classes (e.g., all adjacent transpositions) MUST NOT rely on the ARS-1 checksum alone. Such Profiles SHOULD define additional application-layer validation or select a future Protocol Version with an algebraic checksum mechanism. Therefore the checksum is a:

and NOT:

An attacker who knows the algorithm can recompute it. These properties are restated as Hard Invariants 81 and 82 (Section 85). In case of any perceived discrepancy, the Hard Invariants and this Section are intended to be semantically identical.

A Hardware Profile is identified by:

A Hardware Profile MUST define an exact deterministic Canonical Challenge construction. The challenge construction MUST be a deterministic function of the canonical Reference context available before hardware_input is produced, together with the Hardware Profile definition. The protocol-visible challenge context MUST include at least:

It MUST NOT include hardware_input, because hardware_input is the response-derived output of the Hardware Profile. A Hardware Profile MUST specify the exact byte encoding of its challenge context, challenge derivation algorithm, response algorithm, output truncation rule, and output encoding. A Hardware Profile definition SHOULD provide conformance vectors covering representative equivalent credentials, so that implementers have verifiable behavioral standards for Hardware Credential Equivalence Class claims. A Hardware Credential Equivalence Class MAY be defined by a Hardware Profile. Two hardware credentials MUST be treated as equivalent for ARS reproduction only when the Profile explicitly guarantees that they produce the same deterministic response for every valid canonical challenge. Possessing a physically different device is not, by itself, evidence of hardware credential equivalence.

Hardware is OPTIONAL. ARS-1 defines:

Possible implementations include:

ARS-1 does not depend on any vendor.

A Hardware Profile MUST define:

For Reference derivation, a conforming Hardware Profile MUST guarantee:

Uncontrolled randomness MUST NOT affect the Reference-derived hardware output.

ARS does not interpret vendor-specific hardware internals. Instead:

The hardware_input field in the ARS canonical record is exactly that canonical Profile-defined byte representation. The same Hardware Profile Version MUST assign exactly one canonical byte representation to each valid response.

Hardware Profile Version MUST be explicit. A future incompatible construction MUST use a new version. A Profile MUST NOT silently change:

while retaining the same version. A deprecated or compromised Hardware Profile MUST NOT invalidate already issued References. A deployment MAY stop issuing new References under the deprecated Profile while retaining the Profile for historical reproduction and verification. A Hardware Profile migration MAY change the Hardware Input used by future Reference contexts. It MUST NOT rewrite a historical Reference.

This is a hard ARS-1 invariant. If hardware participates in Reference generation:

hardware MAY be required for:

but ordinary Reference Resolution MUST NOT require the hardware to be present after issuance when the application already maintains the Reference -> Entity association. Therefore:

MUST remain resolvable without an attached hardware device. Loss of issuance hardware MUST NOT invalidate an already issued Reference.

A deployment MAY preserve hardware_input as part of the historical Reference record. When hardware_input is retained:

MAY be performed without physical access to the original hardware, provided all other required canonical inputs, Profile information, and key material are available. When hardware_input is not retained, reproduction MAY require the original hardware credential or an explicitly defined recoverable equivalent. An Application Profile using hardware-bound References MUST explicitly document which reproduction mode it uses.

A YubiKey MAY implement an ARS Hardware Profile. A vendor-specific Challenge-Response output becomes the Hardware Profile's deterministic response. ARS cryptographic derivation then incorporates the canonical hardware response through the applicable Reference Cryptographic Profile. ARS-1 does not use vendor-specific hardware cryptography as a replacement for its own Reference derivation architecture.

A Hardware Profile MAY require:

These controls determine whether the hardware operation is allowed. They MUST NOT themselves become uncontrolled entropy in Reference derivation. A deterministic Hardware Profile MUST produce the same response for the same canonical challenge and the same hardware secret.

An Application Profile using Hardware-Bound References MUST define a recovery strategy. Permitted strategies MAY include:

Loss of the original hardware MUST NOT mutate an already issued Reference. If reproduction is required after hardware loss, the Application Profile MUST define how the necessary reproduction material is recovered.

Digital Signatures are independent from Reference derivation. A signature establishes that a holder of a specific Signing Private Key authorized or signed a specified record. Signatures:

MUST NOT determine the Reference.
MUST NOT alter the Reference.
MAY exist in multiple versions.
MAY use hardware-backed keys.
MAY use classical, post-quantum, or hybrid cryptographic constructions.

The cryptographic status of a Signature Profile MUST NOT determine whether an already issued Reference remains valid.

Signing Private Keys MUST be separate from:

A signing implementation SHOULD generate its signing key independently. A hardware-backed signing key MAY be stored in:

A Signature Profile MUST define:

ARS-1 does not prescribe one permanent signature algorithm. Signature Profiles MAY be classified as:

A deployment requiring long-term resistance to quantum attacks SHOULD select an approved and currently appropriate post-quantum or hybrid Signature Profile. A future Signature Profile MAY replace an older Profile without changing any associated Public Reference.

A Signature Profile MAY be deprecated, superseded, or retired. Deprecating a Signature Profile MUST NOT invalidate:

A deployment MAY attach a newer signature to the same Reference and state while retaining historical signatures for archival purposes. A migration MAY therefore produce:

without changing the Reference. A cryptographic signature MUST NOT be treated as the permanent identity of the entity.

A recommended signing context is:

Signature serialization MUST be specified independently from Reference derivation serialization. A signature MUST NOT be added to the Reference derivation merely to increase perceived security. A change in Signature Profile MUST NOT alter the Public Reference.

A Reference does not prove the exact historical contents of an entity. Applications requiring historical integrity SHOULD use:

Conceptually:

Which durable entity? State Root -> Which exact historical state? Signature -> Who authorized the record? Authorization -> Who is allowed to access or modify it? ]]> These are independent properties.

ARS-1 is designed so that its core Reference architecture does not depend on classical public-key primitives such as integer-factorization or elliptic-curve discrete-logarithm systems. The ARS-1 Reference Cryptographic Profile Version 1 uses:

This construction is not based on the classical public-key assumptions targeted by Shor-style attacks. However, ARS-1 MUST NOT claim that any specific cryptographic algorithm is permanently immune to all future quantum or classical cryptanalytic advances. The security target of each Cryptographic Profile is an engineering designation describing the intended security level under the assumptions of the specified primitives. ARS-1 therefore treats the following as separate properties:

A Profile MAY be cryptographically suitable for current deployment without being treated as permanently safe against all future cryptanalytic advances.

Post-quantum migration MUST occur at the cryptographic Profile layer wherever possible. A deployment MUST prefer:

rather than:

A Cryptographic Profile migration preserves historical References, but different Cryptographic Profiles are NOT required to derive the same Reference from the same entity context. Historical References remain cryptographically bound to the Profile and key context under which they were originally issued. For example:

and later:

MAY produce different References. This does not constitute mutation of R1. R1 remains the canonical historical Reference for the original Reference context. A deployment SHOULD distinguish:

from:

When a Cryptographic Profile becomes deprecated or unsafe, the deployment SHOULD:

A cryptographic transition MUST NOT silently reinterpret an existing Reference as though it had been issued under a different Profile.

Reference Resolution means:

Entity ]]> Resolution is an application-state operation. A system MAY resolve a syntactically valid and checksum-valid Reference to:

depending on application policy. Checksum validity alone does NOT establish that an entity exists. Reference Resolution MUST NOT require a particular cryptographic Profile unless the application explicitly needs cryptographic reproduction or verification.

Reference Reproduction means:

A conforming implementation MUST reproduce the exact canonical Reference. Reproduction is cryptographic. Resolution is application-state based. The two operations MUST NOT be conflated.

A verifier MAY operate at multiple levels.

Verify:

Given:

reproduce the Reference and compare character-for-character.

Use application state:

Entity ]]> No lower verification level implicitly proves a higher one.

A valid Reference MUST NOT imply:

Applications MUST enforce authorization independently. Knowledge of a Reference MUST NOT itself grant privileged access.

Once an ARS Reference has been issued:

MUST NOT release the Reference for reassignment. A retired Reference MUST NOT be reassigned to an unrelated entity.

Semantic routes MAY change:

The ARS Reference remains stable:

Therefore: Semantic URL = current information architecture. ARS Reference = durable identity locator.

When an ARS Reference is embedded in a canonical URL:

Prefix MUST be canonical uppercase.
Payload MUST use the canonical ARS-1 alphabet.
The separator MUST be exactly one ASCII hyphen.
The Reference itself MUST NOT require percent-encoding.
Lowercase representations MUST NOT constitute a separate canonical identity.

Example:

A future cryptographic Profile MUST NOT require changing the canonical URL representation of an already issued Reference.

A complete portable export MUST preserve all information necessary to reproduce existing References. At minimum:

A complete archival export SHOULD also preserve:

Where a Hardware Profile requires an external hardware credential for reproduction, the export policy MUST document how that credential is preserved, duplicated, escrowed, or otherwise recovered. Imports MUST preserve historical References. A correct export/import cycle MUST satisfy:

for identical canonical identity context, applicable Profile definitions, and required key material.

Key rotation MUST NOT rewrite historical References. Example:

Historical References MUST retain their Reference Key Version. Old key material SHOULD remain protected for as long as cryptographic reproduction of historical References is required. Changing Reference Key Version MAY affect newly issued References, but MUST NOT silently alter historical ones.

Cryptographic Profile selection for new Reference issuance MUST be governed by authenticated local deployment policy. An untrusted caller, request field, import record, or network input MUST NOT be able to select a Deprecated or Retired Cryptographic Profile when the deployment policy requires a stronger Active Profile. A deployment MUST define a minimum acceptable Cryptographic Profile for new issuance. The effective issuance policy MUST be evaluated before Reference derivation. Historical reproduction is a distinct operation and MAY use the historical Cryptographic Profile and Reference Key Version originally bound to the Reference, provided the required historical material is available and the deployment explicitly permits such reproduction. Therefore:

A cryptographic migration MUST NOT be interpreted as permission for an untrusted caller to request a weaker Profile. A conforming implementation MUST fail closed when a requested Profile is unknown, unsupported, below the configured issuance security floor, or otherwise disallowed by policy.

Every Reference Cryptographic Profile SHOULD have an explicit lifecycle status:

A Profile MAY become:

when a stronger or more appropriate Profile is available. A Profile MAY become:

when continued issuance under that Profile is no longer acceptable. Retirement MUST NOT invalidate historical References. Historical Profiles MUST remain identifiable to conforming archival software for as long as historical Reference reproduction is required. A deployment MAY prohibit creation of new References under a Deprecated or Retired Profile while retaining the Profile for historical verification. A Deprecated or Retired Profile MUST NOT be silently substituted with another Profile.

A cryptographic migration is the controlled introduction of a new Cryptographic Profile for future issuance or reproduction. A migration MUST identify:

A migration MUST preserve:

A migration MAY issue a new Reference for the same durable Entity when the Application Profile explicitly permits multiple Reference contexts. If multiple References exist for one Entity, the Application Profile MUST define which Reference is:

No migration process may silently replace an existing historical Reference.

Protocol Version MUST identify the exact ARS construction. For example:

defines this specification. A future:

MAY change:

ARS-2 MUST NOT silently reinterpret an ARS-1 Reference. Historical ARS-1 References remain ARS-1 References. Cryptographic Profile changes that preserve the ARS-1 protocol architecture SHOULD use Profile Versioning rather than forcing a protocol-version change.

Every deployment SHOULD define:

An Application Profile MAY be stricter than ARS-1. It MUST NOT weaken ARS-1 deterministic or canonical requirements.

ARS-1 does not mandate any specific real-world Application Profile. An illustrative Profile MAY define:

The checksum is 1 symbol (5 bits) as fixed by the protocol. Example Prefix Registry:

The above is illustrative only. ARS-1 itself does not require 40-bit data, nine-symbol maximum Payloads, or any particular Prefix Registry.

The following vector is normative. It uses a test-only Application Profile and the ARS-1 Default Reference Cryptographic Profile Version 1. All values below use the final ARS-1 alphabet:

First Creation Time exists in the entity record but is deliberately NOT part of the Reference derivation vector. The test Application Profile defines:

The checksum is 1 symbol (5 bits) as fixed by the protocol. The following values were generated using the exact inputs above and the construction defined in Section 11, Section 30, Section 33, Section 34, Section 42, and Section 43. They have been cross-verified by 23 independent implementations (Python, Rust, Go, TypeScript, JavaScript, C, C++, C#, Java, PowerShell, Dart, Bash, AWK, Perl, sed, LaTeX, SQL, m4, bc, Make, troff, Assembly, FFmpeg) producing identical output.

Hexadecimal:

First 40 bits:

Any conforming ARS-1 implementation receiving exactly these inputs MUST produce the regenerated Final Canonical Reference character-for-character.

The following Reference is derived from the Section 79 final Reference (NX-DQEC5JQDW) by corrupting the checksum symbol from W to X. The following Reference MUST fail checksum verification:

because the normative checksum does not match the supplied checksum symbol. A decoder MUST also reject non-canonical Base32 representations containing unnecessary leading zero-valued symbols. For example, a data value canonically represented as:

MUST NOT accept:

as an equivalent canonical Reference payload.

A conforming implementation SHOULD pass:

At least two independently implemented implementations SHOULD be cross-tested. Recommended implementation languages include:

Cross-language outputs MUST match exactly. Independent implementations SHOULD test at least one implementation in a memory-safe systems language and one implementation in a separate runtime or language ecosystem.

A production deployment SHOULD maintain a minimal reference implementation whose purpose is:

The test-vector generator SHOULD be treated as a build-time or verification tool, not as part of the runtime trust model. Normative vectors SHOULD be generated from the reference implementation and independently verified before every protocol release. A reference implementation MUST NOT silently fall back to a different cryptographic Profile when a requested Profile is unavailable.

A conforming implementation SHOULD test at least:

for a large corpus of generated values. The corpus SHOULD include:

Decoders SHOULD reject:

Implementations SHOULD test that historical References remain reproducible after introducing a new Cryptographic Profile or Signature Profile.

A Secure ARS deployment MUST:

use a CSPRNG for Root Secret generation
use the minimum entropy required by the selected Reference Cryptographic Profile
protect Root Secret material
use an explicitly selected Reference Cryptographic Profile ID and Version
use explicit Profile Versioning
separate cryptographic purposes
canonicalize all serialized inputs
fail closed on malformed input
preserve Reference Key Versions
preserve Reference Cryptographic Profile Versions
preserve historical References
avoid hidden runtime entropy
avoid silent collision fallback
avoid silent cryptographic algorithm substitution
enforce an authenticated minimum Profile policy for new issuance
reject cryptographic downgrades for new issuance
preserve Profile metadata required for historical reproduction

For Reference Cryptographic Profile Version 1, implementations MUST:

use a 256-bit Root Secret
use HKDF-SHA-256 as specified
produce a 256-bit Reference Key
produce a 256-bit Reference Material value

Implementations SHOULD also:

zeroize sensitive intermediate material where practical
minimize secret lifetime in memory
avoid secret exposure in diagnostics
protect encrypted backups
audit key rotation
audit cryptographic Profile migration
test import/export reproducibility
test historical Reference reproduction

A Root Secret compromise is a critical security incident. It affects the enumeration resistance property (Section 40) but does NOT affect Reference identity stability. Historical References remain canonical and MUST NOT be invalidated, reassigned, or reissued. The compromise is a confidentiality failure of the derivation secret, not an integrity failure of the Reference.

Under Reference Cryptographic Profile Version 1, all Reference Key Versions are deterministically derived from the same Root Secret via HKDF-Expand (Section 11). The Reference Key Version is bound to the derivation context through the info parameter, but the Root Secret is the sole source of secret entropy for every Key Version. Therefore, an attacker who obtains the Root Secret can reconstruct the full derivation chain for ALL Reference Key Versions under that Root Secret, provided the Profile identifiers, Profile versions, and Key Version numbers are known (which they are, since they form part of the canonical Reference context): The derivation chain is: Root Secret -> HKDF-Extract -> PRK (pseudorandom key) -> HKDF-Expand(info = ... || profile_id || profile_version || key_version || ...) -> ReferenceKey(v) for every v. This means: Root Secret compromise = compromise of ALL Reference Key Versions derived from that Root Secret. A deployment that uses a single Root Secret across multiple Namespaces or Prefixes MUST treat the compromise as affecting the entire Root Secret domain. The Reference Salt (Section 33) provides domain separation between Application Profiles, Namespaces, and Prefixes, but the Salt is a public value derived from public inputs -- it does NOT provide additional secret entropy. Therefore, Salt-based domain separation does NOT limit the scope of a Root Secret compromise.

A Root Secret compromise affects the following security properties:

Reference identity stability: PRESERVED. Historical References remain canonical, unchanged, and valid. The compromise does not alter or invalidate any issued Reference.
Enumeration resistance (compromised key context): LOST. The attacker can reproduce all existing References and predict Reference Material for entities whose canonical inputs are known, for ALL Key Keys under the compromised Root Secret. This loss is IRRECOVERABLE for the compromised Root Secret domain. No Key Version rotation under the same Root Secret can restore it, because the attacker can derive every future Key Version as well.
New issuance security: RESTORABLE ONLY by replacing the Root Secret. A new Reference Key Version under the SAME Root Secret does NOT restore enumeration resistance, because the attacker can derive the new Key Version from the compromised Root Secret. To restore enumeration resistance for new issuance, the deployment MUST generate and deploy a NEW, independent Root Secret. Key Version rotation under the same Root Secret is NOT sufficient.

The critical distinction is:

Key Version rotation under the SAME Root Secret: changes the derivation context for new issuance; does NOT prevent the attacker from deriving the new Key Version; enumeration resistance remains LOST.
New, independent Root Secret: attacker cannot derive keys from the new Root Secret; new issuance regains enumeration resistance; historical References under the OLD Root Secret remain canonical but their enumeration resistance is permanently lost.

A deployment that detects or suspects Root Secret compromise MUST:

Immediately generate a NEW, independent Root Secret using a CSPRNG. Do NOT derive the new Root Secret from the compromised Root Secret.
Introduce a new Reference Key Version bound to the new Root Secret, or introduce a new Reference Cryptographic Profile if the compromise suggests structural weakness.
Cease all new Reference issuance under the compromised Root Secret and ALL Reference Key Versions derived from it. New issuance MUST use the new Root Secret and new Key Version.
Audit the scope of potential exposure:
- identify all Reference Key Versions derived from the compromised Root Secret
- identify all Namespaces and Prefixes affected
- assess whether canonical entity inputs for affected References are publicly known
- evaluate the enumeration risk for each affected Namespace and Prefix
Preserve all historical References and their associated Profile metadata. Historical References MUST NOT be invalidated or reassigned. Historical References do NOT need to be reissued.
Document the compromise incident, affected Root Secret, affected key versions, and remediation actions as part of the archival record.

After deploying a new, independent Root Secret:

compromised Root Secret domain: historical References remain canonical and unchanged; identity stability: PRESERVED; enumeration resistance: PERMANENTLY LOST; cannot be restored by any means.
new Root Secret domain: new References regain full enumeration resistance; identity stability: PRESERVED (new References are canonical); new issuance security: RESTORED.

Root Secret compromise does NOT constitute a Reference identity failure. Historical References remain canonical identifiers for their original entities and do NOT need to be reissued. The failure is in the confidentiality of the derivation secret: the attacker can predict and reproduce References, but cannot alter or invalidate them.

A deployment that requires stronger isolation against Root Secret compromise MAY adopt a per-Namespace or per-Prefix Root Secret strategy: Namespace A -> Root Secret A, Namespace B -> Root Secret B, Namespace C -> Root Secret C. Under this model, compromise of Root Secret A does NOT affect the enumeration resistance of Namespaces B or C. Each Root Secret domain is cryptographically independent. This is a deployment-level decision. ARS-1 v1 does NOT mandate a single-Root-Secret model. The protocol's HKDF construction supports multiple independent Root Secrets without modification -- each Root Secret simply produces its own independent derivation chain. A deployment SHOULD document its Root Secret strategy as part of its Application Profile security policy, including:

detection mechanisms
escalation procedures
Root Secret rotation procedure (new independent Root Secret, NOT key version rotation)
communication plan for affected stakeholders
forensic preservation requirements
Root Secret isolation strategy (single vs. per-Namespace vs. per-Prefix)

Profile Identifier uniqueness is scoped to the applicable ARS Profile Registry (Section 84.3). Within a Registry, each Identifier MUST be unique and permanent. The following Profile Identifiers are defined by this specification and registered in the ARS Canonical Profile Registries (Section 84.3):

ARS1-REF: Reference Cryptographic Profile Identifier (Version 1 defined in Section 9)
NONE: Hardware Profile Identifier (no hardware)

These protocol-defined identifiers are reserved and MUST NOT be redefined by Application Profiles or deployments. A deployment MAY define its own Profile Identifiers. When two independent deployments need to interoperate, they SHOULD exchange and verify complete Profile definitions before interoperation. Cross-deployment reproduction or verification requires explicit Profile alignment. A deployment SHOULD maintain an internal registry of all Profile Identifiers it uses. The internal registry SHOULD follow the same field model as the ARS Canonical Profile Registries (Section 84.3).

ARS-1 defines a formal Profile Registry architecture consisting of three Canonical Profile Registries, each governing a distinct Profile type:

Application Profile Identifiers are deployment-scoped and are NOT governed by a Canonical Registry. Cross-deployment Application Profile alignment is the responsibility of the interoperating deployments (Section 84.2).

Every entry in a Canonical Profile Registry MUST include:

Identifier: The permanent, unique Profile Identifier (ASCII-only, no version suffix).
Version: The Profile Version (positive integer).
Name: Human-readable name of the Profile.
Status: Lifecycle status: Active / Deprecated / Retired / Reserved.
Specification: Reference to the defining specification or document.
Security Target: Engineering security designation for the Profile.
Change Controller: The entity responsible for approving changes to this Registry entry.

The ordered pair (Identifier, Version) is permanent and MUST NOT be reused for a different Profile definition. A Reserved status indicates that an Identifier (or Identifier + Version pair) is set aside for future or experimental use. A Reserved entry MUST NOT be used in production Reference derivation until its status changes to Active.

Active: The Profile is approved for new issuance.
Deprecated: The Profile is superseded but remains valid for historical reproduction. New issuance is discouraged but not prohibited unless deployment policy forbids it.
Retired: The Profile is no longer approved for new issuance. Historical References remain canonical. The Profile MUST remain identifiable for historical reproduction.
Reserved: The Identifier or Identifier + Version pair is set aside and MUST NOT be used in production until the status changes to Active.

Status transitions:

Reserved -> Active: Permitted when the Profile definition is finalized.
Active -> Deprecated: Permitted when a successor Profile is available.
Active -> Retired: Permitted when continued issuance is no longer acceptable.
Deprecated -> Retired: Permitted.
Retired -> Active: NOT permitted. A Retired Profile MUST NOT be reactivated.
Any -> Reserved: NOT permitted after initial registration.

Once an (Identifier, Version) pair has been registered with any status other than Reserved, it MUST NOT be reused for a different Profile definition, even if the status becomes Retired.

Profile Identifiers are allocated on a first-come, first-served basis within each Registry, subject to review by the Change Controller. Identifier allocation rules:

An Identifier MUST be unique within its Registry.
An Identifier MUST NOT include a version suffix. Version is always a separate field.
An Identifier MUST be ASCII-only (Section 31).
An Identifier MUST be between 3 and 32 characters.
An Identifier SHOULD be mnemonic of the Profile's purpose.
The Identifier prefix "ARS1-" is a protocol-defined namespace reservation. Identifiers beginning with "ARS1-" are reserved for protocol-defined Profiles and MUST NOT be allocated by deployments without explicit protocol authorization. Third-party Identifiers MAY use other prefixes (e.g., "ACME-REF", "FOO-HW").
The Identifier "NONE" is reserved for the no-hardware Hardware Profile.
Once allocated, an Identifier is permanent and MUST NOT be renamed.

Versions are positive integers starting from 1.
A new Version of an existing Profile Identifier MAY be registered when the Profile definition changes in a way that affects cryptographic output, challenge construction, signature format, or other interoperability-relevant properties.
An existing (Identifier, Version) pair MUST NOT be reused for a different Profile definition.
Version numbers SHOULD normally be monotonically increasing within an Identifier. Gaps MAY exist due to reservation, withdrawal, or other documented registry operations. Version numbers MUST NOT be reused.
A Version that has been registered as Active, Deprecated, or Retired MUST NOT be silently redefined.

The Change Controller for the ARS Canonical Profile Registries is the ARS-1 specification maintainer, currently the ARS-1 GitHub repository:

The Change Controller is responsible for:

Reviewing registration requests
Approving or rejecting Identifier / Version allocations
Publishing the canonical Registry contents
Maintaining the historical Registry record

A change to a Registry entry (other than status transitions) MUST NOT alter any already-registered (Identifier, Version) pair. New entries and status transitions are published as amendments to the Registry tables in Section 84.4.

The Canonical Profile Registries are published and maintained in the ARS-1 specification repository. The Registry contents are normatively defined by the tables in Section 84.4 of this specification. Deployments SHOULD consult the Canonical Profile Registries when validating Profile Identifiers received from external sources. However, the Canonical Registries do NOT override deployment-local policy for Profile selection (Section 73).

Identifier: ARS1-REF
Version: 1
Name: ARS-1 Default Reference Cryptographic Profile
Status: Active
Specification: ARS-1 Section 9, 11, 33, 34
Security Target: ~128-bit classical
Change Controller: GitHub

Identifier: NONE
Version: 1
Name: No Hardware Profile
Status: Active
Specification: ARS-1 Section 47
Security Target: N/A (no hardware)
Change Controller: GitHub

The ARS Signature Profile Registry is empty as of ARS-1 v1.0-rc2. ARS-1 does not define a default Signature Profile. Deployments requiring digital signatures SHOULD register their Signature Profile in their internal registry and MAY request registration in the Canonical Registry.

ARS-1 v1.0 does NOT request IANA to create any new registries. The ARS Canonical Profile Registries (Section 84.3, 84.4) are maintained as GitHub-maintained canonical registries within the ARS-1 specification repository. If future protocol evolution requires IANA-managed registries, the following migration path is defined:

At that point, the IANA-managed Registry would succeed the GitHub Canonical Registry as the authoritative source. Existing GitHub Registry entries would be migrated as initial IANA Registry entries. The (Identifier, Version) permanence rules (Section 84.3.1, 84.3.4) would carry over to the IANA Registry without modification. This section is informative for v1.0. A future ARS specification version MAY make IANA-related sections normative.

ARS-1 MUST satisfy all of the following:

Identical canonical inputs under the same Reference Cryptographic Profile ID and Version produce identical References.
Reference derivation contains no hidden randomness.
Root Secrets are generated with a CSPRNG.
The selected Cryptographic Profile defines the required Root Secret security level.
Reference derivation uses an explicit Cryptographic Profile ID and Version.
Cryptographic purposes use independent derivation domains.
Entity Identity is immutable.
First Creation Time is immutable archival metadata when used by the Application Profile.
First Creation Time is not a Reference derivation input in ARS-1 v1.
Permanent identity does not depend on mutable titles or content.
Sequence numbers are not permanent identity unless explicitly profiled.
Payload length may naturally vary.
ARS-1 does not prescribe one universal Payload length.
Application Profiles define their own data-bit and length policies.
The ARS-1 alphabet contains exactly 32 ASCII alphanumeric symbols.
The ARS-1 alphabet contains no punctuation or other symbols.
Hardware is optional.
Hardware Profiles are vendor-neutral.
Hardware-derived Reference inputs are deterministic.
Hardware input is explicit canonical input.
Digital signatures do not determine the Reference.
Signature Profiles are independent from Reference derivation.
Signature Profiles are replaceable without rewriting historical References.
Checksum is deterministic.
Checksum is not cryptographic authentication.
Reference validity is not authorization.
Reference validity is not content integrity.
Historical References never change.
Historical References are never reused.
Export/import preserves References.
Key rotation does not rewrite historical References.
Prefix semantics are Namespace-local.
Prefix meanings cannot be silently reassigned.
Collision fallback cannot introduce hidden randomness.
A detected collision is an issuance failure unless canonical inputs are deliberately changed.
Canonical URLs are deterministic.
Canonical Base32 representations are unique.
Independent conforming implementations produce identical References.
Cryptographic algorithms are public.
Secret cryptographic material is never embedded in source code.
Protocol Version, Application Profile ID/Version, Reference Cryptographic Profile ID/Version, Reference Key Version and Hardware Profile ID/Version are distinct identity/version dimensions.
Signature Profile Version does not affect Reference derivation.
Cryptographic Profile changes MUST be explicit.
A deprecated Cryptographic Profile MUST NOT silently reinterpret historical References.
Historical References remain valid after Cryptographic Profile migration.
A Signature Profile may be migrated without changing the associated Reference.
Canonical References use uppercase output.
The ARS-1 alphabet excludes I, L, O and U.
The ARS-1 alphabet is exactly: 0123456789ABCDEFGHJKMNPQRSTVWXYZ
An empty canonical Payload is never valid.
Leading zero-valued Base32 symbols MUST be omitted in canonical encoding.
Variable-length canonical fields MUST use explicit length encoding.
Reference Salt construction MUST use the normative length-delimited serialization, including Application Profile Identifier and Version.
CanonicalReferenceRecord in cryptographic operations MUST mean the exact binary serialization defined in Section 30.
Hardware loss MUST NOT mutate an already issued Reference.
Stored canonical hardware_input MAY permit reproduction without physical access to the original hardware.
Reference derivation MUST NOT depend on a signature.
A future Cryptographic Profile MUST NOT silently alter an existing Profile Version.
A future Signature Profile MUST NOT silently alter an existing Signature Profile Version.
A future Hardware Profile MUST NOT silently alter an existing Hardware Profile Version.
Cryptographic migration MUST preserve historical Reference identity.
Reference Resolution and Reference Reproduction are distinct operations.
Protocol evolution SHOULD prefer Profile Versioning when the existing ARS architecture remains semantically valid.
ARS-1 MUST NOT require a particular classical public-key algorithm for its core Reference construction.
ARS-1 MUST preserve cryptographic agility as a protocol design property.
Different Reference Cryptographic Profiles are not required to derive the same Reference from the same entity context.
Historical References remain bound to their original Reference Cryptographic Profile and Reference Key context.
Cryptographic Profile migration MUST NOT silently replace a historical Reference.
Cryptographic Profile security targets are engineering designations, not permanent guarantees of future security.
A cryptographic Profile MUST NOT be treated as permanently immune to future quantum or classical cryptanalysis solely because it is designated as active.
A Profile Identity is the exact ordered pair of Profile Identifier and Profile Version.
Application Profile Identity is explicitly represented in the canonical Reference context and cryptographically bound to Reference Salt derivation.
Reference Cryptographic Profile Identity is explicitly represented in the canonical Reference context and cryptographically bound to key derivation.
New Reference issuance MUST obey the deployment's authenticated minimum Cryptographic Profile policy.
Historical reproduction MAY use the historical Cryptographic Profile context and MUST NOT silently substitute a different Profile.
ARS-1 core Profile identifiers are ASCII-only.
Unicode-enabled canonical fields MUST have a Profile-defined normalization form and fixed Unicode version.
Hardware Profile challenge construction MUST be deterministic and fully specified.
Hardware credential equivalence MUST be explicitly defined by the Hardware Profile when equivalence is claimed.
Hardware Profile output truncation and encoding MUST be explicitly versioned.
The checksum provides a 32-state checksum space. Its random collision probability is 1/32. This MUST NOT be interpreted as authentication or cryptographic integrity.
The ARS-1 checksum is a hash-truncation checksum. It has NO deterministic detection guarantee for any specific error class. Under the pseudorandom-function / random-oracle model, the expected miss probability for all error classes is 1/32.
Root Secret compromise does NOT invalidate historical References. Historical References remain canonical and do NOT need to be reissued. Reference identity stability is preserved.
Root Secret compromise causes loss of enumeration resistance for the compromised Root Secret domain, including ALL Reference Key Versions derived from that Root Secret. This loss is permanent and irrecoverable. To restore enumeration resistance for new issuance, the deployment MUST generate a NEW, independent Root Secret. Key Version rotation under the SAME Root Secret is NOT sufficient.
Reference Salt (Section 33) provides domain separation for public inputs but does NOT provide additional secret entropy. Salt-based domain separation does NOT limit the scope of a Root Secret compromise.
A deployment MAY adopt per-Namespace or per-Prefix Root Secrets for stronger isolation. ARS-1 v1 does NOT mandate a single-Root-Secret model.
Hardware Profile field order in canonical serialization is hardware_profile_id before hardware_profile_version, consistent with all other Profile field ordering.
A Profile Identifier MUST NOT include a version suffix. Version is always a separate field.
The ordered pair (Identifier, Version) is permanent and MUST NOT be reused for a different Profile definition.
ARS-1 defines three Canonical Profile Registries: Reference Cryptographic Profile Registry, Signature Profile Registry, and Hardware Profile Registry.
A Retired Profile MUST NOT be reactivated to Active status.
The Identifier prefix "ARS1-" is reserved for protocol-defined Profiles. Third-party Identifiers MAY use other prefixes. Deployments MUST NOT allocate Identifiers beginning with "ARS1-" without explicit protocol authorization.

ARS-1 separates:

from:

The intended long-term model is:

Therefore:

when:

or:

The purpose of cryptographic agility is not to predict the future algorithm. The purpose is to ensure that ARS does not need to predict it. A Cryptographic Profile migration may produce a different Reference for a newly derived Reference context. This is expected and does not constitute mutation of the historical Reference.

ARS should be understood as four independent layers:

No layer may implicitly replace another. Cryptographic algorithm migration SHOULD occur within the relevant layer and SHOULD NOT require cross-layer identity mutation.

Separately:

ARS-1 is not a prettier UUID . It is a: deterministic archival reference language for durable digital entities. Its defining visual property is: Prefix + naturally variable-length cryptographic Payload. It deliberately does not mandate one universal Payload length. Its defining technical property is: The same complete canonical conditions, applicable Cryptographic Profile, and same key material always produce exactly the same Reference across independent implementations. Its defining security property is: The algorithms are explicit and versioned. Security derives from high-entropy protected secret material and standardized cryptographic constructions rather than from obscurity. Its defining long-term property is: Cryptographic assumptions may evolve without requiring the reassignment of historical References. Its defining extensibility property is: Reference Cryptographic Profiles, Signature Profiles, and Hardware Profiles are independently versioned and replaceable. A future cryptographic transition SHOULD therefore look like:

rather than:

The protocol is designed not to predict which cryptographic assumptions will remain valid forever. It is designed so that ARS can survive when those assumptions change. For ARS-1:

constitute the protocol's long-term archival model. Profiles MAY define external lifecycle metadata such as expiration, revocation, or tombstone state. Such metadata MUST NOT alter the canonical Reference unless explicitly defined by a new protocol version. ARS-1 itself remains general-purpose and does not mandate any particular application-level Payload length or cryptographic signature algorithm.

The ars URI scheme is formally specified by -- ARS URI Scheme -- A URI Scheme for ARS-1 References, v1.0-rc2, available at <https://github.com/Juwan-Hwang/ARS-1/blob/main/spec/ARS-URI.md>. The ars URI scheme is registered as a provisional URI scheme in the IANA URI Schemes Registry (<https://www.iana.org/assignments/uri-schemes>), following the registration guidelines of and the URI syntax of . The ars URI scheme defines the syntax ars://<namespace>/<local-reference> for representing ARS-1 References as URIs. It includes the complete ABNF grammar, authority/path semantics, case sensitivity rules, percent-encoding rules, canonicalization, resolution semantics, and IANA provisional registration template. Conforming ARS-1 implementations are NOT required to support the ars URI form. The canonical ARS-1 Reference representation is always the Local Reference form defined in Section 21. Internationalized Resource Identifiers are out of scope for ARS-1 References, which use a restricted ASCII-compatible character set.

Key words for use in RFCs to Indicate Requirement Levels Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words Uniform Resource Identifier (URI): Generic Syntax Augmented BNF for Syntax Specifications: ABNF HMAC-based Extract-and-Expand Key Derivation Function (HKDF) Guidelines and Registration Procedures for URI Schemes A Universally Unique Identifier (UUID) URN Namespace Internationalized Resource Identifiers (IRIs) ARS URI Scheme: A URI Scheme for ARS-1 References

The ARS-1 protocol and its 23 independent implementations provided the foundation for this specification.