[Audit] Re: Proposed charter change to clarify VCON relationship

["Heime.Jorgen" <[e-mail]>]

Hi Jonathan, Mohamad, Henri, Peter, and All,

While identifying Hook injection points (PEPs/PDPs), structuring interaction payloads (vCon), and defining approval objects (CHEQ) are necessary exercises, the current direction on the list relies on an incomplete trust model.

The Root Cause of Misunderstanding in JWS/vCon Audits:

There is a fundamental misconception that an embedded timestamp claim (`iat`) inside a vCon or CHEQ JWS signature is sufficient for an audit.

However, a timestamp inside a JWS payload is merely a "Self-Reported Claimed Time" asserted by the signer itself. Without an external, independent Cryptographic Timestamping Service (CTS / Proof-of-Time from Roughtime ensembles or PTP) sealing the packet header envelope at the exact moment of execution, any private key holder can retroactively forge valid signatures with backdated timestamps. Relying parties are left with zero cryptographic defense against post-hoc backdating or key compromise hazards.

Relying solely on local sequence numbers and static JWS signatures without a mandatory Cryptographic Timestamping Service (CTS) or Hardware-backed Proof-of-Time (PoT) envelope leaves the entire audit framework vulnerable under enterprise threat models.

Below is a technical breakdown of why the current assumptions fail to achieve legal non-repudiation:

1. Sequence Numbers Do Not Prevent Replay or Backdating Attacks (Re: Henri & Peter)

Local sequence numbers and signed running counts only prove internal ordinal continuity within a single, active, isolated stream. They provide zero temporal anchoring:

- Replay Vulnerability: A completely valid, signed sequence capture from months ago can be replayed across an agent delegation boundary today. Sequence verification will pass 100%.

- Backdating & Post-Hoc Insertion: If an operator controls the runtime clock, they can retroactively forge a valid signed sequence. Sequence counters cannot prove when sequence S_k was produced relative to an objective timeline.

- Cross-PEP Disparity: Software clock skews across heterogeneous PEPs (e.g., Cursor runtime vs. Enterprise Gateway) prevent establishing a total order of events without a unified hardware-backed time anchor.

2. JWS Signatures Prove Key Identity, Not Signature Timing (Re: Mohamad & Jonathan)

Whether using vCon’s JWS header (`x5c`/`x5u`) or standalone approval objects like CHEQ (`draft-rosenberg-cheq-00`), standard PKI signatures (RFC 7515) only prove possession of the signing key (who signed). They fail to establish temporal non-repudiation (when it was signed):

- Unverifiable Claims: A `iat` (Issued At) claim inside a JWS payload is self-reported metadata, not cryptographic proof.

- Post-Hoc Key Compromise Hazard: If an agent's private key is compromised or revoked in the future, every historical vCon or CHEQ signature lacking an external Cryptographic Timestamping Service (CTS / ISO/IEC 18014) anchor becomes legally repudiable. The signer can claim past records were backdated post-compromise.

3. The Missing Layer: Decoupling Payload from the Temporal Integrity Envelope

Attempting to force non-repudiation directly into the payload format (vCon/CHEQ) or relying on PEP-level runtime hooks creates a fragile, fail-open audit model.

To satisfy enterprise CISO requirements and regulatory frameworks (e.g., EU AI Act, FDA 21 CFR Part 11, DORA), AUDIT must explicitly decouple:

Here is the architecture

[Factor 1: Data Model] x [Factor 2: Time Envelope] x [Factor 3: Storage]

(vCon / CHEQ Payload) (CTS / TTTPS Header Seal) (S3 WORM Anchor)

[WHAT & WHO] [WHEN & NON-REPUDIATION] [WHERE & SOVEREIGNTY]

Note: If any single factor equals 0, the entire Audit Integrity equals 0. And if there are immutable storage, AWS S3 can be replaceable, no vendor lock-in.

Without anchoring every hook event and vCon/CHEQ payload to an external Cryptographic Timestamping Service (CTS) at the exact moment of execution, any audit trail generated by this Working Group will remain probabilistic, mutable, and vulnerable to simple time-skew and replay exploits.

Why should the AUDIT WG restrict its scope to identity and data structures while ignoring deterministic Cryptographic Timestamping (CTS), given that identity without verifiable temporal proof cannot survive a legal or regulatory audit?

Best regards,

Heime Jorgen

-------- Original Message --------
On Sunday, 10/04/26 at 09:16 Heime.Jorgen <[e-mail]> wrote:

> Hi Jonathan, Mohamad, Henri, Peter and All,
>
> While identifying Hook injection points (PEPs/PDPs), structuring interaction payloads (vCon), and defining approval objects (CHEQ) are necessary exercises, the current direction on the list relies on an incomplete trust model.
>
> The Root Cause of Misunderstanding in JWS/vCon Audits:
>
> There is a fundamental misconception that an embedded timestamp claim (`iat`) inside a vCon or CHEQ JWS signature is sufficient for an audit.
>
> However, a timestamp inside a JWS payload is merely a "Self-Reported Claimed Time" asserted by the signer itself. Without an external, independent Cryptographic Timestamping Service (CTS / Proof-of-Time from Roughtime ensembles + Cryptographic seal) sealing the packet header envelope at the exact moment of execution, any private key holder can retroactively forge valid signatures with backdated timestamps. Relying parties are left with zero cryptographic defense against post-hoc backdating or key compromise hazards.
>
> Relying solely on local sequence numbers and static JWS signatures without a mandatory Cryptographic Timestamping Service (CTS) or Hardware-backed Proof-of-Time (PoT) envelope leaves the entire audit framework vulnerable under enterprise threat models.
>
> Below is a technical breakdown of why the current assumptions fail to achieve legal non-repudiation:
>
> 1. Sequence Numbers Do Not Prevent Replay or Backdating Attacks (Re: Henri & Peter)
>
> Local sequence numbers
> and signed running counts only prove internal ordinal continuity within a single, active, isolated stream.
>
> They provide zero temporal anchoring:
>
> - Replay Vulnerability: A completely valid, signed sequence capture from months ago can be replayed across an agent delegation boundary today. Sequence verification will pass 100%.
>
> - Backdating & Post-Hoc Insertion: If an operator controls the runtime clock, they can retroactively forge a valid signed sequence. Sequence counters cannot prove when sequence S_k was produced relative to an objective timeline.
>
> - Cross-PEP Disparity: Software clock skews across heterogeneous PEPs (e.g., Cursor runtime vs. Enterprise Gateway) prevent establishing a total order of events without a unified hardware-backed time anchor.
>
> 2. JWS Signatures Prove Key Identity, Not Signature Timing (Re: Mohamad & Jonathan)
>
> Whether using vCon’s JWS header (`x5c`/`x5u`) or standalone approval objects like CHEQ (`draft-rosenberg-cheq-00`), standard PKI signatures (RFC 7515) only prove possession of the signing key (who signed). They fail to establish temporal non-repudiation (when it was signed):
>
> - Unverifiable Claims: A `iat` (Issued At) claim inside a JWS payload is self-reported metadata, not cryptographic proof.
>
> - Post-Hoc Key Compromise Hazard: If an agent's private key is compromised or revoked in the future, every historical vCon or CHEQ signature lacking an external Cryptographic Timestamping Service (CTS / ISO/IEC 18014) anchor becomes legally repudiable. The signer can claim past records were backdated post-compromise.
>
> 3. The Missing Layer: Decoupling Payload from the Temporal Integrity Envelope
>
> Attempting to force non-repudiation directly into the payload format (vCon/CHEQ) or relying on PEP-level runtime hooks creates a fragile, fail-open audit model.
>
> To satisfy enterprise CISO requirements and regulatory frameworks (e.g., EU AI Act, FDA 21 CFR Part 11, DORA), AUDIT must explicitly decouple:
>
> a) The Interaction Data Model (vCon / CHEQ payloads)
>
> b) The Cryptographic Verification Envelope (TTTPS / CTS binding hardware PTP and time quorum proofs into the packet header before state mutation)
>
> c) The Immutable Storage Anchor (S3 WORM / Object Lock)
>
> Without anchoring every hook event and vCon/CHEQ payload to an external Cryptographic Timestamping Service (CTS) at the exact moment of execution, any audit trail generated by this Working Group will remain probabilistic, mutable, and vulnerable to simple time-skew and replay exploits.
>
> Here is the architecture: (note: If there are other immutable storage, AWS S3 can be replaceable, no vendor lock-in)
>
> Why should the AUDIT WG restrict its scope to identity and data structures while ignoring deterministic Cryptographic Timestamping (CTS), given that identity without verifiable temporal proof cannot survive a legal or regulatory audit?
>
> Best regards,
>
> Heime Jorgen
>
> -------- Original Message --------
> On Sunday, 10/04/26 at 00:48 Jonathan Rosenberg <[e-mail]> wrote:
>
>> This is a good question.
>>
>> I do see value in defining the idea of a user approval as a standalone object format, usable in many different contexts. Once defined, it could then be used within a VCON, either by reference or by value. In that way, I don't think such an object format is an extension of VCON. This means it might be better suited to specification elsewhere, such as AUDIT, and then referenced by the VCON extension.
>>
>> I had written a proposal on a protocol and format for this, called CHEQ:
>> https://datatracker.ietf.org/doc/html/draft-rosenberg-cheq-00
>>
>> Thx,
>> Jonathan R.
>>
>> On Sat, Oct 3, 2026 at 10:05 AM Mohamad Khalil Yossif <mohamad=[e-mail]> wrote:
>>
>>>> Jonathan, all,
>>>>
>>>> One question about the vCon direction, asked to understand it rather
>>>> than to object.
>>>>
>>>> vCon's signed form is JWS with x5c or x5u in the unprotected header,
>>>> so the signer is identified by a certificate chain. That fits a
>>>> recording system signing a conversation it captured.
>>>>
>>>> The charter says audit information must be verifiable by a party that
>>>> trusts neither the agent nor its operator. For interaction records
>>>> that holds, because the recording system is a different party from the
>>>> agent and the chain names it.
>>>>
>>>> Where I am unclear is the record of a human decision. If a user
>>>> approval is captured as part of a conversation, the signature over it
>>>> is the recording system's, not the user's. The record then says the
>>>> system observed an approval. A relying party that does not trust the
>>>> system has no second source.
>>>>
>>>> So: is a record whose signer is the human rather than the capturing
>>>> system in scope for the data-model deliverable, and if so does it
>>>> belong in the vCon profile, in a separate record type, or as an
>>>> externally referenced object carried by content_hash?
>>>>
>>>> I ask because vCon already has the third of those. Externally
>>>> referenced files are committed to by url and content_hash inside the
>>>> integrity signature, so a separately signed artifact can ride along
>>>> without vCon needing to understand it. If that is the intended answer
>>>> it would be useful to say so, since it is a profile question rather
>>>> than a vCon extension and would therefore sit in AUDIT rather than in
>>>> the VCON group.
>>>>
>>>> Mohamad Khalil Yossif
>>>
>>> _______________________________________________
>>> Audit mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]