Message Types
The specification governs
This page explains the design of the Vultron Protocol. It is informative: the normative text is the Vultron Protocol Specification. Where this page and the specification differ, the specification governs.
The States page identified four main roles in the MPCVD process:
- Finder/Reporter
- Vendor
- Coordinator
- Deployer
This page examines the messages passed between them. Revisiting the definitions from the Protocol Definition:
Formalism
\(\langle M_{ij} \rangle_{i,j=1}^N\) are \(N^2\) disjoint finite sets with \(M_{ii}\) empty for all \(i\): \(M_{ij}\) represents the messages that can be sent from process \(i\) to process \(j\).
The message types in the Vultron Protocol arise primarily from the following principle taken directly from the CVD Guide:
Avoid Surprise
As with most situations in which multiple parties are engaged in a potentially stressful and contentious negotiation, surprise tends to increase the risk of a negative outcome. The importance of clearly communicating expectations across all parties involved in a CVD process cannot be overemphasized. If we expect cooperation between all parties and stakeholders, we should do our best to match their expectations of being "in the loop" and minimize their surprise. Publicly disclosing a vulnerability without coordinating first can result in panic and an aversion to future cooperation from Vendors and Finders alike. CVD promotes continued cooperation and increases the likelihood that future vulnerabilities will also be addressed and remedied.
That principle condenses into the following protocol recommendation:
Participants whose state changes in the RM, EM, or CVD State Models SHOULD send a message to other Participants for each transition.
If you are looking for a one-sentence summary of the entire Vultron Protocol, that was it.
State Transitions
- RM state transitions \(\Sigma^{rm} = \{ r,v,a,i,d,c\}\)
- EM state transitions \(\Sigma^{em} = \{ p,a,r,t\}\)
- CVD state transitions \(\Sigma^{cs} = \{\mathbf{V},\mathbf{F},\mathbf{D},\mathbf{P},\mathbf{X},\mathbf{A}\}\)
As a reminder, those transitions are shown at right.
The specific circumstances when each message should be emitted are addressed in Transitions; but first, the message types this recommendation implies are introduced here. The messages associated with each state model are covered in turn below, concluding with a few message types not directly connected to any particular state model.
RM Message Types
Finders have hidden states
As discussed in RM Interactions, the Finder's states \(q^{rm} \in \{R,I,V\}\) are not observable to the CVD process because Finders start coordination only when they have already reached \(q^{rm} = A\).
With the exception of the Finder/Reporter, each Participant's involvement in a CVD case starts with the receipt of a report from another Participant who is already in the \(Accepted\) (\(q^{rm} \in A\)) state. The remainder of a Participant's RM process is largely independent of the other Participants' RM processes. Therefore, the RM message types are primarily used to inform other Participants of the sender's state.
| Message Type | Name | Description |
|---|---|---|
| \(RS\) | Report Submission | A message from one Participant to a new Participant containing a vulnerability report. |
| \(RI\) | Report Invalid | A message indicating the Participant has designated the report as invalid. |
| \(RV\) | Report Valid | A message indicating the Participant has designated the report as valid. |
| \(RD\) | Report/Case Deferred | A message indicating the Participant is deferring further action; a case-participation decision (Ignore(VulnerabilityCase)). |
| \(RA\) | Report/Case Accepted | A message indicating the Participant has accepted the report for further action; a case-participation decision (Join(VulnerabilityCase)). |
| \(RC\) | Report Closed | A message indicating the Participant has closed the report. |
| \(RK\) | Report Acknowledgment | A message acknowledging the receipt of any RM message listed above. |
| \(RE\) | Report Error | A message indicating a Participant received an unexpected RM message. |
A summary of the RM message types is shown below.
RM Message Types
All state changes are from the Participant's (sender's) perspective, not the recipient's perspective. As Transitions shows, the receipt of a Report Submission is the only message whose receipt directly triggers an RM state change in the receiver. All other RM messages are used to convey the sender's status.
Participants SHOULD act in accordance with their own policy and process in deciding when to transition states in the RM model.
Participants SHOULD NOT mark duplicate reports as invalid.
Instead, duplicate reports SHOULD pass through \(Valid\) (\(q^{rm} \in V\)), although they MAY be subsequently (immediately or otherwise) deferred (\(q^{rm} \in V \xrightarrow{d} D\)) in favor of the original.
Participants SHOULD track the RM states of the other Participants in the case.
An example object model for such tracking is described in The Case Model. Furthermore, while these messages are expected to inform the receiving Participant's choices in their own RM process, this protocol intentionally does not specify any other recipient RM state changes upon receipt of an RM message.
EM Message Types
Whereas the RM process is unique to each Participant, the EM process is global to the case. Therefore, the message types below are those a Participant SHOULD emit when their EM state changes.
| Message Type | Name | Description |
|---|---|---|
| \(EP\) | Embargo Proposal | A message containing proposed embargo terms (e.g., date/time of expiration). |
| \(ER\) | Embargo Proposal Rejection | A message indicating the Participant has rejected an embargo proposal. |
| \(EA\) | Embargo Proposal Acceptance | A message indicating the Participant has accepted an embargo proposal. |
| \(EV\) | Embargo Revision Proposal | A message containing a proposed revision to embargo terms (e.g., date/time of expiration). |
| \(EJ\) | Embargo Revision Rejection | A message indicating the Participant has rejected a proposed embargo revision. |
| \(EC\) | Embargo Revision Acceptance | A message indicating the Participant has accepted a proposed embargo revision. |
| \(ET\) | Embargo Termination | A message indicating the Participant has terminated an embargo (including the reason for termination). Note that an Embargo Termination message is intended to have immediate effect. |
| \(EK\) | Embargo Acknowledgment | A message acknowledging receipt of any of the above EM message types. |
| \(EE\) | Embargo Error | A message indicating a Participant received an unexpected EM message. |
If an early termination is desired but the termination date/time is in the future, this SHOULD be achieved through an Embargo Revision Proposal and additional communication as necessary to convey the constraints on the proposal.
A summary of the EM message types is shown below.
EM Message Types
CS Message Types
From the CS process model, the following is the list of messages associated with CS state changes:
| Message Type | Name | Description |
|---|---|---|
| \(CV\) | Vendor Awareness | A message to other Participants indicating that a report has been delivered to a specific Vendor. Note that this is an announcement of a state change for a Vendor, not the actual report to the Vendor, which is covered in the Report Submission (\(RS\)) above. |
| \(CF\) | Fix Readiness | A message from a Participant (usually a Vendor) indicating that a specific Vendor has a fix ready. |
| \(CD\) | Fix Deployed | A message from a Participant (usually a Deployer) indicating that they have completed their fix deployment process. This message is expected to be rare in most MPCVD cases because Deployers are rarely included in the coordination effort. |
| \(CP\) | Public Awareness | A message from a Participant indicating that they have evidence that the vulnerability is known to the public. This message might be sent after a Participant has published their own advisory or if they have observed public discussion of the vulnerability. |
| \(CX\) | Exploit Public | A message from a Participant indicating that they have evidence that an exploit for the vulnerability is publicly available. This message might be sent after a Participant has published their own exploit code, or if they have observed exploit code available to the public. |
| \(CA\) | Attacks Observed | A message from a Participant indicating that they have evidence that attackers are exploiting the vulnerability in attacks. |
| \(CK\) | CS Acknowledgment | A message acknowledging receipt of any of the above CS message types. |
| \(CE\) | CS Error | A message indicating a Participant received an unexpected CS message. |
Vendor Awareness (\(CV\)) messages SHOULD be sent only by Participants with direct knowledge of the notification (i.e., either by the Participant who sent the report to the Vendor or by the Vendor upon receipt of the report).
A summary of the CS message types is shown below.
CS Message Types
Other Message Types
Finally, there are a few additional message types required to tie the coordination process together. Most of these message types are not associated with a specific state change, although they might trigger activities or events that could cause a state change in a Participant (and therefore trigger one or more of the above message types to be sent).
| Message Type | Name | Description |
|---|---|---|
| \(GI\) | General Inquiry | A message from a Participant to one or more other Participants to communicate non-state-change information. |
| \(GK\) | General Acknowledgment | A message from a Participant indicating their receipt of a GI message. |
| \(GE\) | General Error | A message indicating a general error has occurred. |
Examples of general inquiry messages include but are not limited to
- asking or responding to a question
- requesting an update on a Participant's status
- requesting review of a draft publication
- suggesting a potential Participant to be added to a case
- coordinating other events
- resolving a loss of Participant state synchronization
A summary of the General message types is shown below.
General Message Types
Message Type Redux
Thus, the complete set of possible messages between processes is \(M_{i,j} = M^{rm} \cup M^{em} \cup M^{cs} \cup M^{*}\). For convenience, these are collected into the table below.
| Process Model | \(M_{i,j}\) | Message Type | Emit When |
|---|---|---|---|
| RM | \(RS\) | Report Submission | sender \(\in A\) |
| RM | \(RI\) | Report Invalid | \(R \xrightarrow{i} I\) |
| RM | \(RV\) | Report Valid | \(\{R,I\} \xrightarrow{v} V\) |
| RM | \(RD\) | Report/Case Deferred | \(\{V,A\} \xrightarrow{d} D\) |
| RM | \(RA\) | Report/Case Accepted | \(\{V,D\} \xrightarrow{a} A\) |
| RM | \(RC\) | Report Closed | \(\{R,I,D,A\} \xrightarrow{c} C\) |
| RM | \(RK\) | Report Acknowledgment | any valid RM message |
| RM | \(RE\) | Report Error | any unexpected RM message |
| EM | \(EP\) | Embargo Proposal | \(\{N,P\} \xrightarrow{p} P\) |
| EM | \(ER\) | Embargo Proposal Rejection | \(P \xrightarrow{r} N\) |
| EM | \(EA\) | Embargo Proposal Acceptance | \(P \xrightarrow{a} A\) |
| EM | \(EV\) | Embargo Revision Proposal | \(A \xrightarrow{p} R\) |
| EM | \(EJ\) | Embargo Revision Rejection | \(R \xrightarrow{r} A\) |
| EM | \(EC\) | Embargo Revision Acceptance | \(R \xrightarrow{a} A\) |
| EM | \(ET\) | Embargo Termination | \(\{A,R\} \xrightarrow{t} X\) |
| EM | \(EK\) | Embargo Acknowledgment | any valid EM message |
| EM | \(EE\) | Embargo Error | any unexpected EM message |
| CS | \(CV\) | Vendor Awareness | \(vfd \cdot\cdot\cdot \xrightarrow{\mathbf{V}} Vfd \cdot\cdot\cdot\) |
| CS | \(CF\) | Fix Readiness | \(Vfd \cdot\cdot\cdot \xrightarrow{\mathbf{F}} VFd \cdot\cdot\cdot\) |
| CS | \(CD\) | Fix Deployed | \(VFd \cdot\cdot\cdot \xrightarrow{\mathbf{D}} VFD \cdot\cdot\cdot\) |
| CS | \(CP\) | Public Awareness | \(\cdot\cdot\cdot p \cdot\cdot \xrightarrow{\mathbf{P}} \cdot\cdot\cdot P \cdot\cdot\) |
| CS | \(CX\) | Exploit Public | \(\cdot\cdot\cdot\cdot x \cdot \xrightarrow{\mathbf{X}} \cdot\cdot\cdot\cdot X \cdot\) |
| CS | \(CA\) | Attacks Observed | \(\cdot\cdot\cdot\cdot\cdot a \xrightarrow{\mathbf{A}} \cdot\cdot\cdot\cdot\cdot A\) |
| CS | \(CK\) | CS Acknowledgment | any valid CS message |
| CS | \(CE\) | CS Error | any unexpected CS message |
| * | \(GI\) | General Inquiry | any time |
| * | \(GK\) | General Acknowledgment | any valid GI message |
| * | \(GE\) | General Error | any unexpected GI message |
Message Types Formally Defined
Message formats are implemented using the ActivityStreams 2.0 vocabulary. See Vultron AS Activity Guides for details on the wire format.
AS2 Implementation Note
The ActivityStreams-based wire format collapses the revision-negotiation message types: \(EV\) is sent as \(EP\), \(EC\) is sent as \(EA\), and \(EJ\) is sent as \(ER\). The formal message type set above remains normative for protocol semantics; the AS2 mapping is an implementation detail of the current prototype.
Error shorthands have no direct wire counterpart
\(RE\), \(EE\), \(CE\), and \(GE\) are not realized as distinct AS2 activity types.
Fault reporting is instead partitioned by failure mode: Create(ProcessingFault)
for a message that was not understood, as:Reject for one that was understood but
declined, and Add(Note) for a condition requiring narrative explanation.
See How to Report a Protocol Fault and
specs/message-semantics-mapping.yaml MSM-05.
Acknowledgment shorthands have no direct wire counterpart
\(EK\), \(CK\), and \(GK\) have no per-message wire equivalents for ledger-replicated
state. Acknowledgment is instead cumulative and implicit via hash-chain
continuity: a receiver whose prev_log_hash matches its local ledger tail says
nothing — the match is the acknowledgment. On a mismatch the receiver emits
Reject(CaseLedgerEntry), whereupon the CASE_MANAGER replays all entries after the
last accepted hash (negative acknowledgment with gap-fill replay).
\(RK\) remains a real wire activity (Read(Offer(VulnerabilityReport))) because
report submission is not ledger-replicated.
See Faults and Acknowledgments and
specs/message-semantics-mapping.yaml MSM-05-002.