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

[Brent Zundel <[e-mail]>]

Mirja,

I agree with both of your points, particularly b, and think the charter
should use the language you suggest.

On Mon, Oct 5, 2026 at 10:10 AM Heime.Jorgen <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 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]
>>
> _______________________________________________
> Audit mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Brent Zundel
Standards Architect | Yubico <http://www.yubico.com/>