Independent Submission J. Hwang Internet-Draft 22 August 2026 Intended status: Informational Expires: 23 February 2027 ARS-1 -- Generic Archival Reference System draft-juwan-ars-00 Abstract 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 of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 February 2027. Hwang Expires 23 February 2027 [Page 1] Internet-Draft ARS-1 August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Normative Language . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol / Application Separation . . . . . . . . . . . . . . 6 5. Core Identity Architecture . . . . . . . . . . . . . . . . . 7 6. Determinism Invariant . . . . . . . . . . . . . . . . . . . . 8 7. Root Secret . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Root Secret Protection . . . . . . . . . . . . . . . . . . . 10 9. Cryptographic Key Separation . . . . . . . . . . . . . . . . 10 10. Reference Cryptographic Profile . . . . . . . . . . . . . . . 11 11. Cryptographic Agility . . . . . . . . . . . . . . . . . . . . 12 12. Reference Key Derivation . . . . . . . . . . . . . . . . . . 13 13. Reference Key Version . . . . . . . . . . . . . . . . . . . . 14 14. Protocol and Profile Version Separation . . . . . . . . . . . 15 15. Identity Generation . . . . . . . . . . . . . . . . . . . . . 16 16. Stable Entity Identity . . . . . . . . . . . . . . . . . . . 16 17. First Creation Time . . . . . . . . . . . . . . . . . . . . . 17 18. No Permanent Sequence Number . . . . . . . . . . . . . . . . 18 19. Namespace . . . . . . . . . . . . . . . . . . . . . . . . . . 18 20. Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 21. Prefix Registry . . . . . . . . . . . . . . . . . . . . . . . 19 22. Local Reference Grammar . . . . . . . . . . . . . . . . . . . 19 23. Qualified Reference . . . . . . . . . . . . . . . . . . . . . 19 24. Canonical Payload Alphabet . . . . . . . . . . . . . . . . . 20 25. Human Readability . . . . . . . . . . . . . . . . . . . . . . 22 26. Variable-Length Payload . . . . . . . . . . . . . . . . . . . 22 27. Public Data Domain . . . . . . . . . . . . . . . . . . . . . 23 28. Natural Variable-Length Encoding . . . . . . . . . . . . . . 23 29. Canonical Encode / Decode Invariants . . . . . . . . . . . . 24 30. Canonical Reference Record . . . . . . . . . . . . . . . . . 24 31. Binary Serialization . . . . . . . . . . . . . . . . . . . . 25 32. String Normalization and Identifier Encoding . . . . . . . . 27 33. Entity Identity Encoding . . . . . . . . . . . . . . . . . . 27 34. Reference Salt . . . . . . . . . . . . . . . . . . . . . . . 28 35. Reference Material Derivation . . . . . . . . . . . . . . . . 29 Hwang Expires 23 February 2027 [Page 2] Internet-Draft ARS-1 August 2026 36. Reference Material Domain Separation . . . . . . . . . . . . 30 37. Public Data Extraction . . . . . . . . . . . . . . . . . . . 30 38. Base32 Encoding . . . . . . . . . . . . . . . . . . . . . . . 31 39. Payload Length . . . . . . . . . . . . . . . . . . . . . . . 32 40. Collision Guidance . . . . . . . . . . . . . . . . . . . . . 32 41. Predictability and Enumeration Resistance . . . . . . . . . . 33 42. Collision Handling . . . . . . . . . . . . . . . . . . . . . 34 43. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . 34 44. Checksum Placement . . . . . . . . . . . . . . . . . . . . . 35 45. Checksum Verification . . . . . . . . . . . . . . . . . . . . 35 46. Checksum Security Boundary . . . . . . . . . . . . . . . . . 36 47. Hardware Profile Semantics . . . . . . . . . . . . . . . . . 37 48. Hardware Input Architecture . . . . . . . . . . . . . . . . . 38 49. Hardware Profile Contract . . . . . . . . . . . . . . . . . . 38 50. Canonical Hardware Input . . . . . . . . . . . . . . . . . . 39 51. Hardware Profile Versioning and Agility . . . . . . . . . . . 40 52. Hardware Is an Issuance Input, Not a Runtime Resolution Dependency . . . . . . . . . . . . . . . . . . . . . . . 40 53. Hardware Reproduction Modes . . . . . . . . . . . . . . . . . 41 54. YubiKey Compatibility . . . . . . . . . . . . . . . . . . . . 41 55. User Presence . . . . . . . . . . . . . . . . . . . . . . . . 42 56. Hardware Recovery . . . . . . . . . . . . . . . . . . . . . . 42 57. Digital Signatures . . . . . . . . . . . . . . . . . . . . . 42 58. Signature Key Separation . . . . . . . . . . . . . . . . . . 43 59. Signature Profile . . . . . . . . . . . . . . . . . . . . . . 43 60. Signature Migration . . . . . . . . . . . . . . . . . . . . . 44 61. Signature Message . . . . . . . . . . . . . . . . . . . . . . 44 62. Content Integrity . . . . . . . . . . . . . . . . . . . . . . 45 63. Post-Quantum Security Position . . . . . . . . . . . . . . . 46 64. Post-Quantum Migration Principle . . . . . . . . . . . . . . 46 65. Reference Resolution . . . . . . . . . . . . . . . . . . . . 48 66. Reference Reproduction . . . . . . . . . . . . . . . . . . . 48 67. Reference Verification Levels . . . . . . . . . . . . . . . . 49 67.1. Level 1 -- Syntax . . . . . . . . . . . . . . . . . . . 49 67.2. Level 2 -- Checksum . . . . . . . . . . . . . . . . . . 49 67.3. Level 3 -- Canonicality . . . . . . . . . . . . . . . . 49 67.4. Level 4 -- Cryptographic Reproduction . . . . . . . . . 50 67.5. Level 5 -- Resolution . . . . . . . . . . . . . . . . . 50 68. Public Reference vs Authorization . . . . . . . . . . . . . . 50 69. Permanent Non-Reuse . . . . . . . . . . . . . . . . . . . . . 50 70. Semantic URL Independence . . . . . . . . . . . . . . . . . . 51 71. Canonical URL . . . . . . . . . . . . . . . . . . . . . . . . 51 72. Export / Import . . . . . . . . . . . . . . . . . . . . . . . 52 73. Key Rotation . . . . . . . . . . . . . . . . . . . . . . . . 53 74. Cryptographic Downgrade Resistance . . . . . . . . . . . . . 53 75. Cryptographic Profile Deprecation . . . . . . . . . . . . . . 54 76. Cryptographic Profile Migration . . . . . . . . . . . . . . . 55 77. Protocol Versioning . . . . . . . . . . . . . . . . . . . . . 56 Hwang Expires 23 February 2027 [Page 3] Internet-Draft ARS-1 August 2026 78. Application Profile Requirements . . . . . . . . . . . . . . 56 79. Example Application Profile . . . . . . . . . . . . . . . . . 57 80. Formal Test Vector . . . . . . . . . . . . . . . . . . . . . 58 80.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 59 80.2. Canonical Reference Record . . . . . . . . . . . . . . . 60 80.3. Reference Key . . . . . . . . . . . . . . . . . . . . . 60 80.4. Reference Salt Input . . . . . . . . . . . . . . . . . . 60 80.5. Reference Salt . . . . . . . . . . . . . . . . . . . . . 60 80.6. Reference Material . . . . . . . . . . . . . . . . . . . 60 80.7. Public Data . . . . . . . . . . . . . . . . . . . . . . 61 80.8. Canonical Data . . . . . . . . . . . . . . . . . . . . . 61 80.9. Checksum Body . . . . . . . . . . . . . . . . . . . . . 61 80.10. Checksum Digest . . . . . . . . . . . . . . . . . . . . 61 80.11. Final Canonical Reference . . . . . . . . . . . . . . . 61 81. Negative Verification Vector . . . . . . . . . . . . . . . . 61 82. Independent Implementation Requirement . . . . . . . . . . . 62 83. Reference Implementation . . . . . . . . . . . . . . . . . . 62 84. Encoder / Decoder Property Tests . . . . . . . . . . . . . . 63 85. Security Considerations . . . . . . . . . . . . . . . . . . . 64 86. Root Secret Compromise Response . . . . . . . . . . . . . . . 65 86.1. Derivation Structure and Compromise Scope . . . . . . . 66 86.2. Security Properties After Compromise . . . . . . . . . . 66 86.3. Compromise Response Procedure . . . . . . . . . . . . . 67 86.4. Post-Rotation Security Property Summary . . . . . . . . 68 86.5. High-Security Deployment Guidance . . . . . . . . . . . 68 87. Profile Identifier Uniqueness . . . . . . . . . . . . . . . . 69 88. ARS Profile Registry Model . . . . . . . . . . . . . . . . . 69 88.1. Registry Required Fields . . . . . . . . . . . . . . . . 70 88.2. Registry Lifecycle Status Values . . . . . . . . . . . . 70 88.3. Identifier Allocation Rules . . . . . . . . . . . . . . 71 88.4. Version Allocation Rules . . . . . . . . . . . . . . . . 72 88.5. Change Controller . . . . . . . . . . . . . . . . . . . 72 88.6. Canonical Registry Publication . . . . . . . . . . . . . 73 89. Canonical Profile Registry -- Initial Entries . . . . . . . . 73 89.1. ARS Reference Cryptographic Profile Registry . . . . . . 73 89.2. ARS Hardware Profile Registry . . . . . . . . . . . . . 73 89.3. ARS Signature Profile Registry . . . . . . . . . . . . . 74 90. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 91. Hard Invariants . . . . . . . . . . . . . . . . . . . . . . . 74 92. Long-Term Security Position . . . . . . . . . . . . . . . . . 80 93. Security Model . . . . . . . . . . . . . . . . . . . . . . . 81 94. Final Architecture . . . . . . . . . . . . . . . . . . . . . 82 95. Final Principle . . . . . . . . . . . . . . . . . . . . . . . 83 ARS URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 85 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Normative References . . . . . . . . . . . . . . . . . . . . . 86 Informative References . . . . . . . . . . . . . . . . . . . . 86 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 87 Hwang Expires 23 February 2027 [Page 4] Internet-Draft ARS-1 August 2026 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 87 1. Introduction *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. 2. Abstract ARS-1 defines a deterministic, human-oriented, cryptographically derived reference protocol for assigning stable public References to durable digital entities. Typical visual forms include: NX-174932 CJ3-106 MR-X4928 KX4-7B19Q2 ARS does not assign business meaning to Prefixes. For example: NX -> Project is an Application Profile decision, not an ARS-1 rule. ARS-1 defines: Hwang Expires 23 February 2027 [Page 5] Internet-Draft ARS-1 August 2026 Cryptographic Identity Deterministic Derivation Namespace Prefix Registry Canonical Serialization Variable-Length Encoding Checksum Optional Hardware Input Optional Digital Signature Cryptographic Agility Versioning Portability Reference Resolution Reference Reproduction 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. 3. Normative Language 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 [RFC2119] and [RFC8174]. A conforming implementation MUST treat all normative serialization, derivation, encoding, verification, migration, and versioning rules as exact protocol requirements. 4. Protocol / Application Separation ARS-1 defines the protocol. Hwang Expires 23 February 2027 [Page 6] Internet-Draft ARS-1 August 2026 ARS-1 | +-- Reference Grammar +-- Cryptographic Derivation Interface +-- Canonical Serialization +-- Encoding +-- Checksum +-- Hardware Input Interface +-- Cryptographic Profile Interface +-- Signature Profile Interface +-- Verification +-- Resolution Semantics +-- Reproduction Semantics +-- Migration Semantics +-- Protocol Versioning | [U+25BC] Application Profile | +-- Namespace +-- Prefix Registry +-- Entity Identity Format +-- Reference Cryptographic Profile +-- Reference Key Policy +-- Data Bit Length +-- Maximum Payload Length +-- Checksum Policy +-- Hardware Profile +-- Signature Profile +-- Collision Policy +-- URL Policy ARS-1 MUST NOT require any specific: Namespace Prefix database hardware vendor URL structure entity model UI convention cryptographic signature algorithm 5. Core Identity Architecture ARS separates the following mechanisms: Hwang Expires 23 February 2027 [Page 7] Internet-Draft ARS-1 August 2026 Root Secret v Reference Cryptographic Profile v Reference Key v Reference Material v Public Reference Optional: Hardware Secret v Hardware Profile v Canonical Challenge v Deterministic Hardware Response v Canonical Hardware Input Independent: Signing Key v Signature Profile v Digital Signature Independent: State Root / Content Hash v Historical Content Integrity These mechanisms MUST NOT be treated as interchangeable. 6. Determinism Invariant Let: T = CanonicalReferenceRecord K = Reference Key P = Reference Cryptographic Profile Then: Hwang Expires 23 February 2027 [Page 8] Internet-Draft ARS-1 August 2026 R = F(T, K, P) MUST satisfy: T1 = T2 K1 = K2 P1 = P2 v F(T1, K1, P1) = F(T2, K2, P2) Reference derivation MUST NOT depend on hidden runtime state. The following MUST NOT affect Reference derivation unless explicitly included in a canonical protocol field: random() nonce current time database sequence process ID machine ID MAC address thread state memory address filesystem ordering network state runtime entropy 7. Root Secret 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 = 256 bits 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. Hwang Expires 23 February 2027 [Page 9] Internet-Draft ARS-1 August 2026 8. Root Secret Protection 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: OS Key Store Encrypted Keystore HSM Secure Element TPM-backed storage 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. 9. Cryptographic Key Separation 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: Root Secret | +-- reference-root +-- export +-- future purpose-specific domains A Signing Private Key MUST NOT be treated as the Root Secret. Hwang Expires 23 February 2027 [Page 10] Internet-Draft ARS-1 August 2026 A Hardware Response Secret MUST NOT be treated as the Root Secret. 10. Reference Cryptographic Profile A Reference Cryptographic Profile defines the cryptographic construction used to derive a Reference. A Profile MUST define at least: profile identifier profile version security target root secret requirements key derivation algorithm hash or PRF algorithm Reference Key construction Reference Material construction Reference Material length domain separation rules security assumptions deprecation status The Profile is part of the ARS Reference context. A Profile's cryptographic identity is the ordered pair: profile identifier profile version 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: Hwang Expires 23 February 2027 [Page 11] Internet-Draft ARS-1 August 2026 Profile Identifier: ARS1-REF Profile Version: 1 Security Target: approximately 128-bit classical symmetric security under the security assumptions of the selected primitives Root Secret: 256 bits Reference Key: 256 bits KDF: HKDF-SHA-256 Reference Material: 256 bits 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. 11. Cryptographic Agility 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: Hwang Expires 23 February 2027 [Page 12] Internet-Draft ARS-1 August 2026 hash function KDF PRF construction Root Secret size Reference Key size Reference Material size domain separation construction security target provided the new Profile is explicitly versioned. A future Signature Profile MAY change: signature algorithm public-key representation signature encoding certificate representation security target without altering the associated Public Reference. A future Hardware Profile MAY change: challenge construction hardware operation response algorithm truncation encoding hardware credential mechanism security target 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. 12. Reference Key Derivation For Reference Cryptographic Profile profile_id, version profile_version, and Reference Key Version v: Hwang Expires 23 February 2027 [Page 13] Internet-Draft ARS-1 August 2026 PRK = HKDF-Extract( salt = UTF8("ARS-1/reference-root-salt"), IKM = RootSecret ) Then: ReferenceKey(v) = HKDF-Expand( PRK, info = UTF8("ARS-1/reference-root/v") || UINT8(length(PROFILE_ID_BYTES)) || PROFILE_ID_BYTES || UINT16_BE(profile_version) || UINT32_BE(v), L = 32 ) 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: 32 bytes 256 bits ARS-1 Reference Cryptographic Profile Version 1 uses HKDF-SHA-256 [RFC5869]. Future Profiles MAY define a different key derivation construction. 13. Reference Key Version Every Reference Key has an explicit version: 1 2 3 ... Reference Key Version MUST be part of the canonical Reference context. Hwang Expires 23 February 2027 [Page 14] Internet-Draft ARS-1 August 2026 Changing Reference Key Version MUST NOT rewrite historical References. Example: v1 -> 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. 14. Protocol and Profile Version Separation ARS distinguishes at least: protocol_version application_profile_id application_profile_version reference_cryptographic_profile_id reference_cryptographic_profile_version reference_key_version hardware_profile_id hardware_profile_version 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. Hwang Expires 23 February 2027 [Page 15] Internet-Draft ARS-1 August 2026 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. 15. Identity Generation An Application Profile MAY define an Identity Generation value. Default type: uint32 Identity Generation distinguishes different long-lived cryptographic identity contexts. It is NOT: entity number creation sequence revision number Example: Identity Generation = 1 After an explicit identity-generation transition: Identity Generation = 2 16. Stable Entity Identity Every Referenceable Entity MUST have an immutable Entity Identity. Permitted forms MAY include: UUID UUIDv7 ULID application-defined immutable identifier Entity Identity is the durable identity of the entity. Hwang Expires 23 February 2027 [Page 16] Internet-Draft ARS-1 August 2026 It does not need to resemble the Public Reference. A database primary key MUST NOT automatically be assumed to be an ARS Public Reference. 17. First Creation Time 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: UTC milliseconds since Unix Epoch uint64 Example: 2026-08-20T12:34:56.789Z 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: Entity Identity + Reference Context defines the cryptographic identity of the Reference, while: First Creation Time remains immutable archival metadata associated with the entity. Hwang Expires 23 February 2027 [Page 17] Internet-Draft ARS-1 August 2026 18. No Permanent Sequence Number ARS-1 does not use: entity #1 entity #2 entity #3 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. 19. Namespace Namespace defines the interpretation scope of a Reference. A Namespace MAY represent: website application organization repository tenant dataset archive Namespace semantics are application-defined. 20. Prefix Prefix is a Namespace-local semantic series identifier. ARS-1 syntax: one uppercase letter followed by 1-3 uppercase alphanumeric total length: 2 to 4 characters Recommended length: 2-4 characters ARS-1 does not define global Prefix semantics. Example: Hwang Expires 23 February 2027 [Page 18] Internet-Draft ARS-1 August 2026 NX -> Project CJ3 -> Writing MR -> Media is valid only when the corresponding Application Profile defines those meanings. 21. Prefix Registry 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. 22. Local Reference Grammar A Local Reference has the form: - Example: NX-17A492Q A Local Reference MAY be embedded directly in a URL: https://example.com/NX-17A492Q 23. Qualified Reference A system operating across multiple Namespaces MAY use a qualified form: AEV:NX-17A492Q An implementation MAY represent an ARS reference using a URI-like notation such as: Hwang Expires 23 February 2027 [Page 19] Internet-Draft ARS-1 August 2026 ars://AEV/NX-17A492Q This notation is defined by [ARSURI], which formally registers the ars URI scheme and defines its complete ABNF grammar [RFC5234], 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. 24. Canonical Payload Alphabet The normative ARS-1 alphabet is: 0123456789ABCDEFGHJKMNPQRSTVWXYZ Alphabet indices are: Hwang Expires 23 February 2027 [Page 20] Internet-Draft ARS-1 August 2026 0 -> 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: 32 symbols 5 bits per symbol The following characters are excluded: I L O U The alphabet is: Hwang Expires 23 February 2027 [Page 21] Internet-Draft ARS-1 August 2026 ASCII-only alphanumeric-only canonically uppercase URL-safe Only uppercase letters are permitted in canonical output. 25. Human Readability The alphabet intentionally excludes the visually ambiguous letters: I L O U The characters: 0 1 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: 0 / O 1 / I / L 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. 26. Variable-Length Payload 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: Hwang Expires 23 February 2027 [Page 22] Internet-Draft ARS-1 August 2026 CJ3-106 MR-X4928 NX-17A492Q KX4-7B19Q2 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. 27. Public Data Domain An Application Profile defines: data_bits 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. 28. Natural Variable-Length Encoding 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: remove every leading symbol whose alphabet index = 0 retain at least one symbol Because alphabet index 0 maps to: 0 Hwang Expires 23 February 2027 [Page 23] Internet-Draft ARS-1 August 2026 leading 0 symbols are omitted from the canonical representation. The all-zero data value is encoded as: 0 and never as an empty string. 29. Canonical Encode / Decode Invariants Let: Encode(x) = canonical payload Decode(s) = underlying data value A conforming implementation MUST satisfy: Decode(Encode(x)) = x and: Encode(Decode(s)) = s for every accepted canonical string. A decoder MUST reject non-canonical encodings. For example, if: ABC is canonical, then: 0ABC MUST NOT be accepted as an alternative canonical representation. 30. Canonical Reference Record The canonical Reference record is: Hwang Expires 23 February 2027 [Page 24] Internet-Draft ARS-1 August 2026 protocol_version application_profile_id application_profile_version reference_cryptographic_profile_id reference_cryptographic_profile_version namespace prefix entity_identity identity_generation reference_key_version hardware_profile_id hardware_profile_version hardware_input 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. 31. Binary Serialization All integer values use unsigned big-endian encoding. Canonical field types: Hwang Expires 23 February 2027 [Page 25] Internet-Draft ARS-1 August 2026 protocol_version uint16 application_profile_id uint8 length + UTF-8 bytes application_profile_version uint16 reference_cryptographic_profile_id uint8 length + UTF-8 bytes reference_cryptographic_profile_version uint16 namespace uint16 length + UTF-8 bytes prefix uint8 length + UTF-8 bytes entity_identity uint16 length + UTF-8 bytes identity_generation uint32 reference_key_version uint32 hardware_profile_id uint8 length + UTF-8 bytes hardware_profile_version uint16 hardware_input uint16 length + raw bytes 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. Hwang Expires 23 February 2027 [Page 26] Internet-Draft ARS-1 August 2026 32. String Normalization and Identifier Encoding The following textual fields MUST be normalized before serialization: application_profile_id reference_cryptographic_profile_id namespace prefix entity_identity hardware_profile_id For ARS-1 core identifiers, the following fields MUST use ASCII bytes only: application_profile_id reference_cryptographic_profile_id hardware_profile_id 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: ASCII-only Unicode NFC with an explicitly fixed Unicode version 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. 33. Entity Identity Encoding 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. Hwang Expires 23 February 2027 [Page 27] Internet-Draft ARS-1 August 2026 For example, only one of the following may be canonical: 0198f3c7-7e8d-7c12-a5e1-000000000001 or: 0198F3C7-7E8D-7C12-A5E1-000000000001 The Profile MUST NOT permit both as canonical encodings. 34. Reference Salt Define: APP_PROFILE_ID_BYTES = UTF8(application_profile_id) PROFILE_ID_BYTES = UTF8(reference_cryptographic_profile_id) NAMESPACE_BYTES = UTF8(namespace) PREFIX_BYTES = UTF8(prefix) Then: SALT_INPUT = UTF8("ARS-1/reference-salt") || UINT8(length(APP_PROFILE_ID_BYTES)) || APP_PROFILE_ID_BYTES || UINT16_BE(application_profile_version) || UINT8(length(PROFILE_ID_BYTES)) || PROFILE_ID_BYTES || UINT16_BE(reference_cryptographic_profile_version) || UINT32_BE(reference_key_version) || UINT16_BE(length(NAMESPACE_BYTES)) || NAMESPACE_BYTES || UINT8(length(PREFIX_BYTES)) || PREFIX_BYTES Then: SALT = SHA256(SALT_INPUT) 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. Hwang Expires 23 February 2027 [Page 28] Internet-Draft ARS-1 August 2026 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. 35. Reference Material Derivation For Reference Cryptographic Profile Version 1, first derive the Reference Key using the exact Reference Cryptographic Profile Identifier and Version: PRK = HKDF-Extract( salt = UTF8("ARS-1/reference-root-salt"), IKM = RootSecret ) RK = HKDF-Expand( PRK, info = UTF8("ARS-1/reference-root/v") || UINT8(length(PROFILE_ID_BYTES)) || PROFILE_ID_BYTES || UINT16_BE(reference_cryptographic_profile_version) || UINT32_BE(reference_key_version), L = 32 ) Then: PRK2 = HKDF-Extract( salt = SALT, IKM = RK ) Then: Hwang Expires 23 February 2027 [Page 29] Internet-Draft ARS-1 August 2026 ReferenceMaterial = HKDF-Expand( PRK2, info = UTF8("ARS-1/public-reference") || CanonicalReferenceRecord, L = 32 ) 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. 36. Reference Material Domain Separation The following domain strings are normative for Reference Cryptographic Profile Version 1: ARS-1/reference-root-salt ARS-1/reference-root/v ARS-1/reference-salt ARS-1/public-reference ARS-1/checksum ARS-1/signature/v1 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. 37. Public Data Extraction 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: Hwang Expires 23 February 2027 [Page 30] Internet-Draft ARS-1 August 2026 data_bits maximum_payload_length The checksum is 1 symbol (5 bits) as defined by the protocol. The Public Data domain is exactly: 2^data_bits possible values. Increasing the cryptographic strength of the underlying Reference derivation does not automatically increase the public collision domain. 38. Base32 Encoding For each 5-bit group: 0 -> 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 Hwang Expires 23 February 2027 [Page 31] Internet-Draft ARS-1 August 2026 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. 39. Payload Length An Application Profile MUST specify: data_bits maximum_payload_length 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. 40. Collision Guidance For approximately n independently distributed issued values, the birthday-bound approximation is: p ~= n^2 / 2^(data_bits + 1) 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: Hwang Expires 23 February 2027 [Page 32] Internet-Draft ARS-1 August 2026 Root Secret entropy Reference Key size Reference Material size checksum size 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: P(collision) = 1 - e^(-n(n-1) / (2 * 2^b)) For small probabilities, this simplifies to: P ~= n^2 / (2 * 2^b) To determine the required data_bits for a target collision probability P_target and expected lifetime issuance volume n: b >= log2(n^2 / (2 * P_target)) For example, for P_target = 0.5 (50% birthday bound), the exact threshold is: n ~= sqrt(2 * 2^b * ln 2) ~= 1.1774 * 2^(b/2) For data_bits = 40, this yields: n ~= 1.1774 * 2^20 ~= 1.234 * 10^6 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. 41. Predictability and Enumeration Resistance 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. Hwang Expires 23 February 2027 [Page 33] Internet-Draft ARS-1 August 2026 Therefore: Determinism != Public Predictability Collision resistance and enumeration resistance are separate security properties. A larger public data domain does not by itself provide authentication or authorization. 42. Collision Handling 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: random salt retry nonce database sequence current timestamp machine identifier runtime entropy A collision MAY be resolved only by an explicit change of canonical profile inputs, such as: Namespace Prefix Application Profile Version Entity Identity Identity Generation Reference Cryptographic Profile Version Reference Key Version Such a change creates a distinct canonical Reference context. Applications SHOULD detect collisions before committing a Reference as issued. 43. Checksum ARS-1 defines a deterministic 5-bit hash-derived checksum. For: canonical_body = PREFIX + "-" + canonical_data Hwang Expires 23 February 2027 [Page 34] Internet-Draft ARS-1 August 2026 calculate: digest = SHA256( UTF8("ARS-1/checksum") || UTF8(canonical_body) ) 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. 44. Checksum Placement 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. 45. Checksum Verification A verifier performs: 1. Parse Prefix. 2. Parse Payload. 3. Separate the final Payload symbol as checksum. 4. Treat preceding symbols as canonical data. 5. Reconstruct PREFIX + "-" + DATA. 6. Compute SHA256("ARS-1/checksum" || body). 7. Take the first 5 bits. 8. Map through the ARS-1 alphabet. 9. Compare against the supplied checksum. Checksum verification does not require database access. Hwang Expires 23 February 2027 [Page 35] Internet-Draft ARS-1 August 2026 46. Checksum Security Boundary 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: human-error detector and NOT: Hwang Expires 23 February 2027 [Page 36] Internet-Draft ARS-1 August 2026 authentication authorization signature MAC proof of provenance cryptographic identity 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. 47. Hardware Profile Semantics A Hardware Profile is identified by: hardware_profile_id hardware_profile_version 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: protocol_version application_profile_id application_profile_version reference_cryptographic_profile_id reference_cryptographic_profile_version namespace prefix entity_identity identity_generation reference_key_version hardware_profile_id hardware_profile_version 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. Hwang Expires 23 February 2027 [Page 37] Internet-Draft ARS-1 August 2026 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. 48. Hardware Input Architecture Hardware is OPTIONAL. ARS-1 defines: Hardware Profile v Canonical Challenge v Hardware Operation v Deterministic Hardware Response v Canonical Hardware Input Possible implementations include: YubiKey TPM HSM Smart Card Secure Enclave Secure Element other secure hardware ARS-1 does not depend on any vendor. 49. Hardware Profile Contract A Hardware Profile MUST define: Hwang Expires 23 February 2027 [Page 38] Internet-Draft ARS-1 August 2026 profile identifier profile version challenge construction hardware operation response algorithm input encoding output encoding security assumptions recovery procedure cryptographic status security target For Reference derivation, a conforming Hardware Profile MUST guarantee: same profile + same canonical challenge + same hardware secret = same deterministic response Uncontrolled randomness MUST NOT affect the Reference-derived hardware output. 50. Canonical Hardware Input ARS does not interpret vendor-specific hardware internals. Instead: Hardware Profile v deterministic hardware response v Profile-defined canonical byte representation v hardware_input 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. Hwang Expires 23 February 2027 [Page 39] Internet-Draft ARS-1 August 2026 51. Hardware Profile Versioning and Agility Hardware Profile Version MUST be explicit. A future incompatible construction MUST use a new version. A Profile MUST NOT silently change: challenge construction response derivation truncation output encoding hardware algorithm 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. 52. Hardware Is an Issuance Input, Not a Runtime Resolution Dependency This is a hard ARS-1 invariant. If hardware participates in Reference generation: Reference = F( canonical entity inputs, ReferenceKey, hardware_input ) hardware MAY be required for: issuance reproduction migration recovery verification Hwang Expires 23 February 2027 [Page 40] Internet-Draft ARS-1 August 2026 but ordinary Reference Resolution MUST NOT require the hardware to be present after issuance when the application already maintains the Reference -> Entity association. Therefore: /NX-17A492Q MUST remain resolvable without an attached hardware device. Loss of issuance hardware MUST NOT invalidate an already issued Reference. 53. Hardware Reproduction Modes A deployment MAY preserve hardware_input as part of the historical Reference record. When hardware_input is retained: Reference Reproduction 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. 54. YubiKey Compatibility 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. Hwang Expires 23 February 2027 [Page 41] Internet-Draft ARS-1 August 2026 55. User Presence A Hardware Profile MAY require: touch PIN local user approval 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. 56. Hardware Recovery An Application Profile using Hardware-Bound References MUST define a recovery strategy. Permitted strategies MAY include: secondary hardware recovery key secure duplicate hardware pre-issued immutable Reference mapping stored canonical hardware_input 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. 57. Digital Signatures 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. Hwang Expires 23 February 2027 [Page 42] Internet-Draft ARS-1 August 2026 * 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. 58. Signature Key Separation Signing Private Keys MUST be separate from: Root Secret Reference Key Hardware response secret A signing implementation SHOULD generate its signing key independently. A hardware-backed signing key MAY be stored in: YubiKey PIV TPM HSM Smart Card Secure Enclave 59. Signature Profile A Signature Profile MUST define: profile identifier profile version algorithm hash function, if applicable key type public-key encoding signature encoding certificate format, if applicable canonical message format security assumptions cryptographic status security target ARS-1 does not prescribe one permanent signature algorithm. Hwang Expires 23 February 2027 [Page 43] Internet-Draft ARS-1 August 2026 Signature Profiles MAY be classified as: Classical Post-Quantum Hybrid 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. 60. Signature Migration A Signature Profile MAY be deprecated, superseded, or retired. Deprecating a Signature Profile MUST NOT invalidate: Entity Identity Public Reference historical record historical content association 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: Reference +-- historical signature +-- current signature without changing the Reference. A cryptographic signature MUST NOT be treated as the permanent identity of the entity. 61. Signature Message A recommended signing context is: Hwang Expires 23 February 2027 [Page 44] Internet-Draft ARS-1 August 2026 ARS-1/signature/v1 + Namespace + Reference + State Root / Record Hash 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. 62. Content Integrity A Reference does not prove the exact historical contents of an entity. Applications requiring historical integrity SHOULD use: Content Hash State Root Merkle Root Immutable Object Graph Conceptually: Reference -> 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. Hwang Expires 23 February 2027 [Page 45] Internet-Draft ARS-1 August 2026 63. Post-Quantum Security Position 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: 256-bit Root Secret HKDF-SHA-256 SHA-256 256-bit Reference Material 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: classical security quantum resistance under current understanding long-term cryptographic agility archival identity stability A Profile MAY be cryptographically suitable for current deployment without being treated as permanently safe against all future cryptanalytic advances. 64. Post-Quantum Migration Principle Post-quantum migration MUST occur at the cryptographic Profile layer wherever possible. A deployment MUST prefer: Hwang Expires 23 February 2027 [Page 46] Internet-Draft ARS-1 August 2026 new cryptographic Profile v new cryptographic mechanism v same Entity Identity semantics v historical References preserved rather than: new cryptographic algorithm v reissue every historical Reference 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: Entity E Profile v1 Key v1 v Reference R1 and later: Entity E Profile v2 Key v2 v Reference R2 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: historical Reference preservation Hwang Expires 23 February 2027 [Page 47] Internet-Draft ARS-1 August 2026 from: future Reference issuance When a Cryptographic Profile becomes deprecated or unsafe, the deployment SHOULD: stop issuing new References under the affected Profile preserve historical Profile metadata preserve historical References introduce a replacement Profile migrate signatures or supporting credentials A cryptographic transition MUST NOT silently reinterpret an existing Reference as though it had been issued under a different Profile. 65. Reference Resolution Reference Resolution means: Reference -> Entity Resolution is an application-state operation. A system MAY resolve a syntactically valid and checksum-valid Reference to: existing entity retired entity tombstone missing entity 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. 66. Reference Reproduction Reference Reproduction means: Hwang Expires 23 February 2027 [Page 48] Internet-Draft ARS-1 August 2026 Canonical Reference Inputs + Reference Cryptographic Profile + Reference Key + Hardware Input, if required v Reference A conforming implementation MUST reproduce the exact canonical Reference. Reproduction is cryptographic. Resolution is application-state based. The two operations MUST NOT be conflated. 67. Reference Verification Levels A verifier MAY operate at multiple levels. 67.1. Level 1 -- Syntax Verify: Prefix syntax Payload alphabet separator canonical casing maximum length 67.2. Level 2 -- Checksum Verify: checksum 67.3. Level 3 -- Canonicality Verify: canonical Base32 representation canonical Prefix canonical Payload form Hwang Expires 23 February 2027 [Page 49] Internet-Draft ARS-1 August 2026 67.4. Level 4 -- Cryptographic Reproduction Given: Root Secret Reference Cryptographic Profile Application Profile canonical entity inputs Hardware Input, where required reproduce the Reference and compare character-for-character. 67.5. Level 5 -- Resolution Use application state: Reference -> Entity No lower verification level implicitly proves a higher one. 68. Public Reference vs Authorization A valid Reference MUST NOT imply: permission ownership authentication authorization Applications MUST enforce authorization independently. Knowledge of a Reference MUST NOT itself grant privileged access. 69. Permanent Non-Reuse Once an ARS Reference has been issued: delete entity trash purge import migration restore rename move reparent cryptographic Profile migration signature migration hardware Profile migration Hwang Expires 23 February 2027 [Page 50] Internet-Draft ARS-1 August 2026 MUST NOT release the Reference for reassignment. A retired Reference MUST NOT be reassigned to an unrelated entity. 70. Semantic URL Independence Semantic routes MAY change: /lab/zephyr v /zephyr v projects/zephyr v zephyr.example.com The ARS Reference remains stable: NX-17A492Q Therefore: Semantic URL = current information architecture. ARS Reference = durable identity locator. 71. Canonical URL 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: https://example.com/NX-FC5RT0TC0 A future cryptographic Profile MUST NOT require changing the canonical URL representation of an already issued Reference. Hwang Expires 23 February 2027 [Page 51] Internet-Draft ARS-1 August 2026 72. Export / Import A complete portable export MUST preserve all information necessary to reproduce existing References. At minimum: Root Secret secure backup Identity Generation Namespace Prefix Registry Entity Identity First Creation Time Application Profile Version Reference Cryptographic Profile Version Reference Key Version Hardware Profile and Version, if used stored canonical hardware_input, if retained by policy Application Profile Public Reference A complete archival export SHOULD also preserve: historical Signature Profiles historical signatures Signature Profile Versions cryptographic Profile metadata Profile security targets Profile status history 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: Original Reference = Imported Reference for identical canonical identity context, applicable Profile definitions, and required key material. Hwang Expires 23 February 2027 [Page 52] Internet-Draft ARS-1 August 2026 73. Key Rotation Key rotation MUST NOT rewrite historical References. Example: Reference Key v1 v historical References Reference Key v2 v new References 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. 74. Cryptographic Downgrade Resistance 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: Hwang Expires 23 February 2027 [Page 53] Internet-Draft ARS-1 August 2026 new issuance v current authenticated policy v minimum acceptable Profile vs. historical reproduction v historical Profile context v exact historical Reference 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. 75. Cryptographic Profile Deprecation Every Reference Cryptographic Profile SHOULD have an explicit lifecycle status: Active Deprecated Retired A Profile MAY become: Deprecated when a stronger or more appropriate Profile is available. A Profile MAY become: Retired 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. Hwang Expires 23 February 2027 [Page 54] Internet-Draft ARS-1 August 2026 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. 76. Cryptographic Profile Migration A cryptographic migration is the controlled introduction of a new Cryptographic Profile for future issuance or reproduction. A migration MUST identify: source Profile target Profile migration status effective issuance boundary historical preservation policy reproduction policy signature migration policy, if applicable hardware migration policy, if applicable A migration MUST preserve: Entity Identity historical Reference historical Profile Version historical Reference Key Version historical Reference mapping 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: current canonical Reference historical Reference alias migration successor No migration process may silently replace an existing historical Reference. Hwang Expires 23 February 2027 [Page 55] Internet-Draft ARS-1 August 2026 77. Protocol Versioning Protocol Version MUST identify the exact ARS construction. For example: ARS-1 defines this specification. A future: ARS-2 MAY change: serialization KDF architecture encoding checksum architecture Profile architecture Reference grammar 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. 78. Application Profile Requirements Every deployment SHOULD define: Hwang Expires 23 February 2027 [Page 56] Internet-Draft ARS-1 August 2026 Namespace Application Profile ID Prefix Registry Entity Identity format First Creation Time policy Reference Cryptographic Profile ID Reference Cryptographic Profile Version Reference Key Version policy Application Profile Version data_bits maximum_payload_length Checksum policy Hardware Profile Signature Profile URL policy backup policy key rotation policy export/import policy collision policy hardware recovery policy, if applicable cryptographic migration policy An Application Profile MAY be stricter than ARS-1. It MUST NOT weaken ARS-1 deterministic or canonical requirements. 79. Example Application Profile ARS-1 does not mandate any specific real-world Application Profile. An illustrative Profile MAY define: Hwang Expires 23 February 2027 [Page 57] Internet-Draft ARS-1 August 2026 Namespace: EXAMPLE Application Profile ID: PersonalArchive Application Profile Version: 1 Reference Cryptographic Profile ID: ARS1-REF Reference Cryptographic Profile Version: 1 data_bits: 40 maximum_payload_length: 9 The checksum is 1 symbol (5 bits) as fixed by the protocol. Example Prefix Registry: NX: Project CJ3: Writing MR: Media KX4: Experience The above is illustrative only. ARS-1 itself does not require 40-bit data, nine-symbol maximum Payloads, or any particular Prefix Registry. 80. Formal Test Vector The following vector is normative. It uses a test-only Application Profile and the ARS-1 Default Reference Cryptographic Profile Version 1. Hwang Expires 23 February 2027 [Page 58] Internet-Draft ARS-1 August 2026 All values below use the final ARS-1 alphabet: 0123456789ABCDEFGHJKMNPQRSTVWXYZ 80.1. Inputs Protocol Version: 1 Application Profile ID: Example-40 Application Profile Version: 1 Reference Cryptographic Profile ID: ARS1-REF Reference Cryptographic Profile Version: 1 Namespace: AEV Prefix: NX Entity Identity: 0198f3c7-7e8d-7c12-a5e1-000000000001 Identity Generation: 1 Reference Key Version: 1 Hardware Profile ID: NONE Hardware Profile Version: 1 Hardware Input: empty Root Secret: 00112233445566778899aabbccddeeff 00112233445566778899aabbccddeeff Hwang Expires 23 February 2027 [Page 59] Internet-Draft ARS-1 August 2026 First Creation Time exists in the entity record but is deliberately NOT part of the Reference derivation vector. The test Application Profile defines: data_bits: 40 maximum_payload_length: 9 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. 80.2. Canonical Reference Record Hexadecimal: 00010a4578616d706c652d3430000108415253312d524546 00010003414556024e58002430313938663363372d376538642d 376331322d613565312d30303030303030303030303100000001 00000001044e4f4e4500010000 80.3. Reference Key d017c2784b7727608283929f06497086cdbd680c9d7ffa73260ecbe68ed1a34f 80.4. Reference Salt Input 4152532d312f7265666572656e63652d73616c740a4578616d706c 652d3430000108415253312d5245460001000000010003414556024e58 80.5. Reference Salt 4a75371f00fffe18a072faaaae941c18905cab120649a37a6106974243ca1aad 80.6. Reference Material 6ddcc2caeddf82ea5f843ec7b48c145b4de5ee1a64f1bc0cd96d19579529f052 Hwang Expires 23 February 2027 [Page 60] Internet-Draft ARS-1 August 2026 80.7. Public Data First 40 bits: 6ddcc2caed 80.8. Canonical Data DQEC5JQD 80.9. Checksum Body NX-DQEC5JQD 80.10. Checksum Digest e66740721579883487c3e7afd8d2525f8aed5c04e7152f37868929579dc44661 80.11. Final Canonical Reference NX-DQEC5JQDW Any conforming ARS-1 implementation receiving exactly these inputs MUST produce the regenerated Final Canonical Reference character-for- character. 81. Negative Verification Vector 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: NX-DQEC5JQDX 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: ABC MUST NOT accept: Hwang Expires 23 February 2027 [Page 61] Internet-Draft ARS-1 August 2026 0ABC as an equivalent canonical Reference payload. 82. Independent Implementation Requirement A conforming implementation SHOULD pass: canonical serialization vectors Reference Cryptographic Profile vectors Reference Key vectors Reference Salt vectors Reference Material vectors Base32 vectors variable-length encoding vectors checksum vectors negative verification vectors Hardware Profile vectors Signature Profile vectors Profile migration vectors Profile identity separation vectors Cryptographic downgrade rejection vectors Hardware challenge construction vectors Hardware credential equivalence vectors At least two independently implemented implementations SHOULD be cross-tested. Recommended implementation languages include: Rust TypeScript / JavaScript Go Python 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. 83. Reference Implementation A production deployment SHOULD maintain a minimal reference implementation whose purpose is: Hwang Expires 23 February 2027 [Page 62] Internet-Draft ARS-1 August 2026 canonical serialization Reference Cryptographic Profile handling key derivation Reference Material derivation Base32 encoding / decoding checksum generation / verification Reference reproduction Profile verification test-vector generation 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. 84. Encoder / Decoder Property Tests A conforming implementation SHOULD test at least: Decode(Encode(x)) = x Encode(Decode(s)) = s for a large corpus of generated values. The corpus SHOULD include: all-zero values single-bit values boundary values values with leading zero Base32 groups maximum profile values random values Decoders SHOULD reject: Hwang Expires 23 February 2027 [Page 63] Internet-Draft ARS-1 August 2026 invalid alphabet characters lowercase output when canonical uppercase is required non-canonical leading-zero encodings invalid padding bits empty payloads payloads exceeding profile limits unknown checksum profiles unknown cryptographic Profiles unknown Profile Identifier + Version pairs malformed version fields unsupported Unicode version declarations invalid Hardware Profile challenge constructions Implementations SHOULD test that historical References remain reproducible after introducing a new Cryptographic Profile or Signature Profile. 85. Security Considerations 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 Hwang Expires 23 February 2027 [Page 64] Internet-Draft ARS-1 August 2026 * 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 [RFC5869] * 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 86. Root Secret Compromise Response 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. Hwang Expires 23 February 2027 [Page 65] Internet-Draft ARS-1 August 2026 86.1. Derivation Structure and Compromise Scope 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. 86.2. Security Properties After 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. Hwang Expires 23 February 2027 [Page 66] Internet-Draft ARS-1 August 2026 * 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. 86.3. Compromise Response Procedure A deployment that detects or suspects Root Secret compromise MUST: 1. Immediately generate a NEW, independent Root Secret using a CSPRNG. Do NOT derive the new Root Secret from the compromised Root Secret. 2. 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. 3. 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. 4. 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 Hwang Expires 23 February 2027 [Page 67] Internet-Draft ARS-1 August 2026 5. 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. 6. Document the compromise incident, affected Root Secret, affected key versions, and remediation actions as part of the archival record. 86.4. Post-Rotation Security Property Summary 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. 86.5. High-Security Deployment Guidance 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 Hwang Expires 23 February 2027 [Page 68] Internet-Draft ARS-1 August 2026 * 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) 87. Profile Identifier Uniqueness 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). 88. ARS Profile Registry Model ARS-1 defines a formal Profile Registry architecture consisting of three Canonical Profile Registries, each governing a distinct Profile type: Hwang Expires 23 February 2027 [Page 69] Internet-Draft ARS-1 August 2026 ARS-1 | +-- ARS Reference Cryptographic Profile Registry | Governs: Reference Cryptographic Profiles (Section 9) | +-- ARS Signature Profile Registry | Governs: Signature Profiles (Section 58) | +-- ARS Hardware Profile Registry Governs: Hardware Profiles (Section 46-50) 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). 88.1. Registry Required Fields 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. 88.2. Registry Lifecycle Status Values Hwang Expires 23 February 2027 [Page 70] Internet-Draft ARS-1 August 2026 * 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. 88.3. Identifier Allocation Rules Profile Identifiers are allocated on a first-come, first-served basis within each Registry, subject to review by the Change Controller. Identifier allocation rules: 1. An Identifier MUST be unique within its Registry. 2. An Identifier MUST NOT include a version suffix. Version is always a separate field. Hwang Expires 23 February 2027 [Page 71] Internet-Draft ARS-1 August 2026 3. An Identifier MUST be ASCII-only (Section 31). 4. An Identifier MUST be between 3 and 32 characters. 5. An Identifier SHOULD be mnemonic of the Profile's purpose. 6. 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"). 7. The Identifier "NONE" is reserved for the no-hardware Hardware Profile. 8. Once allocated, an Identifier is permanent and MUST NOT be renamed. 88.4. Version Allocation Rules 1. Versions are positive integers starting from 1. 2. 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. 3. An existing (Identifier, Version) pair MUST NOT be reused for a different Profile definition. 4. 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. 5. A Version that has been registered as Active, Deprecated, or Retired MUST NOT be silently redefined. 88.5. Change Controller The Change Controller for the ARS Canonical Profile Registries is the ARS-1 specification maintainer, currently the ARS-1 GitHub repository: https://github.com/Juwan-Hwang/ARS-1 The Change Controller is responsible for: Hwang Expires 23 February 2027 [Page 72] Internet-Draft ARS-1 August 2026 * 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. 88.6. Canonical Registry Publication 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). 89. Canonical Profile Registry -- Initial Entries 89.1. ARS Reference Cryptographic Profile Registry * 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 89.2. ARS Hardware Profile Registry * Identifier: NONE * Version: 1 Hwang Expires 23 February 2027 [Page 73] Internet-Draft ARS-1 August 2026 * Name: No Hardware Profile * Status: Active * Specification: ARS-1 Section 47 * Security Target: N/A (no hardware) * Change Controller: GitHub 89.3. ARS Signature Profile Registry 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. 90. IANA Considerations 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: GitHub Canonical Registry v Internet-Draft (IETF or independent submission) v IANA Registry creation request 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. 91. Hard Invariants ARS-1 MUST satisfy all of the following: Hwang Expires 23 February 2027 [Page 74] Internet-Draft ARS-1 August 2026 1. Identical canonical inputs under the same Reference Cryptographic Profile ID and Version produce identical References. 2. Reference derivation contains no hidden randomness. 3. Root Secrets are generated with a CSPRNG. 4. The selected Cryptographic Profile defines the required Root Secret security level. 5. Reference derivation uses an explicit Cryptographic Profile ID and Version. 6. Cryptographic purposes use independent derivation domains. 7. Entity Identity is immutable. 8. First Creation Time is immutable archival metadata when used by the Application Profile. 9. First Creation Time is not a Reference derivation input in ARS-1 v1. 10. Permanent identity does not depend on mutable titles or content. 11. Sequence numbers are not permanent identity unless explicitly profiled. 12. Payload length may naturally vary. 13. ARS-1 does not prescribe one universal Payload length. 14. Application Profiles define their own data-bit and length policies. 15. The ARS-1 alphabet contains exactly 32 ASCII alphanumeric symbols. 16. The ARS-1 alphabet contains no punctuation or other symbols. 17. Hardware is optional. 18. Hardware Profiles are vendor-neutral. 19. Hardware-derived Reference inputs are deterministic. 20. Hardware input is explicit canonical input. Hwang Expires 23 February 2027 [Page 75] Internet-Draft ARS-1 August 2026 21. Digital signatures do not determine the Reference. 22. Signature Profiles are independent from Reference derivation. 23. Signature Profiles are replaceable without rewriting historical References. 24. Checksum is deterministic. 25. Checksum is not cryptographic authentication. 26. Reference validity is not authorization. 27. Reference validity is not content integrity. 28. Historical References never change. 29. Historical References are never reused. 30. Export/import preserves References. 31. Key rotation does not rewrite historical References. 32. Prefix semantics are Namespace-local. 33. Prefix meanings cannot be silently reassigned. 34. Collision fallback cannot introduce hidden randomness. 35. A detected collision is an issuance failure unless canonical inputs are deliberately changed. 36. Canonical URLs are deterministic. 37. Canonical Base32 representations are unique. 38. Independent conforming implementations produce identical References. 39. Cryptographic algorithms are public. 40. Secret cryptographic material is never embedded in source code. 41. Protocol Version, Application Profile ID/Version, Reference Cryptographic Profile ID/Version, Reference Key Version and Hardware Profile ID/Version are distinct identity/version dimensions. Hwang Expires 23 February 2027 [Page 76] Internet-Draft ARS-1 August 2026 42. Signature Profile Version does not affect Reference derivation. 43. Cryptographic Profile changes MUST be explicit. 44. A deprecated Cryptographic Profile MUST NOT silently reinterpret historical References. 45. Historical References remain valid after Cryptographic Profile migration. 46. A Signature Profile may be migrated without changing the associated Reference. 47. Canonical References use uppercase output. 48. The ARS-1 alphabet excludes I, L, O and U. 49. The ARS-1 alphabet is exactly: 0123456789ABCDEFGHJKMNPQRSTVWXYZ 50. An empty canonical Payload is never valid. 51. Leading zero-valued Base32 symbols MUST be omitted in canonical encoding. 52. Variable-length canonical fields MUST use explicit length encoding. 53. Reference Salt construction MUST use the normative length- delimited serialization, including Application Profile Identifier and Version. 54. CanonicalReferenceRecord in cryptographic operations MUST mean the exact binary serialization defined in Section 30. 55. Hardware loss MUST NOT mutate an already issued Reference. 56. Stored canonical hardware_input MAY permit reproduction without physical access to the original hardware. 57. Reference derivation MUST NOT depend on a signature. 58. A future Cryptographic Profile MUST NOT silently alter an existing Profile Version. 59. A future Signature Profile MUST NOT silently alter an existing Signature Profile Version. Hwang Expires 23 February 2027 [Page 77] Internet-Draft ARS-1 August 2026 60. A future Hardware Profile MUST NOT silently alter an existing Hardware Profile Version. 61. Cryptographic migration MUST preserve historical Reference identity. 62. Reference Resolution and Reference Reproduction are distinct operations. 63. Protocol evolution SHOULD prefer Profile Versioning when the existing ARS architecture remains semantically valid. 64. ARS-1 MUST NOT require a particular classical public-key algorithm for its core Reference construction. 65. ARS-1 MUST preserve cryptographic agility as a protocol design property. 66. Different Reference Cryptographic Profiles are not required to derive the same Reference from the same entity context. 67. Historical References remain bound to their original Reference Cryptographic Profile and Reference Key context. 68. Cryptographic Profile migration MUST NOT silently replace a historical Reference. 69. Cryptographic Profile security targets are engineering designations, not permanent guarantees of future security. 70. A cryptographic Profile MUST NOT be treated as permanently immune to future quantum or classical cryptanalysis solely because it is designated as active. 71. A Profile Identity is the exact ordered pair of Profile Identifier and Profile Version. 72. Application Profile Identity is explicitly represented in the canonical Reference context and cryptographically bound to Reference Salt derivation. 73. Reference Cryptographic Profile Identity is explicitly represented in the canonical Reference context and cryptographically bound to key derivation. 74. New Reference issuance MUST obey the deployment's authenticated minimum Cryptographic Profile policy. Hwang Expires 23 February 2027 [Page 78] Internet-Draft ARS-1 August 2026 75. Historical reproduction MAY use the historical Cryptographic Profile context and MUST NOT silently substitute a different Profile. 76. ARS-1 core Profile identifiers are ASCII-only. 77. Unicode-enabled canonical fields MUST have a Profile-defined normalization form and fixed Unicode version. 78. Hardware Profile challenge construction MUST be deterministic and fully specified. 79. Hardware credential equivalence MUST be explicitly defined by the Hardware Profile when equivalence is claimed. 80. Hardware Profile output truncation and encoding MUST be explicitly versioned. 81. 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. 82. 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. 83. Root Secret compromise does NOT invalidate historical References. Historical References remain canonical and do NOT need to be reissued. Reference identity stability is preserved. 84. 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. 85. 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. 86. 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. Hwang Expires 23 February 2027 [Page 79] Internet-Draft ARS-1 August 2026 87. Hardware Profile field order in canonical serialization is hardware_profile_id before hardware_profile_version, consistent with all other Profile field ordering. 88. A Profile Identifier MUST NOT include a version suffix. Version is always a separate field. 89. The ordered pair (Identifier, Version) is permanent and MUST NOT be reused for a different Profile definition. 90. ARS-1 defines three Canonical Profile Registries: Reference Cryptographic Profile Registry, Signature Profile Registry, and Hardware Profile Registry. 91. A Retired Profile MUST NOT be reactivated to Active status. 92. 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. 92. Long-Term Security Position ARS-1 separates: stable archival identity from: current cryptographic assumptions The intended long-term model is: Stable Reference | +--------------[U+253C]--------------+ | | | Reference Signature Hardware Cryptography Profile Profile | | | v v v Versioned Versioned Versioned Profile Profile Profile Therefore: Hwang Expires 23 February 2027 [Page 80] Internet-Draft ARS-1 August 2026 Reference v does not need to change when: current hash/KDF construction v future stronger construction or: Classical Signature v Post-Quantum Signature or: Hardware Profile v1 v Hardware Profile v2 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. 93. Security Model ARS should be understood as four independent layers: Hwang Expires 23 February 2027 [Page 81] Internet-Draft ARS-1 August 2026 Layer 1 -- Identity Entity Identity Identity Generation Layer 2 -- Reference Reference Cryptographic Profile ID / Version Root Secret Reference Key Reference Material Public Reference Layer 3 -- Integrity / Provenance State Root Content Hash Digital Signature Signature Profile Layer 4 -- Access Control Authentication Authorization Policy No layer may implicitly replace another. Cryptographic algorithm migration SHOULD occur within the relevant layer and SHOULD NOT require cross-layer identity mutation. 94. Final Architecture Hwang Expires 23 February 2027 [Page 82] Internet-Draft ARS-1 August 2026 ARS-1 | Application Profile ID/Version | +-------------[U+2534]-------------+ | | Canonical Entity Optional Hardware Context Input | | +-------------[U+252C]-------------+ v Reference Cryptographic Profile ID/Version v Reference Key v Reference Material v Public Data Bits v Canonical Base32 Encoding v Checksum v Public Reference | v URL Separately: Signature Profile v Digital Signature v Reference + State Root Separately: State Root v Historical Content Integrity 95. Final Principle ARS-1 is not a prettier UUID [RFC4122]. It is a: Hwang Expires 23 February 2027 [Page 83] Internet-Draft ARS-1 August 2026 *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: Old Profile v Historical References remain unchanged New Profile v Future Reference contexts / signatures / hardware mechanisms rather than: Old cryptography v Reissue every historical Reference Hwang Expires 23 February 2027 [Page 84] Internet-Draft ARS-1 August 2026 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: Stable Identity + Cryptographic Agility + Canonical Serialization + Variable-Length Encoding + Permanent Non-Reuse + Portable Reproduction + Independent Verification 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. ARS URI Scheme The ars URI scheme is formally specified by [ARSURI] -- ARS URI Scheme -- A URI Scheme for ARS-1 References, v1.0-rc2, available at . The ars URI scheme is registered as a provisional URI scheme in the IANA URI Schemes Registry (), following the registration guidelines of [RFC7595] and the URI syntax of [RFC3986]. The ars URI scheme defines the syntax ars:/// 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. Hwang Expires 23 February 2027 [Page 85] Internet-Draft ARS-1 August 2026 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 [RFC3987] are out of scope for ARS-1 References, which use a restricted ASCII-compatible character set. References Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005, . [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", RFC 7595, December 2015, . Informative References [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique Identifier (UUID) URN Namespace", RFC 4122, July 2005, . [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005, . Hwang Expires 23 February 2027 [Page 86] Internet-Draft ARS-1 August 2026 [ARSURI] Hwang, J., "ARS URI Scheme: A URI Scheme for ARS-1 References", Work in Progress, Internet-Draft, draft- juwan-ars-uri-00, August 2026, . Acknowledgments The ARS-1 protocol and its 23 independent implementations provided the foundation for this specification. Author's Address Juwan Hwang Email: juwan.hwang@proton.me Hwang Expires 23 February 2027 [Page 87]