Did-core: Should DID support self-signed certificates?

[DurandA]

Do you plan to support (self-signed) certificate fingerprints instead of public keys?

I think that DID could be useful to WebRTC. WebRTC uses self-signed certificates that are identified by fingerprints (e.g. sha-256 0E:12:7C:D5:17:E6:01:74:17:0B:2E:AA:B9:D2:A9:D3:D9:C3:DB:CD:64:7D:EF:EC:20:5E:27:5C:5C:2F:A6:B6).

[kdenhartog]

I would think that this would be possible through the use of the did-core-registries. I see no reason that you couldn't do this either and it seems like a good piece of data that would fall within the did document.

[oare]

@kdenhartog Do I understand correctly that if it would not support it, then the DIDs would be backed by certificate authorities and therefore would not be any different to legacy IDM as we know it today? I'm struggling to understand how an entity/subject could become well-known without a root-of-trust CA. Maybe I missed something in the spec but a truly decentralized identity system should not need to rely on CAs to form well-known identities, no?

[DurandA]

@kdenhartog I did not dig very deep into all specs, but I don't see any assertion method not based on public keys in did-core-registries.

@oare I think that they define the DIDs in an abstract way so you could use it with a web of trust model.

Are the some introduction materials (video, documents...) besides the specs available?

[kdenhartog]

See PR #304 which updates the text to further specify it. As an example, ethereumAddress is a verificationMethod which is not a publicKey but can be used to provide cryptographic proof of control over a did. For additional discussion on this topic see issue #283

[OR13]

Closed issue related: https://github.com/w3c/did-core/issues/69

Simple answer would be no.

[selfissued]

I think that we should just say no to this. We're in the JSON/CBOR world. We don't need to drag in X.509 as well.

[tplooker]

@DurandA could you clarify by what you mean in regards to support? E.g are you asking about the use of a cert as a verification method, or creating self-signed certificates with key material associated to a DID?

[DurandA]

@DurandA could you clarify by what you mean in regards to support? E.g are you asking about the use of a cert as a verification method, or creating self-signed certificates with key material associated to a DID?

For the use-case of establishing a trusted peer-to-peer WebRTC connection with a DID subject, I think it means creating self-signed certificates with key material associated to a DID. WebRTC relies on self-signed certificate for DTLS session establishment. There is _getRemoteCertificates_ in the WebRTC API that enables retrieving of certificate fingerprint (more info). I guess that would imply using a certificate fingerprint as an authentication type.

[OR13]

@DurandA it is possible to use oneway functions of a public key as a verification methods in some scenarios... ethereumAddress and ECRecover are the most obvious.

perhaps you can propose an obvious JSON representations of what you mean? Here is a stab in the dark for inspiration:

"verificationMethod": [
 {
    "id": "did:example:123#key-1",
    "type": "KeyUsed",
    "publicKeyJwk": ... // might contain x5c
  },
 {
    "id": "did:example:123#self-signed-cert-fingerprint-1",
    "type": "DTLSVerificationMethod????20202",
    "selfSignedCertificateFingerprint": "sha-256-0E:12:7C:D5:17:E6:01:74:17:0B:2E:AA:B9:D2:A9:D3:D9:C3:DB:CD:64:7D:EF:EC:20:5E:27:5C:5C:2F:A6:B6"
  }
]

[DurandA]

@OR13 your proposal is pretty much what I would expect. Here is a slightly modified version:

{
  "id": "did:example:123#cert-0",
  "type": "X509V3RecoveryMethod2020",
  "controller": "did:example:123",
  "certificateFingerprint": "sha-256 0E:12:7C:D5:17:E6:01:74:17:0B:2E:AA:B9:D2:A9:D3:D9:C3:DB:CD:64:7D:EF:EC:20:5E:27:5C:5C:2F:A6:B6"
}

Here are the steps to recover the public key from a certificate:

1. Generate the certificate fingerprint and match it against certificateFingerprint
2. ?Check that it is a self-signed certificate?
3. Extract the public key from the X.509 certificate

[OR13]

@DurandA this can be accomplished via an extension, and unless every did method is trying to use this / its a very popular legacy crypto thing I would expect to use an extension for this.

IMO, the best way to proceed would be to write a Linked Data Signature Suite that supports this extension, and make some kind of demo of it using did:key and a browser... and then register the extension here: https://w3c-ccg.github.io/ld-cryptosuite-registry/

[msporny]

Discussion continues on the best way to support this.

[msporny]

This is almost definitely going to be an extension, and not go in DID Core. @DurandA, would you be happy with this mechanism to achieve your goals?

[OR13]

If there is a JWK representation and we retain publicKeyJwk @type: @json... its possible you could do this in DID Core without extensions... not sure about that though.

[msporny]

Waiting on @DurandA for feedback.

[msporny]

The WG discussed this on the 2020-09-01 call, we won't be taking an action on this since it is up to the key expression mechanism to support fingerprint (that is done outside of this WG - in the W3C CCG for Linked Data Security Cryptosuites), we have waited a month for feedback with no feedback. Therefore, we will close this in 7 days unless there is an objection.

[brentzundel]

No comments since marked pending close, closing.