RFC 0019: Updating to JWE compliant data model #133
Comments
|
Please be aware, this issue is also posted on the DIDComm-js library in DIF. I'll facilitate communication across the groups if you don't want to track both conversations. |
|
I would like to see Aries using a JWE compliant data model. I am in favor of the proposal. |
|
the above example is for Authrcrypt, below is the Anoncrypt example: |
|
It's worth pointing to the internet draft that originally defined the JOSE AEAD algorithm for chacha20: https://tools.ietf.org/html/draft-amringer-jose-chacha-00 |
|
I have just updated the draft to include ECDH-ES bits: |
|
@gamringer I'm not finding documentation or an IANA registry of the |
|
I'm writing up the I-D for ECDH for JOSE separately from the Chacha for JOSE I-D. I'm writing it up to have the |
|
Ok, since we're registering the |
|
Then we can register both |
|
That seems like a good solution that will allow us to work with multiple types then. |
|
@gamringer @kdenhartog I pushed an initial PR to our go-jose fork to support the above format using Go: |
@gamringer @kdenhartog can we have an updated JWE format with |
|
I finished reimplementing my proposal in PHP: https://github.com/gamringer/php-authcrypt This is the output of 1-crypt.php: |
|
I believe we should update the format to meet the standards and reference them in the docs. @gamringer, I gathered these links from the discussion we had such as:
https://tools.ietf.org/html/rfc7518#section-4.6.2 More specifically about the alternative format for
we should probably update the format to reflect these changes |
This change adds support to encrypt agent's payloads for the Pack() call at the transport layer It follows JWE encryption instructions from Aries Issue: hyperledger/aries-rfcs#133 Signed-off-by: Baha Shaaban <[email protected]>
|
@kdenhartog @gamringer, I just pushed the Go implementation of the JWE encryption (decryption will be coming up soon). Here is an example format: Go PR: hyperledger-archives/aries-framework-go#107 as mentioned in my previous post, we need to update the format a little and confirm if we're using |
This change adds support to encrypt agent's payloads for the Pack() call at the transport layer It follows JWE encryption instructions from Aries Issue: hyperledger/aries-rfcs#133 Signed-off-by: Baha Shaaban <[email protected]>
This change adds support to encrypt agent's payloads for the Pack() call at the transport layer It follows JWE encryption instructions from Aries Issue: hyperledger/aries-rfcs#133 Signed-off-by: Baha Shaaban <[email protected]>
This change adds support to encrypt agent's payloads for the Pack() call at the transport layer It follows JWE encryption instructions from Aries Issue: hyperledger/aries-rfcs#133 Signed-off-by: Baha Shaaban <[email protected]>
|
Update on this. I've been looking at this recently and trying to weigh all factors that would get us good interop between all parties in DID community. Since this change would create a breaking change, I want to make sure that what ever we move to accounts for all of our needs for quite some time. For example, one thing that I didn't account for that I'd like to in the future is the ability to add in forward secrecy when we perform this breaking change. Since I know this work is blocking @Baha-sk my recommendation is to implement the currently non-compliant JWE for now and we'll say that it is version 1. This will give us time to figure out what we want and to conduct a larger discussion as to what we should do going forward. Does that feel like a reasonable approach? |
|
Thanks @kdenhartog for taking the time to look at this issue, and your continuing efforts. We would like to use a compliant JWE. We have already started implementing this updated approach. I am concerned about:
With these concerns, I cannot say that deferring the compliant version is the correct path. It would be much better to become compliant as soon as possible (as the v1), and then iterate from there as needed. |
|
@Baha-sk : I am content with the idea that we should split verification keys and encryption keys apart; the conflation of these was an accident of us using Ed25519. And I get that you're advocating the removal of the verkeys from the JWE. That's all fine. But what I don't know if we're aligned on is this: I want an encryption key value--NOT a reference to an encryption key named in a DID doc--to be named in the JWE, and I want a verkey value--NOT a reference to a verkey in a DID doc--as the field that a JWS uses to verify. |
|
@dhh1128 the encryption keys in the JWE example are real public key values. They are not reference IDs nor are they stored in the DID doc. |
|
Saw this update on the DIF issue tracker: (referring to https://github.com/digitalbazaar/minimal-cipher and digitalbazaar/encrypted-data-vaults#5) |
|
The above noted effort allows:
Also note the kid format:
|
|
The kid format is fatally flawed unless it includes a versionstamp or (less optimally) a timestamp. How can we get it upgraded? |
|
It would be nice to have alignment across communities on these topics. I was also going to mention that it would be nice to have overlapping algorithm support in the envelope. Note that they have |
|
How is the |
|
I think we need to be clearer around the intention of the kid in different circumstances. When we are talking about encryption/decryption, the kid is really acting as an alias to a private key the recipient should have, whereas when we are verifying a signature, the kid should allow the audience of the signature to obtain a public key to perform verification. |
|
I agree that we need to be clearer about intention. However, that doesn't affect my assertion that the Understand: I'm not saying that the idea of It's flawed because without a versionstamp or timestamp, it can't be dereferenced -- either for encryption or for signature validation. Analogy: you want an email address, and I give you "@example.com" as the answer. I claim that answer is fatally flawed, because it doesn't include the mailbox identifier. A |
|
I understand your reasoning, but this key format proposed I dont think is fundamentally flawed in the way you are describing for encryption and decryption, which is the context it is being applied in, because the fragment portion is a fingerprint. Which implies an immutable and unique reference to a single key. Say you rotate a key but some sender continues to send you encrypted messages to your old key, provided you still have the old key indexed in your kms by this kid format, you should still be able to decrypt the message. And safely decrypt messages from new keys linked to the same did. I do understand that because identifiers for keys in did docs are not enforced as immutable by default (e.g not every key featured in a did doc has an id corresponding to the keys unique fingerprint) this is not a universal rule for all did methods. However, this as a kid format if it were universally supported I believe would work without major issue for encryption/decryption. Essentially when it comes to a kid for a signature, the easiest option to preserve verification is to make the kid the public key, no dereferencing required. However when it is an encrypted message the kid must be some meaningful alias to the recipient, there really is no need to have a versionstamp or timestamp, either the alias means something to me as a recipient or it doesn't. |
The problem is that the key value is immutable, but the key's meaning with respect to the DID doc -- the context in which that key is related to the DID -- is not. That key value might have been authorized to encrypt on behalf of the DID at point A, and not authorized to encrypt at point B, and you wouldn't know that. So you could do naked decryption with just the key value, but you can't do the semantic validation that should follow naked decryption, without the additional context.
I disagree. You are assuming that all decryption happens at the time of transmission, which is also the time of reception. If you separate those timeframes, the "either it means something to me or it doesn't" unravels. It might not mean something to me at the time I receive it, but it might be important that it means something to me later. Or vice versa. |
|
A |
|
@selfissued : Right. 100% agree. I think My concern is that the intersection between Now, fans of JW* in DID circles have suggested eliminating Possible solution 1: we stop thinking that Possible solution 2: we like |
|
IMO the case you describe @dhh1128 should be offloaded for the recipient software to deal with, e.g if recipient software rotates a key and the same kid is used in a did doc, what does the recipient software do with the old key? If its deleted then you can't decrypt anyway regardless of having a timestamp. If the software keeps the key, then how is its indexed in the kms? Could you not preserve its association to the |
|
Alternatively if you don't want to traverse all previous keys associated to a |
|
I do however disagree with trying to pack more meaning into the |
|
The DID spec provides a format for identifying a DID Doc at a specific time using either the
|
|
It does, but doing this adds a lot of complexity in parsing this field. If there is a problem with kid reuse for multiple keys over time, I think the simple choice is for the audience or consumer of the message to iterate through the keys associated to one kid or for there to be a seperate field in the kid header that hints at timing information and therefore allows them to limit the possible keys the |
|
IIRC, I heard there was discussion about this during the connectathon. Would anyone be able to provide details about that discussion here for historical context? |
|
My memory of the conversation was that we got to a stalemate. @tplooker , please confirm. The comment thread here boils down to 2 basic positions, which also summarize the connectathon discussion:
FWIW, the ticket about this issue in the DID spec repo includes a comment from one of the JWE spec authors (Mike Jones) that suggests the intent of |
|
@dhh1128, yes your summary is correct. |
|
Continue issue here: decentralized-identity/didcomm-messaging#22 |
Recently there's been discussion to update this work to be fully JWE compliant. One of the proposed solutions that's come up is to generate the following format:
{ "protected": base64url({ "typ": "prs.hyperledger.aries-auth-message", "alg": "ECDH+XC20PKW", "enc":"XC20P" }), "recipients": [ { "encrypted_key": "base64url(encrypted CEK)", "header": { "kid": "base58(Recipient vk)", "iv": "base64url(CEK encryption IV)", "pk": "compactJWE(Sender PK)" } }, { "encrypted_key": "base64url(encrypted CEK)", "header": { "kid": "base58(Recipient vk)", "iv": "base64url(CEK encryption IV)", "pk": "compactJWE(Sender PK)" } } ], "aad": "base64url(sha256(concat('.',sort([recipients[0].kid, recipients[n].kid]))))", "iv": "base64url(content encryption IV)", "ciphertext": "base64url(ciphertext)", "tag": "base64url(AEAD Authentication Tag)" } Exploded example of compactJWE(Sender PK): { "protected": base64url({ "iv": "base64url(CEK encryption IV)", "epk": "Ephemeral JWK", "typ": "jose", "cty": "jwk+json", "alg": "ECDH-ES+XC20PKW", "enc":"XC20P" }), "encrypted_key": "base64url(encrypted CEK)", "iv": "base64url(content encryption IV)", "ciphertext": "base64url(Encrypted Sender vk as JWK)", "tag": "base64url(AEAD Authentication Tag)" }Here's a provided example of what this would look like:
{ "protected": "eyJ0eXAiOiJwcnMuaHlwZXJsZWRnZXIuYXJpZXMtYXV0aC1tZXNzYWdlIiwiYWxnIjoiRUNESCtYQzIwUEtXIiwiZW5jIjoiWEMyMFAifQ", "recipients": [ { "encrypted_key": "whpkJkvHRP0XX-EqxUOHhHIfuW8i5EMuR3Kxlg5NNIU", "header": { "kid": "5jMonJACEPcLfqVaz8jpqBLXHHKYgCE71XYBmFXhjZVX", "iv": "tjGLK6uChZatAyACFzGmFR4V9othKN8S", "tag": "ma9pIjkQuzaqvq_5y5vUlQ", "pk": "eyJpdiI6IldoVGptNi1DX2xiTlQ4Q2RzN2dfNjdMZzZKSEF3NU5BIiwiZXBrIjp7Imt0eSI6Ik9LUCIsImNydiI6IlgyNTUxOSIsIngiOiJnNjRfblJSSFQyYk1JX1hjT1dHRTdJOGdQcU1VWTF4aUNub2J0LVhDUkNZIn0sInR5cCI6Impvc2UiLCJjdHkiOiJqd2sranNvbiIsImFsZyI6IkVDREgtRVMrWEMyMFBLVyIsImVuYyI6IlhDMjBQIn0.4zUt5tOOlcQWskJqxfMi0tNsfUCAzb5_PDfPqQ1h0Vw.xYkeEXV1_cSYFEd6UBMIfl8MWQfHaDex.XSNKTRXye5-iSXQ-aS_vQVZNEgFE6iA9X_KgSRMzihQBMoI1j4WM3o-9dMT9TeSyMvdq3gXt1NpvLdZHpJplahhk3mxMZL-vawm5Prtf.H7a5N-dggwdesjHyJCl06w" } }, { "encrypted_key": "dDHydlp_wlGt_zwR-yUvESx9fXuO-GRJFGtaw2u6CEw", "header": { "kid": "TfVVqzPT1FQHdq1CUDe9XYcg6Wu2QMusWKhGBXEZsosg", "iv": "7SFlGTxQ4Q2l02D9HRNdFeYQnwntyctb", "tag": "9-O6djpNAizix-ZnjAx-Fg", "pk": "eyJpdiI6IkV6UjBFaVRLazJCT19oc05qOVRxeU9PVmVLRFFPYVp1IiwiZXBrIjp7Imt0eSI6Ik9LUCIsImNydiI6IlgyNTUxOSIsIngiOiJoU1g1NGt5ZTdsd0pBdjlMaUplTmh4eFhaV1N0M3hLSDBXUmh6T1NOb1c0In0sInR5cCI6Impvc2UiLCJjdHkiOiJqd2sranNvbiIsImFsZyI6IkVDREgtRVMrWEMyMFBLVyIsImVuYyI6IlhDMjBQIn0.qKmU5xO8Z1ZtRBWEjEMixb5VZG0mrY0LnjUGjLqktwg.EG-VOZSC2vLdoO5l2_A37IYvdXCckLZp.D4kgD6bYL1YfXyApk5ESKE2sc8TUiO-QGBtY-M5hcV_F88JPZdsi53Qofxk02ZxPHJZK-abDy45pIMH6-KUMDfE6WKhW3nPQhydPYutv.0SO4VjM8sDH-wGHcEpinTg" } } ], "aad": "OGY5ZDIxMDE3YTQ4MTc4YWE5MTk0MWQyOGJmYjQ1ZmZmMTYzYTE3ZjUxYjc4YjA3YTlmY2FlMmMwOTFlMjBhZg", "ciphertext": "x1lnQq_pZLgU2ZC4", "tag": "2JgOe9SRjJXddT9TyIjqrg", "iv": "fDGEXswlWXOBx6FxPC_u6qIuhADnOrW1" }I'm curious what other's opinions are on this approach. I personally am not a fan of the bloat the compact JWE adds in order to encrypt the sender's public key. However, I've not found another approach yet that seems satisfactory. If anyone has some suggestions it would be appreciated.
The text was updated successfully, but these errors were encountered: