[media-types] Re: [IANA #1448578] application/vnd.fo ritech.container registration request

This registration is good to go.

________________________________
From: Amanda Baber via RT <[email protected]>
Sent: Friday, April 10, 2026 22:21
Cc: [email protected] <[email protected]>; Darrel Miller <[email protected]>
Subject: [IANA #1448578] application/vnd.foritech.container registration request

Hi Darrel,

Sending a reminder for this request from March 27th.

thanks,
Amanda

On Fri Mar 27 18:32:56 2026, amanda.baber wrote:
> Hi Darrel,
>
> Would you be able to review this new request for us by April 10th?
>
> thanks,
> Amanda
>
> =====
>
> Name: Hristofor Lydmilov Hristov
>
> Email: [email protected]
>
> Media type name: application
>
> Media subtype name: vnd.foritech.container
>
> Required parameters: N/A
>
> Optional parameters: N/A
>
> Encoding considerations: binary
>
> Security considerations: This media type identifies a signed binary
> container format used by Foritech Secure System to transport telemetry
> and machine data together with verification metadata and a
> cryptographic signature.
>
> All received containers must be treated as untrusted until
> cryptographic verification succeeds.
>
> Security depends on strict parsing, correct signature verification,
> trusted key management, and rejection of malformed containers.
> Implementations that skip verification, accept malformed structures,
> or use weak trust policy can make incorrect trust decisions.
>
> The media type itself does not guarantee replay protection, timestamp
> validity, trust policy enforcement, or key provisioning. These
> controls are enforced by the consuming verification service or service
> layer.
>
> Potential risks include malformed input, signature forgery attempts,
> replay of previously valid containers, and denial-of-service through
> resource exhaustion.
>
> Interoperability considerations: Interoperability depends on a shared
> Foritech container specification, deterministic parsing rules, stable
> versioning, and agreement on the signature algorithm and metadata
> semantics.
>
> The container carries metadata, payload, and signature. The payload is
> treated as opaque by the verification core. Interoperable
> implementations must agree on the exact serialization and verification
> rules for header, metadata, payload, and signature coverage.
>
> Published specification: Foritech Protocol Specification:
> https://www.foritech.bg/specs/foritech-protocol-spec-v1
>
> Applications which use this media: Used by Foritech Secure System
> verification services, edge telemetry agents, gateways, audit
> pipelines, and applications that exchange signed telemetry or machine-
> data containers.
>
> Fragment identifier considerations: No fragment identifier syntax is
> currently defined for this media type.
>
> Restrictions on usage: Limited to systems and applications that
> implement the published Foritech container specification and
> verification rules.
>
> Provisional registration? (standards tree only): No
>
> Additional information:
>
> 1. Deprecated alias names for this type: none
> 2. Magic number(s): none
> 3. File extension(s): .ftech
> 4. Macintosh file type code: none
> 5. Object Identifiers: none
>
> General Comments: The format is intended for signed telemetry, machine
> data, and verification workflows where authenticity and integrity must
> be preserved across edge-to-cloud environments.Foritech Secure System
> operates under IANA Private Enterprise Number (PEN) 65385.
>
> Person to contact for further information:
>
> 1. Name: Hristofor Lydmilov Hristov
> 2. Email: [email protected]
>
> Intended usage: LIMITED USE
>
> Vendor-tree registration for a signed binary container format used by
> Foritech Secure System.
>
> Author/Change controller: Hristofor Lydmilov Hristov
> Founder, Foritech Secure System
> IANA PEN 65385
> https://www.foritech.bg/

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]