How to integrate certificates with DIDs?

[OR13]

Is the publicKey field to be used for certificates as well? I'm eager to define potential mappings between GPG / SSH / x509 and DIDs.

[OR13]

Many useful legacy systems rely on certificates, not raw public keys:

https://www.cs.bham.ac.uk/~mdr/teaching/modules/security/lectures/PGP.html

https://github.com/Netflix/bless

https://learn.hashicorp.com/vault/secrets-management/sm-pki-engine#steps

So far, the publicKey section of a DID Document has been used to store raw public key material, or derived values like ethereumAddress.

It seems to me that the authentication section would be the appropriate place to store certificates, here is a hypothetical DID Document with support for certs and PGP added:

{
  "@context": "https://www.w3.org/2019/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [
    {
      "id": "did:example:123456789abcdefghi#keys-1",
      "type": "RsaVerificationKey2018",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
    },
    {
      "id": "did:example:123456789abcdefghi#cert-1",
      "type": "RootCertificate",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyPem": "-----BEGIN CERTIFICATE...END CERTIFICATE-----\r\n"
    },
    {
      "id": "did:example:123456789abcdefghi#key-2",
      "type": "PgpKey",
      "controller": "did:example:123456789abcdefghi",
      "publicKeyPgp": "-----BEGIN PGP PUBLIC KEY BLOCK...END PGP PUBLIC KEY BLOCK-----\r\n"
    }
  ]
}

One concern I have is that since certificates often contain information other than raw key material, there is a risk of PII leakage (from email embedded in PGP keys for example).

I have heard rumors of a did-x509 integration work, I would love to see more examples of using certificates added to the spec.

[OR13]

We should consider closing this issue, if certificates are not useful or nobody has opinions about this topic, I'm not enough of an expert to solo this concept.

[selfissued]

I would advocate not using certificates in our data structures (other than TLS certificates, which are part of the Web infrastructure). We should be exclusively using JSON data representations, barring compelling reasons to do otherwise.

[OR13]

@selfissued thanks for your view!

https://tools.ietf.org/id/draft-miller-jose-pkix-key-00.html

"
This document specifies an approach which encodes a chain of PKIX certificates as an array of strings within a JWK object.

PKIX certificates have a number of advantages, such as an established process of certification and attribution of entities. It is also sometimes desirable for JSON-based cryptographic operations to support the existing and widespread deployment of PKIX-based technologies.
"

seems like choosing JWK would enable this sort of thing, that would be my preference. Id rather not see many certificate formats, like we currently see with public key types.

[OR13]

But I'm also fine making the recommendation not include certs in DID Docs, that was my main hope in raising this issue. We would get a hard yes (and here is how) or a hard no, with reasons why.

[selfissued]

To be clear, JWKs already support including certificate chains using the "x5c" parameter. See https://tools.ietf.org/html/rfc7517#section-4.7. So we wouldn't need any new standards to include them. I'm just personally advocating as a best practice that we not use them.

[OR13]

Here is an example of what embedding x5c cert in BTCR publicKey might look like:

   {
    "id": "did:btcr:xxcl-lzpq-q83a-0d5#1b94c",
    "type": "RsaVerificationKey2019",
    "publicKeyJwk": {
       "kty":"RSA",
        "use":"sig",
        "kid":"1b94c",
        "n":"vrjOfz9Ccdgx5nQudyhdoR17V-IubWMeOZCwX_jj0hgAsz2J_pqYW08
        PLbK_PdiVGKPrqzmDIsLI7sA25VEnHU1uCLNwBuUiCO11_-7dYbsr4iJmG0Q
        u2j8DsVyT1azpJC_NG84Ty5KKthuCaPod7iI7w0LK9orSMhBEwwZDCxTWq4a
        YWAchc8t-emd9qOvWtVMDC2BXksRngh6X5bUYLy6AyHKvj-nUy1wgzjYQDwH
        MTplCoLtU-o-8SNnZ1tmRoGE9uJkBLdh5gFENabWnU5m1ZqZPdwS-qo-meMv
        VfJb6jJVWRpl2SUtCnYG2C32qvbWbjZ_jBPD5eunqsIo1vQ",
        "e":"AQAB",
        "x5c":
         ["MIIDQjCCAiqgAwIBAgIGATz/FuLiMA0GCSqGSIb3DQEBBQUAMGIxCzAJB
         gNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYD
         VQQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1
         wYmVsbDAeFw0xMzAyMjEyMzI5MTVaFw0xODA4MTQyMjI5MTVaMGIxCzAJBg
         NVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDV
         QQKExNQaW5nIElkZW50aXR5IENvcnAuMRcwFQYDVQQDEw5CcmlhbiBDYW1w
         YmVsbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL64zn8/QnH
         YMeZ0LncoXaEde1fiLm1jHjmQsF/449IYALM9if6amFtPDy2yvz3YlRij66
         s5gyLCyO7ANuVRJx1NbgizcAblIgjtdf/u3WG7K+IiZhtELto/A7Fck9Ws6
         SQvzRvOE8uSirYbgmj6He4iO8NCyvaK0jIQRMMGQwsU1quGmFgHIXPLfnpn
         fajr1rVTAwtgV5LEZ4Iel+W1GC8ugMhyr4/p1MtcIM42EA8BzE6ZQqC7VPq
         PvEjZ2dbZkaBhPbiZAS3YeYBRDWm1p1OZtWamT3cEvqqPpnjL1XyW+oyVVk
         aZdklLQp2Btgt9qr21m42f4wTw+Xrp6rCKNb0CAwEAATANBgkqhkiG9w0BA
         QUFAAOCAQEAh8zGlfSlcI0o3rYDPBB07aXNswb4ECNIKG0CETTUxmXl9KUL
         +9gGlqCz5iWLOgWsnrcKcY0vXPG9J1r9AqBNTqNgHq2G03X09266X5CpOe1
         zFo+Owb1zxtp3PehFdfQJ610CDLEaS9V9Rqp17hCyybEpOGVwe8fnk+fbEL
         2Bo3UPGrpsHzUoaGpDftmWssZkhpBJKVMJyf/RuP2SmmaIzmnw9JiSlYhzo
         4tpzd5rFXhjRbg4zW9C+2qok+2+qDM1iJ684gPHMIY8aLWrdgQTxkumGmTq
         gawR+N5MDtdPTEQ0XfIBc2cJEUyMTY5MPvACWpkA6SdS4xSvdXK3IVfOWA=="]
       }
  }

We could add specific language to the publicKey section advising users not to use this functionality.

[OR13]

Extend your context, do what you want.