use did:web for the services so we can rotate keys without having to redo delegations

[Gozala]

Currently we use did:key as service identifier. That is problematic because every time we want to rotate key we have to update the clients with a new key and old clients will no longer work.

It would make sense to just switch to did:dns so we can rotate keys when needed without having to upgrade all the clients

Out of scope

• Actual DNS resolution is out of scope for now, on backend we should just have in memory mapping of did:dns -> dns:key for our keys.
• Supporting other actors did:dns identifiers in delegation chains is out of scope (we can just error saying we failed to resolve the key).
• Support keys that were rotated. So when we rotate the key we may get the the delegation chain which has our did:dns in the chain but with key that is no longer in rotation. We do need to support that use case long term, but for now it's out of the scope, we can work on this when we actually go about rotating keys

[Gozala]

Here is some idea based on discussion https://filecoinproject.slack.com/archives/C02BZPRS9HP/p1668716338471879 an d https://filecoinproject.slack.com/archives/C02BZPRS9HP/p1668722431402189?thread_ts=1668716024.894469&cid=C02BZPRS9HP

1. We create new "certification key" and keep it's private key very very secret (ideally in some hardware)
2. We publish public "certification key" under did:dns:web3.storage.
3. We have another "service key" that we rotate on regular bases (e.g. once a month).
4. We publish public "service key" under did:dns:api.web3.storage.
5. We also publish "service key certificate" (not sure where) which is public "service key" with "certification key".
6. Ucans signed with did:dns:api.web3.storage will include fct like:
   { 'did:dns:api.web3.storage': { key: 'did:key:zCurrentServiceKey', certificate } }
7. Our backend will have in-memory access to:
   a. Certificate public key
   b. Service key pair

Above setup would allow backend to do following:

1. Resolve did:dns:api.web3.storage to did:key:zCurrentServiceKey without any IO.
2. Verify that at a time when UCAN was issued did:key:zCurrentServiceKey was public key in rotation by
   a. By checking that certificate is did:key:zCurrent signed by certificate key.
3. Profit

In other words I think we have a tractable solution to key rotation, we could harden this further by adding another layer, meaning we could have "supreme key" used for rotating "certificate keys" which is used to rotate "service keys".

[Gozala]

I'm also observing some broad pattern here, where we could use UCANs inside UCANS as opposed to describing some custom fact encodings etc... What it boils down I trust some key principal, and it could state facts that I can trust without verification in other words, lets say we have this supreme did:key:zCertificateAuthority, then we could have UCAN like this:

{
   iss: 'did:key:zAlice',
   aud: 'did:dns:api.web3.storage',
   att: [{ can: "store/add", with: 'did:key:zAlice', root }],
   fct: [
    { iss: 'did:key:zCertificateAuthority',
      aud: 'ucan:',
      att: [{ can: 'did/set', with: 'did:dns:api.web3.storage', nb: { did: 'did:key:zServiceKey' } }]
    }
  ]
}

Basically we can generalize the whole idea of building up a lookup table using UCANs inside the facts, so if you can trust some did:key you can trust all of the facts it states

[blaine]

Generally this makes sense (disclosure: I haven't seen the filecoin slack discussions).

I do think there are some questions about DNS proofs. Obviously if you have an X509 with a cn that matches the DNS signed by an entity in a reasonable cert chain, then you could just use that key, or/that is we could use Let's Encrypt's mechanism (ACME) here.

did:dns seems a bit comparatively complicated? The downside is that we'd need to figure out how to specify the verification of the X509 version if we go that route. did:web might be an alternative that's perhaps closer to ACME?

(aside: reading did:dns and did:web, these methods seem awfully "spec-first" and theoretical – are there examples of them being used in the wild? Not to be contrarian, just thinking about what gaining adoption would look like)

[Gozala]

did:dns seems a bit comparatively complicated? The downside is that we'd need to figure out how to specify the verification of the X509 version if we go that route. did:web might be an alternative that's perhaps closer to ACME?

Why is dns:dns complicated it's just one TXT record that from which you can resolve did:key. I think did:web is more complicated because now you have to deal with DID documents with whole lot of things that goes into them.

[blaine]

That's a good question! 🤔

Maybe it's not! I'm not sure, tbh. I have a gut feeling that there's a missing piece around key management wrt did:dns; how do I get that did:key, how do I store it, etc? Maybe all these things are simple and I'm just not used to the ecosystem!

[Gozala]

I do think there are some questions about DNS proofs. Obviously if you have an X509 with a cn that matches the DNS signed by an entity in a reasonable cert chain, then you could just use that key, or/that is we could use Let's Encrypt's mechanism (ACME) here.

I think I need to do some reading on the subject to understand what you're describing.

(aside: reading did:dns and did:web, these methods seem awfully "spec-first" and theoretical – are there examples of them being used in the wild? Not to be contrarian, just thinking about what gaining adoption would look like)

I'm not sure. I'm approaching it from very pragmatic standpoint, which is:

1. We need our service to have did so things could delegate to it without tying delegation to the key in rotation.
2. We need to be able to rotate service key on regular basis without having to redo all the delegations.

It seems that we could use did:dns effectively with very little effort, because all we need to do to rotate a key is publish DNS record

_key1._did.danubetech.com. IN URI 100 10 "did:key:z6MkjvBkt8ETnxXGBFPSGgYKb43q7oNHLX8BiYSPcXVG6gY6"

Now secondary goal is to be able to do UCAN verifications without having to do bunch of DNS lookups (or any IO really). We could achieve that by having a "certificate key" that we sign rotations with and embed actual keys in UCANs. That way our backend only needs certificate public key to verify everything without even doing any DNS lookups

[Gozala]

how do I get that did:key, how do I store it, etc? Maybe all these things are simple and I'm just not used to the ecosystem!

I think expected behavior is during verification you do a DNS lookup of for record that follows did:dns: and you get back did:key. I don't think you need to store it anywhere, although some caching is probably a good idea

But as I alluded to earlier we'd like to avoid even that DNS lookup which I think we could do by embedding something along the lines of dns-sd announcements in the UCAN itself (signed by trusted did:key, which in our service case will be hard coded but also published as DNS record so others could do the lookup)

[blaine]

Nice. Yeah, I think in general I'd say if this works for your use-case, especially in a closed-loop environment, full steam ahead! I'm prematurely expanding out the thought process and applying this to the NNS context, where it would be great to be able to do this in a more general way and where e.g., using the existing keys people use for HTTPS might be a viable option to delegate DNS record -> did

[expede]

In the original flow described in the message starting

Here is some idea based on discussion https://filecoinproject.slack.com/archives/C02BZPRS9HP/p1668716338471879 an d https://filecoinproject.slack.com/archives/C02BZPRS9HP/p1668722431402189?thread_ts=1668716024.894469&cid=C02BZPRS9HP

It looks like the ID is rooted in a certificate authority.

1. Is that a correct read?
2. If so, what does this give you that a UCAN delegation wouldn't?

[expede]

(To clarify: for a lot — but not all! — cases, you can use a root UCAN as a de facto certificate authority. This keeps it in the authZ world though, and you may be trying to solve for authN?)