CERTIDOX - INDEPENDENT VERIFICATION BUNDLE
Certified Email

PURPOSE

This archive contains the encrypted certified email-content representation together with the materials required to:

1. reconstruct the certified email-content representation;
2. verify its SHA-256 hash against the certification manifest; and
3. independently verify the DigiStamp RFC 3161 timestamp associated with that manifest.

The verification process is designed to be reproducible using independently available technical tools and does not require reliance on a Certidox-generated verification display.


CONTENTS

document.enc
    AES-256-GCM encrypted certified email-content representation.

reading_key.txt
    Reading key used to decrypt document.enc.

manifest.json
    Certification manifest containing:
    - the Certidox certification identifier;
    - the SHA-256 hash of the certified payload;
    - the Certidox certification-event time;
    - the certifier information recorded by Certidox; and
    - the certifying organization recorded by Certidox.

response.tsr
    DigiStamp RFC 3161 timestamp response.

    The RFC 3161 message imprint corresponds to the SHA-256 of the exact manifest.json bytes submitted for timestamping.

decrypt.py
    Convenience script used to decrypt document.enc and reconstruct the certified email-content representation.

verify_timestamp.sh
    Convenience script used to verify:
    - the SHA-256 of the reconstructed certified payload against the value recorded in manifest.json; and
    - the exact manifest.json bytes against the DigiStamp RFC 3161 timestamp response.

readme.txt
    This document.


CERTIFIED PAYLOAD

For certified email, the decrypted payload is document.json.

document.json is the certified email-content representation created by the Certidox certification process.

It is not a byte-for-byte reconstruction of the native .eml file.

Depending on the certified email, document.json may contain certified fields such as:

- From;
- To;
- CC;
- Subject;
- message date;
- body;
- body type;
- attachment metadata.

The exact fields present are those contained in the reconstructed document.json.


PAYLOAD SHA-256

payload_sha256 in manifest.json is the SHA-256 hash of the exact certified payload before encryption.

It is calculated by the Certidox certification process and recorded in manifest.json before that manifest is submitted for RFC 3161 timestamping.

Successful verification requires:

SHA-256(reconstructed certified payload) = payload_sha256 recorded in manifest.json


RFC 3161 TIMESTAMP VERIFICATION

The exact manifest.json used for certification is preserved with the certification record.

The DigiStamp RFC 3161 timestamp response contains a message imprint corresponding to the SHA-256 of those exact manifest.json bytes.

Successful timestamp verification therefore requires:

SHA-256(exact manifest.json bytes) = RFC 3161 message imprint

The verification procedure may use DigiStamp trust material obtained independently of Certidox.

The included scripts are convenience implementations and are not themselves trust anchors.


VERIFICATION CHAIN

The historical cryptographic verification chain is:

Certidox QR code
    ->
reading key and certification identifier
    ->
document.enc
    ->
reconstructed certified email-content representation
    ->
SHA-256 of the certified payload
    ->
manifest.json
    ->
SHA-256 of the exact manifest.json bytes
    ->
DigiStamp RFC 3161 timestamp response


WHAT A SUCCESSFUL VERIFICATION ESTABLISHES

A successful verification establishes that:

1. document.enc can be decrypted using the corresponding reading key;

2. the SHA-256 of the reconstructed certified email-content representation matches the payload_sha256 recorded in manifest.json;

3. the SHA-256 of the exact manifest.json bytes matches the message imprint contained in the DigiStamp RFC 3161 timestamp response; and

4. the timestamp response validates using the trust material used for the verification.

This provides cryptographic evidence that the SHA-256 corresponding to the exact reconstructed certified email-content representation was recorded in the timestamped manifest no later than the DigiStamp RFC 3161 genTime.
Because the independently reconstructed certified email-content representation produces that same SHA-256, it is cryptographically linked to that timestamped manifest.


THREE DISTINCT TIMES

For certified email, three different times may be relevant.

1. MESSAGE DATE

The message date is a field contained in the certified email-content representation.

It reflects the date associated with the email record.

2. CERTIDOX CERTIFICATION-EVENT TIME

certification_event_time_utc in manifest.json is the time recorded by Certidox for the certification event.

3. DIGISTAMP RFC 3161 GENTIME

The RFC 3161 genTime is the independent time asserted by the DigiStamp Timestamp Authority.

These three times serve different evidentiary purposes and must not automatically be treated as identical.


CERTIFIER INFORMATION

manifest.json contains the certifier information and certifying organization recorded by Certidox.

Because those values are contained in the timestamped manifest, successful verification establishes that those recorded values were contained in the manifest no later than the DigiStamp RFC 3161 genTime and have not subsequently been altered without invalidating the timestamp verification.

This does not, by itself, independently establish that the human identity, personal authorship, authority or legal capacity associated with those recorded values was accurate when Certidox created the certification record.


NATIVE EMAIL VERSUS CERTIFIED EMAIL-CONTENT REPRESENTATION

document.json is the certified email-content representation.

It is not the native .eml file.

A native .eml file, forwarded email, screenshot, PDF rendering, printout or other transformed representation is not expected to have the same file-level SHA-256 as document.json.

Where the Certidox QR code remains readable, the QR code provides the linkage used to recover the certified email-content representation against which the corresponding content and certified fields of the presented email or copy can be examined.


ATTACHMENTS

Attachment files are not included in this verification bundle.

For each attachment, the certified email-content representation may record metadata including:

- filename;
- MIME type;
- byte size; and
- SHA-256 of the attachment bytes recorded at certification time.

The attachment SHA-256 is part of the certified email-content representation and is therefore protected by the same cryptographic chain described above.

If a file alleged to be an attachment is later supplied separately, its SHA-256 may be independently calculated and compared with the SHA-256 recorded in document.json.

A matching SHA-256 provides strong cryptographic evidence that the separately supplied file is byte-for-byte identical to the attachment whose hash was recorded in the certified email-content representation.

A matching filename alone does not establish attachment identity.


INDEPENDENT VERIFICATION

Except for any inquiry into the current live Certidox certification status, reconstruction of the certified payload and historical RFC 3161 timestamp verification do not require:

- access to the original mailbox;
- access to the original mail server;
- access to the Certidox live verification interface; or
- reliance on a Certidox-generated verification display.

The DigiStamp trust material required for RFC 3161 verification may be obtained independently of Certidox.


CURRENT CERTIDOX STATUS

The current Certidox certification status is a live service-side value.

It is separate from the historical cryptographic evidence contained in this bundle.

Offline verification of this bundle does not, by itself, establish the current Certidox status of the certification.


WHAT THIS BUNDLE DOES NOT ESTABLISH BY ITSELF

This bundle does not, by itself, establish:

- delivery or receipt of the email;
- the complete native .eml file;
- the complete email transport history;
- all SMTP, routing or MIME information;
- that the recorded From field proves which human physically initiated the transmission;
- personal authorship;
- legal authority;
- the factual truth of the email content;
- the legal admissibility or evidentiary weight of the record;
- fraud, intent or liability;
- the content of an attachment that has not been supplied separately for comparison; or
- attachment identity based solely on a matching filename.

Those matters require separate evidence where relevant.


EVIDENCE PRESERVATION

For evidentiary use:

1. preserve the original ZIP archive unchanged;

2. compute and record the SHA-256 of the original ZIP archive before extraction;

3. perform reconstruction and verification on a working copy;

4. preserve the original manifest.json and response.tsr unchanged; and

5. record the SHA-256 of any separately supplied file used for attachment comparison.

The SHA-256 of the ZIP archive identifies that particular exported archive.
It is distinct from the Certidox certification identifier and from the payload_sha256 contained in manifest.json.


SECURITY AND CONFIDENTIALITY

This archive contains both the encrypted certified payload and the reading key required to decrypt it.

Possession of the complete verification bundle therefore normally permits recovery of the certified content.

The bundle should be protected with confidentiality controls appropriate to the underlying certified email content.

Attachment files are not included in this bundle.


QUICK VERIFICATION

Work from a copy of the original archive.

Reconstruct the certified payload:

    python3 decrypt.py

Verify the historical cryptographic evidence:

    bash verify_timestamp.sh

A successful verification should confirm:

    Payload SHA-256: MATCH
    Manifest / RFC 3161 message imprint: MATCH
    RFC 3161 verification: OK

The DigiStamp RFC 3161 genTime reported by the verification is the independent Timestamp Authority time.

The current Certidox live status is not established by this offline verification.
