[media-types] [IANA #1456142] application (RFC 2046) /vnd.aep+zip registration request
"David Dong via RT" <[email protected]>
| Newsgroups | gmane.ietf.types |
|---|---|
| Message-ID | <[email protected]> |
Hi Darrel, Following up for this request that was assigned a due date of July 31st. Thank you. Best regards, David Dong IANA Services Sr. Specialist -- Name: Anton Sokolov Email: [email protected] Media type name: application (RFC 2046) Media subtype name: vnd.aep+zip Required parameters: N/A. Optional parameters: N/A. Encoding considerations: binary Binary (ZIP container; see RFC 6839 for the +zip structured syntax suffix). Security considerations: An AEP (Action Evidence Package) is a signed, append-only evidence container: a ZIP archive with a flat internal layout carrying a canonical action record (RFC 8785 JCS), its SHA-256 hash, a detached signature, an RFC 3161 timestamp token, and metadata. Consumers MUST verify the enclosed signature and hash chain before trusting any member file; the signature proves possession of the runtime's key, not the integrity of the platform that held it (composition with remote attestation per RFC 9334 is specified separately in draft-sokolov-rats-aep-composition). Standard ZIP-parsing hazards apply and are constrained by the profile: nested directories are forbidden, member names are fixed by the profile, maximum uncompressed size is 10 MB (decompression-bomb bound), and duplicate entry names MUST be rejected. The container itself provides no confidentiality; if the recorded action contains personal or confidential data, transport- or object-layer encryption is requir ed. Interoperability considerations: The payload is a standard PKZIP archive (store or deflate) readable by any ZIP library. The profile (v1) fixes the member set and forbids features (nesting, encryption, ZIP64) that commonly break interoperability. Published specification: AEP profile v1, urn:eatf:spec:aep:1.0 - https://schemas.tyche.institute/eatf/aep-v1.schema.json (metadata schema); composition context: draft-sokolov-rats-aep-composition (IETF Datatracker). Applications which use this media: EATF verifier (open source), AEP sandbox tooling, RATS Conceptual Message Wrapper (RFC 9999) Record/Collection carriage of application-layer action evidence. Fragment identifier considerations: As specified for +zip (none defined for application/zip). Restrictions on usage: None. Provisional registration? (standards tree only): No Additional information: 1. Deprecated alias names for this type: N/A. 2. Magic number(s): 50 4B 03 04 (ZIP local file header) 3. File extension(s): .aep 4. Macintosh file type code: N/A. 5. Object Identifiers: N/A. General Comments: Vendor designation "eatf" refers to the EATF open verification tooling published by Tyche Institute (Tallinn, Estonia). Person to contact for further information: 1. Name: Anton Sokolov 2. Email: [email protected] Intended usage: COMMON Evidence interchange for accountability of automated (e.g. AI-agent) actions. Author/Change controller: Tyche Institute (Tallinn, Estonia); [email protected] On Thu Jul 23 22:42:03 2026, david.dong wrote: > Hi Darrel, > > Apologies; correcting some mangled text in the subtype name in the > submission form and template. > > Thank you. > > Best regards, > > David Dong > IANA Services Sr. Specialist > > -- > > Name: Anton Sokolov > > Email: [email protected] > > Media type name: application (RFC 2046) > > Media subtype name: vnd.aep+zip > > Required parameters: N/A. > > Optional parameters: N/A. > > Encoding considerations: binary > > Binary (ZIP container; see RFC 6839 for the +zip structured syntax > suffix). > > Security considerations: An AEP (Action Evidence Package) is a signed, > append-only evidence container: a ZIP archive with a flat internal > layout carrying a canonical action record (RFC 8785 JCS), its SHA-256 > hash, a detached signature, an RFC 3161 timestamp token, and metadata. > Consumers MUST verify the enclosed signature and hash chain before > trusting any member file; the signature proves possession of the > runtime's key, not the integrity of the platform that held it > (composition with remote attestation per RFC 9334 is specified > separately in draft-sokolov-rats-aep-composition). Standard ZIP- > parsing hazards apply and are constrained by the profile: nested > directories are forbidden, member names are fixed by the profile, > maximum uncompressed size is 10 MB (decompression-bomb bound), and > duplicate entry names MUST be rejected. The container itself provides > no confidentiality; if the recorded action contains personal or > confidential data, transport- or object-layer encryption is requir > ed. > > Interoperability considerations: The payload is a standard PKZIP > archive (store or deflate) readable by any ZIP library. The profile > (v1) fixes the member set and forbids features (nesting, encryption, > ZIP64) that commonly break interoperability. > > Published specification: AEP profile v1, urn:eatf:spec:aep:1.0 - > https://schemas.tyche.institute/eatf/aep-v1.schema.json (metadata > schema); composition context: draft-sokolov-rats-aep-composition (IETF > Datatracker). > > Applications which use this media: EATF verifier (open source), AEP > sandbox tooling, RATS Conceptual Message Wrapper (RFC 9999) > Record/Collection carriage of application-layer action evidence. > > Fragment identifier considerations: As specified for +zip (none > defined for application/zip). > > Restrictions on usage: None. > > Provisional registration? (standards tree only): No > > Additional information: > > 1. Deprecated alias names for this type: N/A. > 2. Magic number(s): 50 4B 03 04 (ZIP local file header) > 3. File extension(s): .aep > 4. Macintosh file type code: N/A. > 5. Object Identifiers: N/A. > > General Comments: Vendor designation "eatf" refers to the EATF open > verification tooling published by Tyche Institute (Tallinn, Estonia). > > Person to contact for further information: > > 1. Name: Anton Sokolov > 2. Email: [email protected] > > Intended usage: COMMON > > Evidence interchange for accountability of automated (e.g. AI-agent) > actions. > > Author/Change controller: Tyche Institute (Tallinn, Estonia); > [email protected] > > On Sat Jul 18 02:59:49 2026, david.dong wrote: > > Hi Darrel, > > > > Can you review this new request for us by July 31st? > > > > Thank you. > > > > Best regards, > > > > David Dong > > IANA Services Sr. Specialist > > > > -- > > > > Name: Anton Sokolov > > > > Email: [email protected] > > > > Media type name: application (RFC 2046) > > > > Media subtype name: Vendor Tree (vnd. prefix)eatf.aep+zip > > > > Required parameters: N/A. > > > > Optional parameters: N/A. > > > > Encoding considerations: binary > > > > Binary (ZIP container; see RFC 6839 for the +zip structured syntax > > suffix). > > > > Security considerations: An AEP (Action Evidence Package) is a > > signed, > > append-only evidence container: a ZIP archive with a flat internal > > layout carrying a canonical action record (RFC 8785 JCS), its SHA-256 > > hash, a detached signature, an RFC 3161 timestamp token, and > > metadata. > > Consumers MUST verify the enclosed signature and hash chain before > > trusting any member file; the signature proves possession of the > > runtime's key, not the integrity of the platform that held it > > (composition with remote attestation per RFC 9334 is specified > > separately in draft-sokolov-rats-aep-composition). Standard ZIP- > > parsing hazards apply and are constrained by the profile: nested > > directories are forbidden, member names are fixed by the profile, > > maximum uncompressed size is 10 MB (decompression-bomb bound), and > > duplicate entry names MUST be rejected. The container itself provides > > no confidentiality; if the recorded action contains personal or > > confidential data, transport- or object-layer encryption is requir > > ed. > > > > Interoperability considerations: The payload is a standard PKZIP > > archive (store or deflate) readable by any ZIP library. The profile > > (v1) fixes the member set and forbids features (nesting, encryption, > > ZIP64) that commonly break interoperability. > > > > Published specification: AEP profile v1, urn:eatf:spec:aep:1.0 - > > https://schemas.tyche.institute/eatf/aep-v1.schema.json (metadata > > schema); composition context: draft-sokolov-rats-aep-composition > > (IETF > > Datatracker). > > > > Applications which use this media: EATF verifier (open source), AEP > > sandbox tooling, RATS Conceptual Message Wrapper (RFC 9999) > > Record/Collection carriage of application-layer action evidence. > > > > Fragment identifier considerations: As specified for +zip (none > > defined for application/zip). > > > > Restrictions on usage: None. > > > > Provisional registration? (standards tree only): No > > > > Additional information: > > > > 1. Deprecated alias names for this type: N/A. > > 2. Magic number(s): 50 4B 03 04 (ZIP local file header) > > 3. File extension(s): .aep > > 4. Macintosh file type code: N/A. > > 5. Object Identifiers: N/A. > > > > General Comments: Vendor designation "eatf" refers to the EATF open > > verification tooling published by Tyche Institute (Tallinn, Estonia). > > > > Person to contact for further information: > > > > 1. Name: Anton Sokolov > > 2. Email: [email protected] > > > > Intended usage: COMMON > > > > Evidence interchange for accountability of automated (e.g. AI-agent) > > actions. > > > > Author/Change controller: Tyche Institute (Tallinn, Estonia); > > [email protected] _______________________________________________ media-types mailing list -- [email protected] To unsubscribe send an email to [email protected]