Storage of encrypted content encryption keys in an EDV

[tplooker]

In some instances a group of documents inside an EDV may have a common level of access meaning they could be encrypted with a common encryption key and that encryption key is then encrypted once (via key agreement and key wrapping) to each of the valid recipients. This optimisation can be useful to bypass the need to perform the key agreement and key wrapping step on each document inside the group.

How this would look for instance is an EDV persists a document of the following structure.

{
  "id":"z19x9iFMnfo4YLsShKAvnJk4L",
  "sequence":0,
  "jwe":{
    "protected": {
        "enc":"C20P",
        "kid": "https://edv.example.com/document/4287248957624"
    }, // base64 decoded
    "iv":"FoJ5uPIR6HDPFCtD",
    "ciphertext":"tIupQ-9MeYLdkAc1Us0Mdlp1kZ5Dbavq0No-eJ91cF0R0hE",
    "tag":"TMRcEPc74knOIbXhLDJA_w"
  }
}

Where the kid references another document in the EDV of the following structure

{
  "id":"z19x9iFMnfo4YLsShKAvnJk4L",
  "jwe":{
    "protected": {
        "enc":"A256KW"
    }, // base64 decoded
    "recipients":[
      {
        "header":{
          "kid":"urn:123",
          "alg":"ECDH-ES",
          "epk":{
            "kty":"OKP",
            "crv":"X25519",
            "x":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs"
          },
          "apu":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs",
          "apv":"dXJuOjEyMw"
        }
      }
    ],
    "iv":"FoJ5uPIR6HDPFCtD",
    "ciphertext":"tIupQ-9MeYLdkAc1Us0Mdlp1kZ5Dbavq0No-eJ91cF0R0hE", < - encrypted content encryption key
    "tag":"TMRcEPc74knOIbXhLDJA_w"
  }
}

Where the decryption of the above document yields the content encryption/decryption key for the first document.

Questions

1. The above approach can be implemented with EDV's today where an encrypted content encryption key is stored as an encrypted document, however if we wanted greater semantic separation we could elect to store encrypted content encryption keys under a new endpoint /keys instead of storing these as encrypted documents.

2. Should this pattern feature anywhere in the spec or is it more of a candidate for an implementation guide?

[OR13]

should kid be a URL, or would it be better if it were just a JWK thumbprint ?

Seems like replication would be broken if it were a URL.

[tplooker]

Good question I think this raises the general question of how to refer documents in an EDV that isn't instance specific, and or whether there should be a relative URL referencing scheme

[OR13]

yeah, I would say the URLs should be portable... or we failed... they are portable today.

AFAIK the proposal you are making is compatible, and could be supported.... it is not currently defined in the spec, or supported anywhere.

[OR13]

Whats the nexts step on this? my read is that its low priority and would require minor changes to support. I feel we have bigger fish to fry.

[agropper]

We are implementing something like this for the self-sovereign health record (vaccine credentials too) use-case and would really appreciate the community's input and participation.

Our architecture assumes that the actual health records are NOT in EDVs because the hospitals, labs, and payers have to have the data in the clear. We treat them as normal resource servers (Issuers and verifiers in SSI-speak). From a (GDPR) role perspective, they are "processors" (not "controllers") although they are very jealous of the controllers. I'm overstating this a bit for clarity.

The authorization server (AS) that represents the "controller" technology is modeled as an EDV that holds the policies for turning requests into access tokens at the resource servers (RS) as processors. In our model, as in @tplooker case above, each patient's policies are encrypted with a separate patient-level key. Unlike @tplooker use-case, we have no reason to wrap keys because the policies are never shared. As a matter of fact, for obvious security reasons, the AS can only read policies in the EDV. Policies are written to the EDV only by the user agent of the patient as resource owner (RO).

The interesting question then becomes, where are the keys to the policy EDV stored so they're accessible to the AS on a need-to-know basis when a request comes in to a particular patient? We don't assume that the RO's mobile wallet is online when a request comes to the AS. The encryption key will ideally be in a system that is separate from the EDV and is designed explicitly as a (Web) KMS. Like the EDV, the AS, and the RSs, the KMS should be a standards-based delegate of the RO. @tplooker seems to be asking whether the EDV and the KMS are one and the same? I have the same question.

The best-practice for our use-case will demonstrate zero-trust architecture built around DIDs, VC, and, as much as possible, capabilities. The design should also demonstrate how audits will mitigate the risk of a compromised AS or RS.

• Adrian

On Mon, May 24, 2021 at 8:38 PM @tplooker wrote:

In some instances a group of documents inside an EDV may have a common level of access meaning they could be encrypted with a common encryption key and that encryption key is then encrypted once (via key agreement and key wrapping) to each of the valid recipients. This optimisation can be useful to bypass the need to perform the key agreement and key wrapping step on each document inside the group.

How this would look for instance is an EDV persists a document of the following structure.

{ "id":"z19x9iFMnfo4YLsShKAvnJk4L", "sequence":0, "jwe":{ "protected": { "enc":"C20P", "kid": "https://edv.example.com/document/4287248957624" }, // base64 decoded "iv":"FoJ5uPIR6HDPFCtD", "ciphertext":"tIupQ-9MeYLdkAc1Us0Mdlp1kZ5Dbavq0No-eJ91cF0R0hE", "tag":"TMRcEPc74knOIbXhLDJA_w" } }

Where the kid references another document in the EDV of the following structure

{ "id":"z19x9iFMnfo4YLsShKAvnJk4L", "jwe":{ "protected": { "enc":"A256KW" }, // base64 decoded "recipients":[ { "header":{ "kid":"urn:123", "alg":"ECDH-ES", "epk":{ "kty":"OKP", "crv":"X25519", "x":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs" }, "apu":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs", "apv":"dXJuOjEyMw" } } ], "iv":"FoJ5uPIR6HDPFCtD", "ciphertext":"tIupQ-9MeYLdkAc1Us0Mdlp1kZ5Dbavq0No-eJ91cF0R0hE", < - encrypted content encryption key "tag":"TMRcEPc74knOIbXhLDJA_w" } }

Where the decryption of the above document yields the content encryption/decryption key for the first document.

Questions

1.

The above approach can be implemented with EDV's today where an encrypted content encryption key is stored as an encrypted document, however if we wanted greater semantic separation we could elect to store encrypted content encryption keys under a new endpoint /keys instead of storing these as encrypted documents. 2.

Should this pattern feature anywhere in the spec or is it more of a candidate for an implementation guide?

[TallTed]

Someone who has edit access to third-party comments could perhaps edit @agropper's latest comment above, to change all instances of `@tobias Looker **@.>** (no codefence) to **```@tobias Looker @.>```** (with codefence) or **@tplooker** (who is actually on the issue), so we stop pinging **@tobias`** about this issue?

Thanks, @dmitrizagidulin!

[tplooker]

Discussed on WG call 5th of August, no resolution taken about the future of the issue. Had a brief discussion about other potential usecases for the capability such as integration with a web KMS.

[dmitrizagidulin]

Discussed on Aug 2, 2021 call.

See comment on https://github.com/decentralized-identity/edv-spec/issues/42#issuecomment-912046683 -- this should be covered in the Sharing section.

[TallTed]

[@dmitrizagidulin] Discussed on Aug 2, 2021 call.

s/Aug 2/Sept 2/