Comparing X.509 Certificates with SSI
by Anton Al Najjar
What is X.509?
X.509 is a standard defining the format of public-key certificates, digital documents that securely associate cryptographic key pairs with identities such as websites, individuals, or organizations. Common applications of X.509 certificates include SSL/TLS and HTTPS for authenticated and encrypted web browsing, signed and encrypted email via the S/MIME protocol, code signing, document signing, client authentication and government-issued electronic ID.
The X.509 certificate contains an identity (a hostname, or an organization, or an individual) and a public key (RSA, DSA, etc.), and is either signed by a certificate authority or is self-signed. When a certificate is signed by a trusted certificate authority, or validated by other means, someone holding that certificate can use the public key it contains to establish secure communications with another party, or validate documents digitally signed by the corresponding private key.
X.509 also defines certificate revocation lists, which are a means to distribute information about certificates that have been deemed invalid by a signing authority, as well as a certification path validation algorithm.
Related but different
X.509 certificates tie data to a public key where X.509’s hierarchical public key infrastructure (PKI) is intended to vouch for the validity of the X.509 certificate. Further, X.509 extensions enable the inclusion of additional information. Similarly, DIDDoc’s primary purpose is to associate the public key with a decentralized identifier (DID). Rather than that, SSI relies on verified credentials to make a trustworthy assertion about a decentralized identity.
Another difference is that the DID is needed and serves as a unique identifier for the DIDDoc and must be capable of resolving to the DIDDoc. The DID adds a layer of concealment to the public key. As a result, the public key associated with a DID may be cycled without affecting the DID, making it a permanent identification.
When you visit a web site, your browser uses the X.509 certificate to establish a secure connection. Clicking on the lock 🔐 symbol to the left of the address bar will display information about the certificate which was signed by an authority organization attesting the information obtained. The certificate of the signing organization can provide its public key which can be used to do the check. This certificate is also signed using a private key whose public key is in yet another certificate, and so on. This is called a Certificate Chain.
SSI: data protection without intermediaries
The DID and DIDDoc are self-asserted and self-certifying. With the use of cryptographic means you can easily determine that the binding asserted in the DIDDoc has not been tampered with. Verifiable credentials are then used to tell you who or what the DID is bound to in a verifiable way. Self-Sovereign Identity ensures a simultaneous benefit on both holder and verifier. The person/user, first holder of the data, achieves full control over his or her identity, deciding whether and which certified attributes to make available to external parties, within a framework in which trust and data protection become the main elements.
To understand how this works let’s take the example of Hans Schreiner, the owner of Hans Schreiner GmbH who owns a self-generated DID and will collect and use several verifiable credentials from issuers including a governmental ID-issuing institution, his previous University and current employer. Hans would like to apply for a loan at Commerzbank and is required to submit several documents that validate his claims about himself and his employment status.
Hans’s first verifiable credential will be a digital ID issued by a governmental institution under the name of Gov-ID, built using Hans’s personal information like full name, address and other related data. This ID will then be stored as a credential on Hans’s digital wallet installed on his smartphone. Another credential Hans is going to need is a certificate of employment which he will get from his HR manager and which includes several fields like his income level and years of experience. Hans gets this proof in the form of other verifiable credentials stored in his digital wallet as well (he had to share his Gov-ID credential with his manager for that). Now, Hans has the loan requirements he needs and will present proofs of identity and income to his bank consultant through the credentials he owns in his wallet.
Zero Knowledge Protocol (or Zero Knowledge Password Proof, ZKP) describes a way of performing authentication where no passwords are exchanged. ZKP allows you to prove that you know some secret about somebody at the other end of communication without actually revealing it. The very term “zero knowledge” originates from the fact that no (zero) information about the secret is revealed, but the second party (Verifier) is “rightfully” convinced that the first party (Prover) knows the secret in question.
In our case, Hans is able to combine the attributes in these various credentials in a way that only discloses what Commerzbank is asking for and nothing more. Furthermore, his digital wallet was able to do this for him automatically without Hans having to pick and choose the various attributes from various credentials himself. The proof shows that the information from these two credentials is all bound to the person who controls the DID (which Hans presents to the bank). The proof also shows that these credentials have not been revoked.
Disadvantage of X.509
In case of X.509, Hans would be required to have a personal certificate with his public key which he would use to anchor each of these certificates. X.509 certificates are not linked in any way other than Hans’s public key, which means changing his public key implies that he needs to get new certificates. Besides, there is no easy way Hans can restrict attributes when sharing certificates as the entire certificate has to be shared as a whole. Commerzbank needs then to trust these certificates in the same way your browser does, by following the chain to a minimal set of trusted authorities for each one of the certificates (personal-ID, employer and so on). The bank in this case needs to check if the presented certificate is still valid.
Advantages of DIDS and DIDDocs
● DIDs provide a higher level of security and privacy protection: DIDs enable the rotation of PKs securely so you can safely change the PK underlying the DID without the need of getting new credentials. You are not persuaded to hold onto a possibly compromised key out of concern for the inconvenience. Furthermore, Verifiable credentials minimize information disclosure by presenting only what is required and necessary, not more. For example, you can prove you are over 18 without sharing your age or even your date of birth and of course none of the other information on your personal ID. ZKPs as well decrease the possibility of you sharing more than intended due to human mistakes
● SSI has a uniform user interface: SSI wallets and agents provide an excellent user experience in maintaining connections, saving credentials, and responding to proof requests. Hans can hold credentials from various issuers and present proofs to several verifiers due to standards of data formats and issuer and presentation protocols.
“By 2023, 65% of the world’s population will have its personal information covered under modern privacy regulations, up from 10% today.” — Gartner 2020