Considerations and References
This page is normative
This page is considered a core part of the Vultron Protocol. This is a normative section of the documentation.
The whole specification on one page
The specification is also published as a single page that holds every section and annex in order, for printing or for searching the whole text at once.
This page holds sections 13 to 15 of the Vultron Protocol Specification: the namespaces the protocol uses and what it asks of the Internet Assigned Numbers Authority (IANA), its security considerations, and the documents it cites. Several of its considerations concern the Hypertext Transfer Protocol (HTTP) transport.
13. IANA and Namespace Considerations [I]
Vultron vocabulary namespace. The Vultron ActivityStreams 2.0 (AS2) vocabulary namespace is
https://certcc.github.io/Vultron/ns. This is the initial, provisional Uniform Resource Identifier (URI),
hosted on GitHub Pages. A permanent URI registration (for example, via a
w3id.org redirect) is planned for a future version of this specification.
See ADR-0069.
JSON-LD context document. The normative JavaScript Object Notation for Linked Data (JSON-LD) context is identified by
https://certcc.github.io/Vultron/ns/context.jsonld. Implementations MUST
use this URI as the @context value for all outbound Vultron messages (§5.5 Serialization).
That URI does not currently dereference. The context document is withheld from publication until it is served at the wire-versioned path that ADR-0106 defines. At this version the namespace is therefore a stable identifier, not a retrievable document. An implementation MUST therefore cite the URI without depending on resolving it, and MUST NOT require a successful fetch to process a message.
AS2 extension type naming conventions. Vultron type names follow PascalCase
without an as_ prefix in wire output (for example, "type": "VulnerabilityCase"
rather than "type": "as:VulnerabilityCase"). The Vultron JSON-LD context
declares all type names, so implementations citing only the Vultron context URI
do not need to separately declare the AS2 namespace.
IANA registration. No new IANA registrations are required by the current version of this specification. If the Vultron namespace moves to a standards-track document, an IANA media type registration for the Vultron JSON-LD profile may be appropriate at that time.
14. Security Considerations [N/I]
14.1 Trust Model
Actor identity. The protocol uses actor URIs as process identifiers. An
actor URI is the identity anchor for all messages sent by that actor, and for
the canonical case ledger if the actor holds the CASE_MANAGER role. Implementations
MUST treat actor URI equality as identity equality: two messages with the same
actor URI are from the same actor.
Verification. The protocol does not currently mandate a specific identity verification mechanism. The reference implementation anticipates HTTP Signatures (as used in ActivityPub) as the authentication layer for inbound messages. A future version of this specification is expected to normatively require HTTP Signatures at the transport layer.
Case bootstrap as the trust establishment mechanism. The
Create(VulnerabilityCase) message signed by the originating actor is the
trust root for a case. Late joiners receive a case snapshot and prior ledger
entries from the CASE_MANAGER. A late joiner trusts the CASE_MANAGER's delivery
because it trusts the Create message that introduced the CASE_MANAGER. This
chain is the minimal trust model; cryptographic ledger integrity (hash-chaining)
provides tamper detection.
See also
- §4.5 Trust and Bootstrap Semantics (trust and bootstrap semantics)
- §5.4 Addressing and Channels (addressing and channels)
14.2 Embargo Integrity
Protocol adherence. An active embargo is an agreement, not a technical enforcement. The protocol provides the signaling infrastructure — Participant Embargo Consent (PEC) state tracks which participants have consented, §9.5 Embargo Traffic Reaches Non-Signatories ensures all participants receive meta-protocol messages — but it cannot prevent a participant from disclosing outside the protocol.
Defection. If a participant discloses publicly while an embargo is ACTIVE,
the CP (public awareness) message will trigger the embargo teardown cascade
(§10.3 Status Adoption: The Two-Seam Model). The teardown is a state machine consequence, not a penalty mechanism.
The protocol has no built-in penalty for defection; enforcement is an
out-of-band organizational matter.
Confidentiality gate. Sensitive case content is gated on embargo consent (§9.7 Gating Full Case Delivery).
While an embargo is in force, a participant that is not a signatory to it, because its consent row for that embargo is not AGREED, does not receive full case details.
This is the primary technical lever the protocol provides against inadvertent over-disclosure to non-consenting parties.
14.3 Replay and Idempotency
Message deduplication. Each ActivityStreams Activity carries a unique id.
Implementations MUST deduplicate inbound messages by id before processing
them. Duplicate delivery does not change state.
Ledger idempotency. The canonical case ledger is append-only and
hash-chained. A re-delivered Announce(CaseLedgerEntry) with a known entry
hash MUST be treated as a no-op. The ledger NAK path (Reject(CaseLedgerEntry))
and gap-fill replay provide recovery from missed entries.
14.4 Confidentiality
In-transit protection. The protocol does not currently mandate a specific in-transit encryption mechanism. Transport Layer Security (TLS) is the expected transport protection for HTTP delivery. A future version of this specification is expected to require TLS.
At-rest and end-to-end confidentiality. Content-level encryption — protecting case details from the CASE_MANAGER itself, or supporting future multi-party computation — is not specified by this version. Implementations SHOULD treat any unencrypted case content as accessible to whoever operates the CASE_MANAGER.
Scope. This section covers security requirements for the protocol as specified. Operational security measures (key management, access control, incident response for actor compromise) are out of scope for this specification.
15. References
15.1 Normative References
These documents are required to implement this specification.
| Reference | Title |
|---|---|
| RFC 2119 | Key words for use in RFCs to Indicate Requirement Levels |
| RFC 8174 | Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words |
| ActivityStreams 2.0 Core | Activity Streams 2.0, World Wide Web Consortium (W3C) Recommendation |
| ActivityStreams 2.0 Vocabulary | Activity Vocabulary, W3C Recommendation |
| JSON-LD 1.1 | JSON-LD 1.1: A JSON-based Serialization for Linked Data, W3C Recommendation |
| RFC 8259 | The JavaScript Object Notation (JSON) Data Interchange Format |
15.2 Informative References
These documents provide context. They are not required to implement this specification.
| Reference | Title |
|---|---|
| ActivityPub | ActivityPub, W3C Recommendation. The anticipated transport; not required by this version (§1.3 Relationship to Existing Standards) |
| ISO/IEC 29147:2018 | Information technology — Security techniques — Vulnerability disclosure |
| ISO/IEC 30111:2019 | Information technology — Security techniques — Vulnerability handling processes |
| CERT Guide to CVD | The CERT Guide to Coordinated Vulnerability Disclosure. Source of this specification's definition of vulnerability (§2.1 Actors, Participants and Cases) |
| CVE Program | Common Vulnerabilities and Exposures (CVE) Numbering Authority operational rules, referenced at §12.4.3 CVE ID Assignment |
| RFC 7033 | WebFinger. The anticipated participant-discovery mechanism (§5.6 Transport Layer) |
| HTTP Signatures | Signing HTTP Messages. The anticipated authentication layer (§14.1 Trust Model) |