Publication: 2022-Aug-19, updated: 2023-Jan-19

Kutchy® Manifesto

Keep URI Tracking Certified Hosts Yourself

for

Safe communication in email, API and cloud

 

There are already international technical standards and legal framework since long ago to exchange email and data, secure and compliant.

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 has now brought the existing standards to 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:

 

Background

Encrypted email: Back in the days in October 1995 the signed and encrypted email was standardized as RFC1847.

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
Flexible and configurable

Still, the difficulties below higlight what still was not solved particularely with email and data exchange in the cloud.

 

Problems

 

Email

Pricy and burdensome administrating individual certificates: 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.

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, GDPRLGPD 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 tech: 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, it is readable and may be modified while in transit.

 

eDelivery

Bad 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 revoked connectivity and have it's application certificate revoked.

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.

 

 

Solution

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, another subdomain is defined in a TXT record to use it's certificate 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 propose an open and decentralized internet solution for secure and compliant data and email exchange and this manifesto contribute to EC consultation for improvements of eDelivery. Kutchy manifesto propose that each domain (URL) owner configure their own 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 to receive encrypted emails and configure your DNS is a favorable to include all domain owners in society and not just the large organizations. 

Implementation steps

 

Trust in QWAC certificate 

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.

 

DNS (Domain Name System) settings

NAPTR (Naming Authority Pointer)

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, while EC wants a central SML network's organization to set it on their NAPTR DNS.

An example for email over eDelivery for the domain kutchy.com would have the ID: @kutchy.com to be hashed, encoded and removed the equal sign "=" would result in NAPTR record to become 47kit4nusngrr2jb5vjhh4o4k5dxy6scdr2nkrmrxiliqxigvvuq.kutchy.com

 

TXT (Text record)

An example for signed and encrypted email over SMTP for the domain kutchy.com would have a TXT record for the kutchy.com where you can define 2-3 URLs. One for ID, another for encryption and potentially a third URL for the API enpoint receiving email via https/eDelivery instead of SMTP:

  1. https URL to verify the identity of the domain. Has to point to a domain certificate that has its Common Name (AKA CN) with the domain or includes the domain in one of its SAN (Subject Alternative Name) extension field. SAN, a term often used to refer to a multi-domain SSL certificate. 
  2. URL to the public https certificate that shall be used to encrypt the data. That api shall return a web reply header "KUTCHY" that states what encryption it wants for the data to be sent. Should be the same domain or sub domain.
  3. https API URL where to send the data (required for eDelivery email, not SMTP)

 

Definitions in eDelivery

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. Example is 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.

 

Subscribe to our newsletter and upcoming release or send your comment about the manifesto to our email.