Vulnerability disclosure
Reporting a security issue
If you believe you have found a security weakness in EnSign, we want to hear from you. This page is our disclosure policy: how to report, what we promise in return, and the safe harbour we give to research done in good faith. A register is the most sensitive thing EnSign holds, so a report is taken seriously from the moment it arrives.
What we promise
- We acknowledge every report within 5 working days, at the address you give.
- We tell you whether we could reproduce the issue and what we are going to do about it.
- We fix it on the timeline below, and tell you when it is fixed.
- We do not take legal action against research that follows this policy.
How quickly we fix
Our timeline follows the risk-based logic of CISA's Binding Operational Directive 26-04: how exposed the weakness is, whether it is being exploited, whether an attack can be automated, and how much control it gives.
| Situation | Fixed in production within |
|---|---|
| Known to be exploited, and reachable from the internet in EnSign | 3 days |
| Critical or high severity, in code that serves requests | 7 days |
| Critical or high severity, not reachable by a request | 30 days |
| Moderate or low severity | 90 days |
| A compromised package in our supply chain | Immediately: deploys stop until it is gone |
Safe harbour
If you make a good-faith effort to follow this policy, we consider your research authorised. We will not pursue or support legal action against you for it, and if someone else does, we will make it known that you acted within this policy. In return, we ask that you:
- test only accounts you own, or have the account holder's written permission to use;
- stop as soon as you see data that is not yours: a vessel, an owner, a document or a person belonging to another organisation. Do not copy, keep or share it. Report what you saw, not the data itself;
- do nothing that degrades the service for others: no denial of service, no load testing, no high-volume automated scanning;
- do not use social engineering, phishing or physical access against EnSign, its staff or its customers;
- do not send test messages to a registry's own mailboxes or submit applications to a real registry;
- go no further than you need to show the issue exists;
- give us a reasonable time to fix it before you say anything publicly. We ask for 90 days, or until the fix is out if that is sooner, and we will agree a date with you.
Scope
In scope: www.en-sign.co and every page and console reached from it, the actions and APIs those pages use, and the certificates and documents EnSign produces.
Out of scope: the services EnSign is built on (report those to their owners), anything that needs a compromised device or browser, missing best-practice settings with no demonstrated effect, volumetric attacks, and output from automated scanners without a demonstrated issue.
No bounty
We do not pay for reports and do not keep a public hall of fame. We will thank you directly and, if you ask, confirm in writing that you reported the issue and when.
What happens to your report
Your report is stored in EnSign's restricted database and sent to the people who handle security. We keep it for 2 years so we can answer you if you come back about the same issue, then delete it. See the privacy notice. The machine-readable version of this page is /.well-known/security.txt.
Checking an audit trail yourself
Every registry's audit trail is part of one chain. No entry can be changed or removed without it showing: each is sealed with its registry's own key and with a fingerprint that depends on every entry before it, and we publish the latest fingerprint, a root, every day. A registry's console gives it its key, checks its trail against a root and can save the proof. The steps, for anyone who would rather use their own tools (hashes are SHA-256 in lowercase hex; “+” joins text):
- Take the entries in order from 1. Entry 1's previous hash is 64 zeros; every other entry's is the hash of the entry before it.
- For each entry, compute your tag: HMAC-SHA256 with your key of “ensign-audit-tag:” + the entry number. An entry carrying your tag is yours, and must come with its text; any other must come without.
- For your entries: the salt is HMAC-SHA256 with your key of “ensign-audit-salt:” + the entry number; the hash of salt + text equals the entry's fingerprint; and the text is a JSON array whose first item is the entry number and whose second is your organisation's id.
- For every entry: the hash of previous hash + tag + fingerprint equals the entry's hash.
- The last entry's number and hash equal the root's.
Other registries' entries reach you as hashes only: without their keys, nobody can tell whose they are or recover what they say. Keep copies of roots. A root you kept is the one we cannot quietly replace; a check against today's root shows only that the chain and the root agree.
Send a report
Tell us what you found, where, and how to reproduce it. If the details need a more private channel, say so in the summary and we will agree one with you before you send them.