How would one import an existing x509 cert into Ockam?

[mathewprokos]

Say I have a x509 cert already. Are there any examples of how one might go about using this with Ockam?

[mrinalwadhwa]

Hi @mathewprokos thanks for trying Ockam. We don't currently have x509 certs based attribute attestation / authentication. We instead have very simple signatures based credentials that are lightweight. There are some possible ways to support x509... I would love to learn more about what you're trying to build.

[mathewprokos]

I have devices with RSA signed certs already. I also have the public key to the root cert.
I'm wondering if there is a way to construct an Ockam identity/cert with this in order to setup trust between these devices. Ignoring the format of the data I was hoping I could bootstrap Ockam in some way with the existing chain of trust.

[mrinalwadhwa]

bootstrap Ockam in some way with the existing chain of trust.

This is supported in our design as a general idea with multiple implementations - we call them Enrollment Protocols. An enrollment protocol is a set of steps that result in an issued Ockam Credential.

New enrollment protocols are very easy to add. One for your specific case will need some development.

Here are couple of Enrollment Protocols that currently exist (our docs site is in development but this guide has more details)

Enrollment Protocol based on one time use enrollment tokens:

Enrollment Protocol based on proving identity attributes using an OpenID Connect Identity Provider like Okta, Auth0, AzureAD etc.

The general idea is - an Ockam Credential Authority, starts off with some Trust Anchors. It then observes some proof that has trust rooted in one of its trust anchors and then issues an Ockam credential based on this observed proof to an enrollee. Now the enrollee can participate in protocols that have trust rooted in the identifier / public keys of this Ockam Credential Authority.

So in your case the trust anchor for enrollment would be the root RSA CAs public key.

Here is a sketch of what a new enrollment protocol to support you need may look like:

sequenceDiagram
    autoNumber
    Admin->>Authority: Provision authority with RSA Root CA public key
    Enrollee->>Enrollee: Use Enrollee's private RSA key to sign an attestation <br> that attests a claim that included Ockam Identifier (public key) <br> belongs to the same entity as the included RSA public key.<br> Sign this attestation again with the Ockam Identifier's Curve25519 private key.
    Enrollee->>Authority: Present the above attestation from step 2 + RSA signed cert
    Authority->>Authority: Validate signatures on the presented attestation.<br> Validate signature by the enrollment trust anchor on the RSA signed cert.<br> Validate that the subject RSA public key included in the RSA signed cert and the presented attestation is the same.<br> --- <br> If all this checks out: <br> Issue an Ockam Credential, signed by the authority, to the Ockam Identifier included in the presented attestation.<br> Optionally include other attributes in the new credential (mentioned in the RSA cert or pre-configured in the authority).
    Authority->>Enrollee: Send Credential
    Note right of Enrollee: Use new Ockam Credential to prove attested attributes<br> and setup end-to-end encrypted, authenticated and authorized channels.

Loading

Note that this is just one possible enrollment protocol. Depending on your exact provisioning setup, there are also other designs that may work better. If you can share more about the current state of these devices and how they can be provisioned / updated. We can discuss other possibilities.

This may seem complicated at first glance but because of the building blocks that already exist in Ockam (like vaults, identities, authorities and secure channels) is simple to build in a secure way.

Support for this is on our roadmap but there our other things that are higher in priority.
If you or someone in our community wants to work on it, I would be happy to help along the way.

If you have a business need for this then let's connect over email [email protected].
We can prioritize feature development for paying customers.