Public Key Infrastructure (PKI)

Status Quo

Secured data exchange comprises 3 aspects

Privacy
if data falls into the wrong hands, end-to-end encryption prevents misuse. (Line/point-to-point encryption only prevents interception of a connection, but not misuse at switching nodes)
Authenticity

signing a message can guarantee the true identity of the sender
Integrity

a checksum can exclude a falsification of the transmitted data

Complex cryptographic public-key algorithms play a central role here. The basic principle is comparatively simple:

messages/data that have been encrypted with the public key of a requesting user (consumer) before transmission can only be decrypted with the corresponding private key of this user upon receipt. A public key must always be obtained from a trustworthy source
encrypted messages/data may additionally contain a checksum with which the requesting user can verify whether a manipulation has taken place during the transmission path
messages/data that are encrypted with the private key of the sending/requesting user can be verified with the public key of the sending/requesting user when received

There are different alternatives how a user can generate his public key, where it is stored and what has to be done in the event of a loss of the private key (e..g. in the case of theft of appropriate hardware).

Certificate Authorities(CA) digitally sign and publish the public key of users/applications. The industry standard for monitoring active Transport Layer Security (TLS) certificates (espc. for https), is dominated by a handful of major CAs
Decentralized PKI eliminates dependence on hierarchical PKI managed by centralized CAs., i.e. each entity can serve as its own root authority. The W3C DID Working Group is currently developing a standard for decentralized identifier(DID)
A Web of Trust uses self-signed certificates from an internal CA in e.g. a company. The distribution takes place in a so-called 'key-signing-party' i.e. an event at which people present their public keys to others in perso
Blockchain-based PKI is an emerging approach for PKI that uses the blockchain technology. Some cryptocurrencies support the storage of different public key types

The interrelationships are quite complex, and overwhelm ’normal' Internet users. This is particularly true if there are alternatives or even competing processes (e. g. OpenPGP vs. S/Mime).

Despite the existing solutions, there is still a need for an easy-to-use and widely used PKI.

UNITED-PAGES

UNITED-PAGES enables an elegant handling as PKI through the unique ’symbiosis' of email addresses and web-services.

A private-/public-key can be created and stored as pky-UNIT:

Variable	Example
privatekey	-----BEGIN PRIVATE KEY-----MIIJQw...-----END PRIVATE KEY-----
publickey	-----BEGIN PUBLIC KEY-----MIICIjANB...-----END PUBLIC KEY-----
hashtype	SHA-512
keybits	4096
encryptiontype	RSA
_updated	2019-07-14T17:08:09+02:00

The URL of the pky-UNIT can be derived from the email address of the PRODUCER e. g.

Email	John.Doe@goohoo.com
URI	unit://pky/John.Doe@goohoo.com
URL	https://.../pky/john.doe/goohoo.com

By default privatekey is read-protected (and there is no must to store it within the UNIT). Knowing the email-address enables web-access on the public-key of the owner e.g.

GET (URL)	https://.../pky/john.doe/goohoo.com
Response(JSON)	{ "publickey":"-----BEGIN PUBLIC KEY-----MIICIjANB...-----END PUBLIC KEY-----", "hashtype:":"SHA-512", "keybits":"4096" , "encryptiontype":"RSA", "_updated":"2019-07-14T17:08:09+02:00" }

PROVIDER and email-provider are generally identical for a user. Since an email-provider is considered trustworthy (often e.g. passwords are sent via email during registration with a web-portal) a PROVIDER can also be considered trustworthy and the need for further certification of a private-/public-key is eliminated.

The management of a pky-UNIT is (as with all UNITs) under the complete control of the owner/PRODUCER. If a private-key is lost, the key pair can be renewed immediately.

UNITED-PAGES can be used as PKI for e.g. Identity-Access-Management and Digital-Signature.

Especially the pky-UNIT is also used internally to access protected data .

The adjoining example from the UniterPager APP shows that the USER steve@smail. com has protected his mobile phone number from public access. He allows the USERs chris@cmail.com and charly@cmail,com read-access to all contact data, the USER bernd-werner@gmx.net even write-access.

When the WEBSERVER of the PRODUCER (here: smail.com) is different from the WEBSERVER of the requesting CONSUMER (here: cmail.com / gmx.net) the authorization includes a web-request from the WEBSERVER of the PRODUCER on the pky-UNIT of the CONSUMER. Details can be found in the API esp. how the method pays tribute to the complex public encryption.