We have added the ability to create custom trust chains in Certisfy that are verifiable independent of the Certisfy PKI root. These trust chains will lack the identity component of trustworthy Certisfy certificate so owners of such chains are responsible for implementing their own identity procedures.

Receivers of claims from such custom trust chains will have to whitelist (bookmark in Certisfy) the root certificate in order for claims from those certificates to pass verification. Use cases for custom trust chains are many.

There is currently an ongoing challenge around software supply chain security, ie developers integrate software libraries and components into their own applications and solutions are faced with the prospect of unwittingly including malicious vulnerabilities.

The problem ultimately boils down to the difficulty of ensuring the people who have write access to these packages are trustworthy. This would remain an ongoing problem requiring not just core due diligence by package owners and maintainers but the general ecosystem monitoring. Even after vetting a contributor, it is still possible they are malicious/compromised.

Another front related to this challenge has to do with AI instruction packages, ie packages such as agent skills. Packaging AI instructions via skills and distributing for general use is likely going to be a key way to scale AI utility by making it possible for more users to leverage the work of others.

If one person has done the work of packaging instructions and supporting material (including code) for a given task, it makes sense to facilitate the re-use of that effort.

Distributed trust solutions via cryptographic trust chains are not a silver bullet but could certainly help a lot.

In Certisfy, you can create certificates that support delegation and use that to implement your own trust chain. For instance any well-known and trusted entity/individual can create a root certificate and via delegation build a trust chain from that root.

Each trust chain is free to institute its own rules/procedures for validating and issuing certificates. The Certisfy toolkit is flexible. Users can whitelist trusted roots both in Certisfy or through third-party SDK integrated solutions.

Git for instance supports verification for commits but that doesn't support any delegation mechanism by default. You can however use a key on a trusted chain for commits thus making that mechanism much more flexible, or embed your commit signing public key onto a trusted chain certificate.

In other words a verifier can verify a git commit signature, then validate that the issuer of the signature is on a trust chain they trust.

Non-Technical Use cases

There are countless no-technical uses cases that follow a delegated authority approval structure that works well when implemented as a trust chain. These can be both long-run processes or short projects or just fun activities.

Nothing described above requires something like Certisfy, you can achieve some of the same things with openssl and a cli tool for instance, the Certisfy value prop at least in this context is UX, especially as it relates to trust delegation.

Here is a demo of how one use these capabilities: