How much would you like to receive and send email, documents and data secure while staying compliant and know who you communicate with? One of the 10 most desired solutions in EU is to exchange information safe, secure and compliant within EU between members states entities. Therefore the European Commission draw up a framework that is called eDelivery and is a building block of CEF (Connecting Europe Facility) and regulated in eIDAS. We focus on sending and receiving emails via decentralized eDelivery services for each domain owner.
For about three decades there has been a desire for making email secured with proof of who actually sent it and who received it at what organizations while compliant to regulations.
eDelivery is based on AS4 that is ISO standard and uses https as transmission layer and its file content can be of any type, therefore we promote using the file format of an email. AS4 provides receipt of delivery as standard.
eDelivery requires domain certificate of type QWAC that also work as client certificate to prove who receives and sends between the API endpoints according to eIDAS regulations. A signing certificate QSeal should be used to know what organization that actually sent the email as third parties may be acting as technical providers.
Since 1995 there is the standard RFC1847 to sign and encrypt emails and other data that the European Commission promote. We use the receivers home page's domain certificate to encrypt the email and Freja eID to sign the email.
In EU each country has a catalogue of it's national digital service. There is also a domain for each eDelivery service in Europe that manage the centralized DNS to point to where the ULR of each entity connected service, like the PEPPOL is hosted at. The DNS record for eDelivery is called NAPTR and stands for Name Pointer. Each of so called "network" that PEPPOL is one example of, has to define a unique identifier how to identify each connected member. In the case of PEPPOL, it is the VAT number of the entity.
The regulation does not require a central DNS manager for the "network", it could very well be managed by each entity/domain them self, just like the DNS MX record is used for email sent by SMTP. The unique identifier should be the domain name and hashed as defined in eDelivery framework.
You make verify that the receiver of a secure email is compliant prior to sending signed and encrypted email.
You make setup your own services and make your own domain become compliant as you progress without a no third party certification and burdensome management.
While you continue to use your ordinary email provider, you may use that to exchange signed and encrypted email while you migrate to use the same email software like Outlook to send the emails via eDelivery to every entity that adopt to email via eDelivery.
Also ordinary citizens may use the their ordinary email to send and interact with other public and private entities.
.png)
