Publication: 2022-Aug-19, updated: 2024-Apr-16

Kutchy® Manifesto

Keep URI Tracking Certified Hosts Yourself

for

Safe communication

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:

Background

Encrypted and signed 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 with secure information exchange

Email

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.

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.

eDelivery's issues

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.

Solution for eDelivery and Email

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 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 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

• Configure TXT record to set Kutchy policies for ordinary SMTP email and API.
• Set DNSSEC on your domain.
• Get a QWAC for your domain, API and eDelivery URLs.
• Configure NAPTR for eDelivery networks for secure email.
• For eDelivery install an open source software or commercial software.
• Have your IT administrator to install Kutchy Add-In (about to be released).

Trust in QWAC (Qualified Website Authenticated 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.

VMC - Verified Mark Certificate

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 your 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.

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, 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, 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 in tags. One tag for ID, another for encryption and potentially a third URL for the API enpoint receiving email via https/eDelivery instead of SMTP. Other tags are optional: 

1. Idetity (id=URL) 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. Encryption (e=URL) https URL to the public 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. API location (l=URL) https API URL where to send the data (required for eDelivery email, not for SMTP). Can point to a third party provider's URL, commonly a cloud provider or via CNAME.

Example of a TXT record:
KUTCHY=guidVerificationString1213abc; v=KUTCHY1; id=https://kutchy.com; e=https://kutchy.com; l=https://edelivery.kutchy.com;

Required tags

• KUTCHY=guid display that this domain addhere to Kutchy policy.
• v=KUTCHY1 indicates the version of the KUTCHY record.
• e=The URI to the public certificate to use for encrypting file(s), email(s) and data. It may be a sub URL. The web response shall have a KUTCHY header with values.

Recommended tags

• es=Encryption standard and algorithem that is applied.
• et=Relats to ec. Encryption certificate type that is used. If it is the tls certificate in https communication that is used, or a pem file at a unique URL (https) link or from an WSDL/XML file on a site, like for a SMP URL location according to eIDAS regulations building block eDelivery.
• id=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.
• ids=An electronic digital signature encoded in base64 of the ultimate beneficial owner of the domain, for whom it must be used for and by. Commonly a JWS.
• idp=Relates to ids. The provider or/and issuer of the digital signature to know how to verify the electronic digital signature. Like FREJA, GOOGLE, MICROSOFT, UBISECURE, QSEAL and APPLE.
• ds=DKIM selector to the subdomain to [selector._domainkey.domain.com] to find and check DKIM and DMARC compliance prior to sending an email.
• egw=Email address that acts as a gateway for all incoming encrypted emails.

Optional tags

• l=URI to the API to receive file(s), email(s) and data.
• lt=Type of API to expect, like eDevliery version.
• lip=The IP addresses from where the api request come from at this domain when it wants to send files to and external party's domain api.
• bs=BIMI selector subdomain value to [selector]._bimi.domain.com to find and check if BIMI record exist and retreive the owner, logo and certificate info.
• idh=The hash value of a digital agreement for an ID provider to verify domain.
• cah=The hash value of a digital agreement for a CA (Certificate Authority) to verify domain.

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

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