[PROPOSAL] Complement and eventual replacement of X.509 digital certificates -Standards / NEP

Thanks to a previous discussion about use of custom NFT for mutual authentication, I am focusing on the complement or replacement of digital certificates. The NEP509 I would like to put forward is explained here:

Summary

Properly designed custom non-fungible-tokens can complement or replace X.509 digital certificates for most purposes. The design presented can be easily extended for any number of use cases that use digital certificates. among them TLS communication, mutual authentication, electronic mail, digital signing and time stamping.

Motivation

Public Key Infrastructure is a prevalent way to use public key encryption. The original motivation of this NEP proposal are the many flaws in Public Key Infrastructure. It is beyond the scope of this NEP to explain these flaws in detail, please refer to the sources [1][2][3][4]. Using blockchain issued tokens equivalent to digital certificates can provide better functionality than traditional digital certificates without compromising security. Currently there are no other NEP specifications covering this specific use case.

Terminology

Some terms are used with a specific meaning, as follows:

  • Rich Online Digital Token: Abbreviated as RODiT, is a non fungible token which lifecycle and structure is conformant with this document.
  • Issuer: The organization that creates a smart contract that is used by the Service Providers to mint their RODiT.
  • Service Provider: Organization that signs its RODiT digitally and provides a service to users where RODiT are used for mutual authentication.
  • Holder: A person or system that controls a RODiT via a key pair in a cryptographic wallet.

Problems solved

In this document we call the custom non-fungible-tokens used Rich Online Digital Tokens (RODiT for short). The problems solved are the following:

  1. When implementing mutual authentication with X.509 digital certificates, the workflow has several steps, one of them requires transferring a file (CSR) between the endpoint and the CA. With RODiT we use a workflow with fewer steps, without file transfer, that is completed when the RODiT is sent (not installed), to a blockchain address. The impact of using a simpler process becomes highly significant as the number of participant nodes grows.

  2. With X.509 digital certificates, key rotation requires issuing and installing a new digital certificate when the key is due to be rotated, regardless of the expiration date of the service being secured with the digital certificate. With RODiT key rotation is decoupled from service expiration, as it does not require issuing a new RODiT. Key rotation using RODiT can be performed independently for every node, without any coordination between the parties, greatly simplifying the management of key rotation.

  3. Rogue Certificate Authorities (Issuers in X.509 terminology) can generate digital certificates to any identifier, despite of Certificate Transparency and CAA records, making key pinning necessary in high security scenarios. Any X.509 Issuer can create a digital certificate for any domain name, while the legitimate owner of the domain name may not be aware it has been issued. While RODiT are based on smart contracts controlled by Issuers, it is the Service Providers that issue and revoke RODiT for the identifiers they control, and the Service Provider has the exclusive prerogative to authorize the smart contract. This prevents Unexpected Certificates as described in [2], making key pinning unnecessary. This NEP describes a mechanism for domain names use by service providers to declare what issuers are trusted to issue valid digital certificates for them, removing this threat.

  4. It is not possible to detect private key compromise with X.509 digital certificates until the key is used without authorization, and recovery can be complex as certificate revocation is not uniformly checked by all parties, thanks to the fact that X.509 certificates can be verified off line. Using RODiT a compromise can be detected quickly. As the RODiT is associated with a blockchain address, the only way the attacker can keep exclusive control of the RODiT is moving it to a new address. This can be observed publicly as soon as it happens. Besides, as RODiT can only be verified online, so all parties will react immediately to the RODiT being revoked and will not accept it. Man in the middle attacks are far more challenging using RODiT than X.509 certificates, as we can verify validity against multiple RPC providers or even have our own local NEAR node.

Potential use cases

Rich Online Digital Tokens can be used as a complement or replacement of digital certificates for VPN authentication (reference implementation), TLS authentication and API authentication, among others.

References

1 Ten Risks of PKI: What You’re not Being Told about Public Key Infrastructure - Carl Ellison and Bruce Schneier
2 Problems with the Public Key Infrastructure (PKI) for the World Wide Web - [draft-housley-web-pki-problems-00.txt] - Russ Housley and Karen O’Donoghue
3 PKI considered harmful - Ian Grigg
4 Timeline of Certificate Authority Failures - SSLmate

For example right now is not possible to access the url api.nearspace.info due to a expired certificate…sigh. I was trying to understand how API are implemented accessing NEAR. I was trying to understand better near-api-rest-server.

If I don’t receive any additional feedback, positive or negative, I will proceed to publish the proposal on Github, is that ok?