The Internet already has a global, distributed namespace. There is no technical reason why legally reliable digital communications should depend on a centralized directory.
KUTCHY promotes a DNS-native legal messaging infrastructure where every domain owner can publish and operate its own trusted communication capabilities.
Just as a domain owner publishes MX records for email, it should also be possible to publish:
No central registry should be mandatory. The owner of the domain should remain the owner of its legal messaging namespace.
KUTCHY defines a DNS-native namespace for legal messaging.
Each messaging domain or application defines its own participant identifier format.
A participant identifier is transformed into a deterministic DNS label using a published hashing profile.
For Safe Email, the participant identifier is:
@example.com
and the DNS label is calculated as:BASE32(SHA256(participant-id)) This architecture allows multiple legal messaging ecosystems to coexist while sharing the same decentralized DNS discovery framework.
SHA-256
↓
Base32
↓
Remove '=' padding
↓
DNS subdomain
The resulting label is published under the KUTCHY namespace:
[participant-hash].example.com
↓
lxwxanhrrwxln47iuknzz35vbbfcliuj5kmorpo3ssrojx4hll5a.example.com
This identifier becomes a stable, globally unique and transport-independent participant namespace.
The cryptographic evidence package is the permanent object. Transport protocols are interchangeable.
Evidence Package
|
+-- SMTP
+-- AS4
+-- HTTPS API
+-- Cloud Transfer
+-- Upload files
+-- USB stick
+-- Future Protocols
The evidence package remains unchanged regardless of the transport.
A Safe Email is an evidence package that contains:
SMTP and AS4 become equivalent delivery mechanisms. Legal validity is attached to the evidence package, not to the transport.
DNS should advertise legal messaging capabilities in the same way that it already advertises web and email services.
transport=SMTP,AS4,HTTPS
gateway=safe@example.com
edelivery=https://as4.example.com
signature=BankID,Freja,ZealiD
evidence=RFC1847-JSON
Clients discover capabilities automatically and select the best available communication method.
Create a distributed legal messaging namespace where cryptographically verifiable evidence packages can travel over any transport mechanism, while trust remains anchored in DNS and the domain owner.
KUTCHY believes that the future of digital trust is not another central directory. It is a decentralized Internet where every organization can host and publish its own legal messaging capabilities.
KUTCHY defines the framework. Safe Email defines one participant profile.
[participant-hash].example.com Deploy your own Safe Email gateway in under one hour for free.
KUTCHY Safe Email conclution
KUTCHY defines the framework. Safe Email defines one participant profile.
Namespace: example.com
participant-id=@domain
participant-hash=BASE32(SHA256(participant-id))
participant-id=@example.com
participant-hash=BASE32(SHA256(participant-id))
DNS=[participant-hash].example.com
multipart/encrypted
multipart/signed
message/rfc822
application/json
Kutchy simplify safe communication with existing open standards, rules and laws into a neat solution.
To exchange email and data in a secure and compliant way, there are already international technical standards and legal framework since long ago to accomplish that.
Why are you not already using it? It is because a user-friendly interface, affordable and decentralized way for each domain owner to configure it has been missing.
Kutchy brings these existing standards in a neat solution where you with ease can have a safer email and data exchange using your current email and cloud providers.
Example of a received email where you can see missing DKIM and DMARC:
Example of a received, decrypted and verified email:
Example of a sending an encrypted email where the receiver have safe and compliant eDelivery:
Example of sending an email where you can see who the receiver organization is:
Encrypted and signed email: Back in the days in October 1995 the signed and encrypted email was standardized as RFC1847. It allows the entire email to be signed as a RFC 822 message, and later it was replaced by RFC 2822 and then RFC 5322. The European Commission does emphasize the adoption of RFC1847 for the European Union for broader usage and adoption.
Secure and compliant data exchange: The European Commission ("EC") has understood how important and fundamental it is for the EU's public and private sector to have a trusted, secure and compliant data exchange. For that reason EC created eIDAS (The Regulation on electronic identification and trust services for electronic transactions) regulation, and within eIDAS defined the eDelivery framework. eIDAS is a key enabler for secure cross-border transactions. eDelivery provides technical specifications and standards, installable software and ancillary services to allow projects to create a network (file/message type) of nodes (participants) for secure digital data exchange. However, eDelivery's uses AS4 (https) OASIS ebXML message which is agnostic to what kind of files and data that is exchanged between parties asynchrony. The older version AS2 is used for communication with banks when sending SWIFT or ISO20022 messages to them.
eDelivery in the end claim to solve issues as:
Interoperability
Scalability and performance
Security and accountability
Vendor and platform agnostic
Finding connected eDelivery/AS4 parties in a decentralized internet
Flexible and configurable
Still, the main difficulties below higlight the centralized networks did not solve data and email exchange on the internet.
Centralized solutions: EC thought it would be necessary to have a central Service Metadata Locator (SML) to control each network for each kind of message and its participants verified unique ID, API url and compliant with technical requirements. With eDelivery's current central SML, it becomes very detrimental to scale connectivity, heavy administration and pricy for smaller organizations. EC therefor made a consultation to the public of how to improve the eIDAS regulation and recently for eInvoice. EC's CEF eDelivery information of SML and SMP in pdf is found here.
SMP is also more centrally administrated.
Manual connectivity: The SMP and connectivity check and security compliance is monitored and should be reported if unfit. A party can be disconnected if the network revoke the party's certificate.
Lack individual traceability: eDelivery does not address that in many cases that the receiver needs to know the individual who sent a file or data.
Pricy and burdensome administrating of individual certificates per user: The signed and encrypted email standard RFC1847 was thought to have an encryption and decryption key for each user, that turned very administrative to handle and technical to set up. The standard does not require each individual to have it's own encyption certificate, but signature.
Big tech companies never adopted encrypted email standards: Most large email providers and software did not support it out of the box, so usually you will need to chose an email provider and software to use signed and encrypted emails.
Missing legal compliance: More recent privacy, GDPR, LGPD and data protection act regulations sometimes question that the entire email was not encrypted so the exchanging parties and the subject information is visible to external parties.
Insecure SMTP: Emails are transferred over the inherently insecure asynchrony SMTP (Simple Mail Transfer Protocol) with limited DKIM, SPF and DMARC implementation in general for safety. Even as most email servers implement TLS over the SMTP protocol, each server the email passes on the way to the recipient can read and modify the email while in transit.
Migrating from SMTP to https: Your email provider may have support for both SMTP and https (eDelivery) to receive and send emails.
Automated security implementation: To handle encryption, it is easier and safer to use the publicly known home page domain certificate for every email user in that domain rather then using per user certificates, and to encrypt the entire email rather then part of the email as body and attachments to comply with privacy. Optionally, defined in a TXT record to use it's certificate, or VMC instead for encryption. To decrypt emails, you do not let users access the private key to decrypt, but only let the user to have access to the function (API) to decrypt its own emails. The function lets the organization's system verifying the user and scan the email for malware prior to return the decrypted email to the user.
Decentralized automatic connectivity: Kutchy framwork propose an open and decentralized internet solution for secure and compliant data and email exchange and this white paper contribute to EC consultation for improvements of eDelivery. Kutchy white paper propose that each domain (URL) owner configure their own SML (Service Metadata Locator) and DNS themself and with it, the other participants of the networks can automatically verify its connectivity, ID and security prior to data exchange. It is applicable to both email and API. Just like you configure your DNS for your home page A record and email provider MX record.
The SML and SMP connectivity check and security compliance is verified automatically and visible to the user, like in the Kutchy Add-in prior to sending any email.
Legal compliance: eDelivery is very applicable to emails to substitutes the insecure asynchrony SMTP that has been debated for long time how to merge to safer https.
In any case, a signed and encrypted email using the RFC1847 on the entire email over eDelivery, you can verify organizations prior to sending emails that is signed by the individual and on message level verified organization. To add the signed and encrypted email functionality of today's classic SMTP transfer of emails, Kutchy Add-In provides this functionality out of the box for every user to send it over classic SMTP or/and eDelivery. Using the receiver’s domain's certificate instead of a per user classic public encryption key, administration is diminished, whereas trust, compliance, privacy, security, ID verification, simplicity, affordability and usability is greatly enhanced. Some has suggested that the eDelivery for emails would substitute fax messages.
Affordability: A solution that may use your current homepage domain certificate och other public certificate belonging to your domain, such as the security.txt file on sites, to receive encrypted emails and configure your DNS is a favorable to include all domain owners in society and not only for the large organizations.
Implementation steps for high trust
Highest trust as a party/node, you need to obtain a QWAC (Qualified Website Authenticated Certificate) where you usually are required to go to a notary and prove who you are, being a signatory of said organization and prove that you control your domain. The QWAC works both as a server and client certificate and commonly used between banks in API and is part of the eIDAS regulation.
The less trusted domain/server certificates are EV (extended Validation), OV (Organization Validation) or least trusted DV (domain validation) certificates.
This is a certificate that cryptographically proves your intelectual property right from World Intellectual Property Organization’s (WIPO) of trade marks and points our where the logo (or name) and certificate can be obtained and verified in a BIMI record defined in a TXT DNS record like default._bimi.[yourdomain.com].
The BIMI record with link to created logo and certificate will make it possible for the recepient of your emails to see your logo in their inbox of your email, for them to trust your emails.
It is a EV (extended Validation) certificate for your trade mark's logo, not for your homepage https connection. The certificate is usually allowed to be used for s/mime encryption and signature.
According to eDelivery rules, the ID for a node in a network shall be hashed by SHA256, then base32 encoded, removed "=" (equal sign) and set as the sub-domain of your domain, as it is allowed to set your own SML network's organization to your own NAPTR DNS. This rule makes everyone able to find out what domains adhere to secure email exchange defined by eIDAS regulation.
An example for email over eDelivery for the domain kutchy.com would have the ID: @kutchy.com to be hashed by SHA256, encoded and removed the equal sign "=" would result in NAPTR record to become: 47kit4nusngrr2jb5vjhh4o4k5dxy6scdr2nkrmrxiliqxigvvuq.kutchy.com
An example for signed and encrypted email over SMTP for the domain kutchy.com would have a TXT record for the kutchy.com domain where you can define 1-3 URLs in tags. One tag for encryption, potentially another for ID, and a third URL for the API enpoint receiving email via https/eDelivery instead of SMTP.
Example of a TXT record found at: 47kit4nusngrr2jb5vjhh4o4k5dxy6scdr2nkrmrxiliqxigvvuq.kutchy.com
Lists of "cf" parameter values:
Lists of "ea" common parameter values:
Algorithm Parameter, Value: Algorithm
Lists of "ea" common parameter values:
Alg Parameter Value: Algorithm
Lists of "cf" parameter values:
API - Application Programing Interface, a web API in our case for a URL where a computer can receive and reply data.
CEF - Connecting Europe Facility
ID - or the SMP-ID is the unique ID in the network of the participant/node. The ID will be hashed and encoded and set as a subdomain to the organizers DNSZONE (being the SML network's domain).
Network - One type of message/file set in the SML. One example is the digital EU invoice PEPPOL (Pan-European Public Procurement Online)
Node - A participant's organization.
SML - Service Metadata Locator, address registry for all participants in the network.
SMP - Service Metadata Publishing, capability lookup API location.
© -Kutchy ® - A product developed by Nilsson International AB
Publication: 2022-Aug-19, updated: 2026-Jun-18