Attestation Deep Dive

A Merlonix attestation is a tamper-evident record that certifies: this asset, at this point in time, was in this state, and was verified by this method.

This reference explains how each verification method works, what a certificate contains, how tamper evidence is constructed, and how the audit log is structured.

---

What a certificate contains

Every attestation — regardless of verification method — produces a certificate with the following fields:

The state hash is the critical tamper-evidence component. It is computed from the certificate payload at issuance time and stored immutably. Any post-issuance modification to the payload would produce a different hash — the verification endpoint detects this and returns tampered rather than verified.

---

Verification methods

Inline

Inline attestation records a descriptive statement about the asset and issues the certificate immediately, without an external challenge.

Use when:

• The asset being attested is a deliverable, a document, or a decision — not something that can serve a file or a DNS record
• You need immediate issuance (client approval email, logo delivery confirmation, contract handoff)
• The evidence is the statement itself: "Logo pack v3 was delivered and approved on [date]"

How it works:

1. You enter a statement describing what is being certified
2. Merlonix hashes the statement along with the asset identity and timestamp
3. The certificate is issued immediately with status verified

Limitation: Inline attestation certifies that a statement was made and recorded. It does not independently verify technical state (e.g., that a particular file is deployed). For technical verification, use DNS TXT or HTTP file.

---

DNS TXT record

DNS TXT attestation places a cryptographic challenge token in the domain's DNS records. Merlonix resolves the record to confirm control.

Use when:

• The asset has a domain you control DNS for
• You want to prove that the party operating the domain authorised the attestation
• Clients or auditors need to be able to independently verify DNS control at issuance time

How it works:

1. Merlonix generates a unique verification token for this attestation
2. You add a TXT record at _merlonix-verify.<hostname> with the value merlonix-verify=<token>
3. Merlonix resolves the TXT record and confirms the token is present
4. The certificate is issued with status verified and the DNS record value captured at verification time

DNS propagation: TXT records typically propagate within 30–60 seconds if your TTL is low. If verification fails immediately, wait 60 seconds and retry. Merlonix checks the record up to three times with 30-second intervals.

After issuance: You can remove the TXT record after the certificate is issued. Merlonix captures the resolved value at issuance time — future DNS checks are for SSL/DNS monitoring, not for attestation revalidation.

---

HTTP file

HTTP file attestation serves a challenge file at a well-known path on the domain. Merlonix fetches the file over HTTPS to confirm the token.

Use when:

• The asset has a domain serving HTTPS traffic
• DNS is managed by the client or a third party, making DNS TXT impractical
• You want to prove that the party controlling the web server authorised the attestation

How it works:

1. Merlonix generates a unique token for this attestation
2. You create a file at https://<hostname>/.well-known/merlonix-<token>.txt containing the token value
3. Merlonix fetches the file over HTTPS and confirms the content matches
4. The certificate is issued with the HTTP response status and content captured at verification time

HTTPS requirement: The file must be served over HTTPS with a valid certificate. Merlonix does not follow HTTP-to-HTTPS redirects — the file must be directly accessible at the HTTPS URL.

After issuance: Like DNS TXT, you can remove the file after the certificate is issued.

---

The public verification URL

Every certificate has a public verification URL:

https://merlonix.com/verify/<certificate-id>

Anyone with the URL — a client, their legal team, a third-party auditor — can verify the certificate status without logging in. The verification page shows:

• Certificate ID and issuance timestamp
• Asset label and hostname
• Statement
• Verification method and evidence captured at issuance
• Current status: verified, revoked, or tampered
• State hash comparison result

The URL is permanent. Even after revoking a certificate, the URL remains accessible and shows the revocation timestamp and reason.

---

Tamper evidence

Merlonix uses a two-layer tamper detection approach:

Layer 1 — State hash. At issuance time, Merlonix computes SHA-256(payload) where payload is the JSON-serialised certificate fields. The hash is stored alongside the certificate. The verification endpoint recomputes the hash on every request and compares it against the stored value.

Layer 2 — Audit log immutability. Every attestation action — create, verify, revoke — is written to an append-only audit log. The log is write-once: entries cannot be modified or deleted. The audit log is the authoritative source if the certificate record itself is disputed.

For the tamper evidence to be meaningful, the state hash must be verifiable by a party that did not issue the certificate. The public verification URL provides this: a client, auditor, or legal representative can independently confirm that the certificate hash matches the stored value, and that the hash was recorded at the stated timestamp.

---

Revoking a certificate

Revocation marks a certificate as no longer valid. Revoked certificates remain in the system and on the public verification URL — they are not deleted.

When to revoke:

• A deliverable was replaced by a newer version (revoke v2, issue v3)
• A dispute arises and the certificate is no longer the correct representation
• An error was made in the attestation statement

How to revoke:

1. Navigate to Attestations
2. Find the certificate
3. Click Revoke
4. Enter an optional reason (stored in the audit log and displayed on the verification URL)

After revocation, the public verification URL immediately shows revoked, the revocation timestamp, and the reason if one was provided. Anyone who previously received the URL sees the updated status on their next visit.

Revocation is not deletion. The certificate history, original statement, and revocation record remain accessible. Revocation records when and why a certificate stopped being valid — it does not erase the record of it ever having been valid.

---

Replacing a certificate

Merlonix does not have a built-in "replace" operation. The workflow is:

1. Revoke the existing certificate with a reason such as "Superseded by v3 — see [new certificate URL]"
2. Issue a new attestation for the updated deliverable
3. Share the new certificate URL with stakeholders

If you reference the new certificate URL in the revocation reason, anyone following the old URL can immediately navigate to the current certificate.

---

Audit log retention

Merlonix retains the attestation audit log for 7 years from the date of the most recent event on each certificate.

The 7-year retention window is aligned with standard document retention requirements in commercial and marketing services contracts. If your engagement agreements require a 5-year or 3-year retention period, Merlonix's 7-year window covers it.

The audit log records:

The audit log is not user-editable. It is available to tenant owners and admins under Settings → Audit log.

---

Method comparison

---

Next: read Client Status Pages to give clients a live monitoring view, or Alert Channels to configure where attestation-related notifications are sent.