Skip to Content
1.3.6.1.4.1.65553: signaliks – Signaliks0 - policy

1.3.6.1.4.1.65553.0 – Signaliks OID Registry Policy

Document Control

  • Policy reference: POL-ROOT-2.0.0
  • Revision: 2.0.0
  • Status: Effective
  • Published and effective: September 10, 2026
  • Supersedes: POL-ROOT-1.0.1
  • Registration authority: Signaliks OID Registration Authority

1. Purpose and Scope

This policy governs the allocation and publication of Object Identifiers below the Signaliks Private Enterprise Number 1.3.6.1.4.1.65553. IANA’s assignment of PEN 65553 is the external basis for this naming domain. Internal allocations are administered by Signaliks or by a Registration Authority acting under an explicit delegation record.

The structured dataset at /registry/registry.json is the authoritative register of allocations, delegations, registration decisions, object bindings, lifecycle states, and releases. Human-readable pages are generated views except for policy documents and administrative instruments.

2. Definitions

  • An OID node is a permanently registered numeric identifier and its position in the OID tree.
  • A secondary identifier is a human-readable label. It is descriptive metadata and does not replace the numeric OID.
  • An arc is an OID node authorized to contain subordinate allocations.
  • An object binding records the object identified by an OID. The binding’s identity-defining properties must not be silently replaced.
  • A registration decision is the immutable administrative record authorizing an allocation or material state change.
  • A policy revision is an immutable edition of a policy document with explicit publication and effective times.

3. Registration Principles

  1. Numeric OIDs are the primary identifiers. Secondary identifiers may be corrected or deprecated without changing the numeric OID.
  2. An assigned OID must never be deleted, reused, reassigned to an unrelated object, or made to appear never to have existed.
  3. No allocation is valid unless it is covered by an approved registration decision and an effective governing policy.
  4. Allocation state and object operational state are separate. Retiring or compromising an object does not revoke or free its OID.
  5. Unknown legacy facts must be recorded as unknown or unverified; they must not be inferred from names or prior presentation text.
  6. Material changes to an object’s identity require a new OID. Clerical corrections are recorded as append-only events.

4. Authorities and Delegation

Signaliks is the Naming Authority and root Registration Authority for this arc. A subordinate authority may allocate only within an active delegation’s scope and permissions.

Every delegation must identify the delegator, delegate, arc, permitted actions, effective time, subdelegation rule, status, governing policy, and administrative instrument. Suspension or termination of a delegation does not invalidate previously lawful allocations. The root authority remains responsible for uniqueness, continuity, and orderly transfer of registry custody.

The PKI arc 1.3.6.1.4.1.65553.2 is delegated to Youngdo Technologies Limited under DLG-2026-0001.

5. Registration Procedure

The Registration Authority must:

  1. authenticate the requester and verify authority over the proposed object;
  2. determine the object’s identity boundary and check for duplicate or conflicting registrations;
  3. verify that the requested allocation is permitted by the applicable policy and delegation;
  4. record an approved decision before publication;
  5. publish the structured record, generated views, release manifest, and audit event together;
  6. retain the prior state permanently.

Policy, delegation, and trust-anchor binding changes require independent review by two authorized roles. Where a small organization assigns multiple roles to one person, the exception and reason must be recorded in the decision.

6. Lifecycle and Corrections

OID allocation states are reserved, assigned, and deprecated. Object lifecycle states are defined by the applicable object policy and must not be conflated with allocation state.

A clerical correction that does not change identity may update descriptive metadata, provided an event records the old value, new value, reason, authority, and effective time. A change to an identity-defining property requires a new OID and an explicit supersededBy relationship.

7. Policy and Publication

Policy revisions are immutable after becoming effective. A replacement revision must identify the revision it supersedes and must not erase the previous revision. Every allocation records the policy revision that governed its decision.

Candidate releases may be generated for review. A release is authoritative only after its manifest has been reviewed and signed using a separately governed registry publication key. The canonical release must be reproducible from the structured source, and its historical artifacts must remain available.

8. Use of Arc Component Zero

Existing .0 policy-document OIDs are retained as permanent legacy allocations. There is no longer a global rule reserving the final component .0 at every depth. Future use of .0 is determined by the explicitly declared node type and governing policy. In particular, a versioned sequence may validly begin with version 0.

Policy documents are governance metadata linked from registry records; a new arc does not automatically require or receive a .0 policy OID.

9. Existing Allocations

Allocations published before this revision were regularized by decision MIG-2026-0001 without renumbering. Missing historical dates and cryptographic bindings remain explicitly unknown. The current allocation list and its provenance are available from the registry data page.

End of Policy.

Last updated on