Trinity's trust expressions are as fine-granular as needed. Whether it is delegating all the roles of the CEO position to a successor, or just the CEO's permission to access a specific room within the next hour, a simple statement will do or undo it in real time.

Present approaches based on X.509 certificate systems effectively give you a yes or no answer to a question (“Is this certificate valid?”) lacking all relevant context (“What for?”).

Common workarounds to this issue are “typed” certificates; ie. having a specific certificate for each role (developer, CEO, technician, …). What role a certificate holds is solely dependent on how the application interprets it. There's no inherent difference between the certificates used for different roles, they are interchangeable.

Our system answers a question that is subtly different: “Does the level of trust allow X?”.

Trust between participants in the trust network are modeled using scenario specific Trust Policy Languages¹⁾. This means a Trust Policy Language fulfills the requirements of a specific scenario.

Traditional approaches may offer a set of pre-defined values to which your specific challenge would have to be molded. Often times resulting in a sink or swim decision, using things in a not-quite-right kind of way.

P3KI on the other hand molds the Trust Policy Language to your challenge. And the Trust Policy Language can be the perfect balance between simplicity and flexibility that suits your need, all the while allowing arbitrarily fine-granular trust expressions.

You no longer need to use workarounds like typed certificates. You simply trust someone with a specific expression (control over all the building, control over just the doors, control over a specific office door for a specific point in time, control over room heating next Tuesday from 9 to 5, …

Performing operations in this context results in specific questions getting asked: “Is X allowed to unlock the front door of the building?” or “Is X allowed to change heating parameters for room 101?”. If X is trusted with control over the entire building both questions would be answered with a definite yes; if X is only trusted with controlling heating, the first question would result in a definite no.

The Trust Policy Language or the P3KI system in general does not require a concept of what a building or door is or what it means that you're allowed to control a heater. These semantic aspects are part of the modeling phase of a specific Trust Policy Language and later on no longer of concern to the system when it comes to evaluating trust. Evaluation is done purely as a mathematical operation, joining and meeting different sets of policies and verifying that the end result at least fulfills the initially asked for level of trust.

If your system does not allow fine granularity, delegation becomes a matter of all or nothing. For instance current Certificate Authority setups are build on a hierarchy of Authorities and a large number of non-authoritative leaf nodes (clients). Clients cannot further delegate trust since client certificates are not allowed to sign new certificates into existence. Certificate authorities however can create certificates for virtually everything they want without limitations.

Using our system it is easily possible to delegate very specific trust to others. If I'm trusted with turning on the heating in room 101, the most trust I can effectively delegate to someone else with is exactly this: turning on the heating in room 101. If I were to delegate more, this would automatically be caught in the mathematical evaluation phase, clipping any delegation that's too broad to at most the trust that was extended to me.

If your Certificate Authority was tricked into creating another authoritative certificate or if your authority's private key got stolen you having a problem is a mild understatement. Usually you don't even notice anything is wrong until it's too late (more examples: Diginotar, Digicert, …). If you didn't notice the compromise, the earliest next chance of catching it is someone using unexpected certificates via systems like Google's Certificate Transparency. In other words: having a Certificate Authority compromised is total bankruptcy.

The only thing that's left is revoking the affected authoritative certificates thereby breaking all certificates issued using them, be they legitimate or not.

Even worse: “migrating” legitimate certificates is equivalent to creating new ones requiring each and every client to be updated individually.

Fine granular trust expressions also allow well defined reasoning about the impact of compromised nodes. With our system the impact of compromise is always local to the compromised nodes and limited at most to the specific trust that was extended to the affected node.

Furthermore, since trust information is stored in a public peer-to-peer database, you can see newly created trust in near realtime. You actually can audit trust relationships.

Also, since you see all published trust of a given node you can revoke²⁾ trust directed at the compromised node and instead point it to a (newly created) alternative node. You then simply audit every trust the compromised node extended, only keeping legitimate trust information and extend equivalent trust from the replacement node.

Recovering from a compromised “Intermediate Certificate Authority” therefor becomes a trivial operation with very limited impact. No update of client certificates is needed.