Storage of encrypted content encryption keys in an EDV #45
Comments
|
should Seems like replication would be broken if it were a URL. |
|
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 |
|
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. |
|
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. |
dmitrizagidulin
transferred this issue from decentralized-identity/confidential-storage
|
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?
|
|
Thanks, @dmitrizagidulin! |
|
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. |
|
Discussed on Aug 2, 2021 call. See comment on #42 (comment) -- this should be covered in the Sharing section. |
|
s/Aug 2/Sept 2/ |
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.
Where the kid references another document in the EDV of the following structure
Where the decryption of the above document yields the content encryption/decryption key for the first document.
Questions
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
/keysinstead of storing these as encrypted documents.Should this pattern feature anywhere in the spec or is it more of a candidate for an implementation guide?
The text was updated successfully, but these errors were encountered: