You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Ella Chen <El...@sportsbet.com.au> on 2016/07/19 01:27:40 UTC
Multiple Recipient for JAX-RS JOSE
Hi All,
When I tried to setup a POC for multiple recipients for JWE by following the example under section "JWE JSON", I went quite a journey and could not make it working.
The first thing that I found was that the example itself never works for the second recipient for below reasons:
· it generates different unencrypted CEK for each recipient. However, i think the CEK should be shared across different recipients.
· it didn't have per-recipient headers that allows decryption side to locate to the right "encrypted_key". (https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40#appendix-A.4.7)
After realize that, I created a shared unencrypted CEK to both recipients with method:
JweUtils.getContentEncryptionProvider(CONTENT_KEY, ContentAlgorithm.A128GCM);
, and try to set per-recipient headers to identify the recipients (like using "kid") with method:
p.encryptWith(jweList, jweheadersList); //jweheadersList contains per-recipient headers.
However, it didn’t allow me to do so. The code that I found prevent me from doing so is in class: JweJsonProducer, line 116-117:
jsonHeaders = new JweHeaders(unionHeaders.asMap());
jsonHeaders.asMap().putAll(perRecipientUnprotected.asMap());
These lines obtain a reference to the map of unionHeaders, and when add the current recipient's headers to jsonHeaders, as a side effect, unionHeaders is changed as well. And when it try to check the uniqueness of headers for the second recipient, it failed.
Could anybody please advise whether it is the expected behavior? If it is, what is the correct way to make multiple recipients working? If it is not, when can we expect multiple recipients works?
Cheers,
Ella
Re: Multiple Recipient for JAX-RS JOSE
Posted by Sergey Beryozkin <sb...@gmail.com>.
Sorry
meant JWE JSON JAX-RS filters, though JWS JSON JAX-RS filters can be
tried too
Sergey
On 21/07/16 17:52, Sergey Beryozkin wrote:
> By the way, can you check JWS JSON JAX-RS filters if you get a chance.
> I added them last and the out filters are not streaming yet, but they
> should be quite useful.
> On the out side multiple recipients are supported, ob the in side the
> immediate recipient is directly supported and the data for the extra
> ones are saved in the context properties, for example, the server can
> use them to build a new JWS JSON request and propagate the remaining
> entries further...
>
> Sergey
> On 21/07/16 17:43, Sergey Beryozkin wrote:
>> Hi Ella
>> On 21/07/16 02:26, ellachen wrote:
>>> Hi Sergey,
>>>
>>> We are very looking forward to getting the release. Currently, there
>>> isn't
>>> any other decent implementation for multiple recipient yet.
>>>
>> It just a matter of time before more than one implementation appears :-)
>>
>> FYI, I've created
>> https://issues.apache.org/jira/browse/CXF-6974
>>
>> You might want to experiments with those tests too, such as this one:
>>
>> https://tools.ietf.org/html/rfc7520#section-5.13
>>
>> We'll start adding these tests to the source code later on (def later on
>> this time :-))
>>
>> Cheers, Sergey
>>> Cheers,
>>> Ella
>>>
>>>
>>>
>>> Sergey Beryozkin wrote
>>>> Hi Ella
>>>> On 20/07/16 06:32, ellachen wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Thanks for the quick response and fix the problem in such a short
>>>>> time.
>>>> Np, some work still needs to be done to make it a bit simpler.
>>>>
>>>> Specifically, extending JweJsonProducer to get CEK & IV shared is all
>>>> right but ideally one would just reuse the same instance of
>>>> ContentEncryptionProvider initialized with CEK & IV - but currently
>>>> ContentEncryptionProvider implementations (AES GCM, etc which can
>>>> accept
>>>> CEK and IV in constructors) would fail if they are asked to return IV
>>>> for more than once - this is correct but in this case it is safe as the
>>>> cipher text is created only once, it is only CEK which is encrypted
>>>> more
>>>> than once.
>>>>
>>>> There's also some sub-optimal code there that results in a redundant (
>>>> but harmless) Cipher creation for the 2nd/etc recipient
>>>>
>>>>> Could you please let us know when are we going to have version 3.1.7?
>>>> We are working toward the release, I honestly hope it will be out by
>>>> the
>>>> end of the month
>>>>
>>>> Cheers, Sergey
>>>>>
>>>>> Cheers,
>>>>> Ella
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
>>>>>
>>>>>
>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770547.html
>>>
>>>
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Multiple Recipient for JAX-RS JOSE
Posted by Sergey Beryozkin <sb...@gmail.com>.
FYI,
https://issues.apache.org/jira/browse/CXF-6993
so that CEK does not have to be manually created in case of >1 recipients
Sergey
On 26/07/16 08:24, Sergey Beryozkin wrote:
> Hi Ella
> No problems, whenever you get a chance
> Cheers, Sergey
> On 26/07/16 04:56, ellachen wrote:
>> Hi Sergey,
>>
>> Sorry that I didn't get this reply earlier. I will give it a try and
>> let you
>> know.
>>
>> Cheers,
>> Ella
>>
>> Sergey Beryozkin wrote
>>> By the way, can you check JWS JSON JAX-RS filters if you get a chance.
>>> I added them last and the out filters are not streaming yet, but they
>>> should be quite useful.
>>> On the out side multiple recipients are supported, ob the in side the
>>> immediate recipient is directly supported and the data for the extra
>>> ones are saved in the context properties, for example, the server can
>>> use them to build a new JWS JSON request and propagate the remaining
>>> entries further...
>>>
>>> Sergey
>>> On 21/07/16 17:43, Sergey Beryozkin wrote:
>>>> Hi Ella
>>>> On 21/07/16 02:26, ellachen wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> We are very looking forward to getting the release. Currently, there
>>>>> isn't
>>>>> any other decent implementation for multiple recipient yet.
>>>>>
>>>> It just a matter of time before more than one implementation appears
>>>> :-)
>>>>
>>>> FYI, I've created
>>>> https://issues.apache.org/jira/browse/CXF-6974
>>>>
>>>> You might want to experiments with those tests too, such as this one:
>>>>
>>>> https://tools.ietf.org/html/rfc7520#section-5.13
>>>>
>>>> We'll start adding these tests to the source code later on (def
>>>> later on
>>>> this time :-))
>>>>
>>>> Cheers, Sergey
>>>>> Cheers,
>>>>> Ella
>>>>>
>>>>>
>>>>>
>>>>> Sergey Beryozkin wrote
>>>>>> Hi Ella
>>>>>> On 20/07/16 06:32, ellachen wrote:
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> Thanks for the quick response and fix the problem in such a short
>>>>>>> time.
>>>>>> Np, some work still needs to be done to make it a bit simpler.
>>>>>>
>>>>>> Specifically, extending JweJsonProducer to get CEK & IV shared is all
>>>>>> right but ideally one would just reuse the same instance of
>>>>>> ContentEncryptionProvider initialized with CEK & IV - but currently
>>>>>> ContentEncryptionProvider implementations (AES GCM, etc which can
>>>>>> accept
>>>>>> CEK and IV in constructors) would fail if they are asked to return IV
>>>>>> for more than once - this is correct but in this case it is safe
>>>>>> as the
>>>>>> cipher text is created only once, it is only CEK which is encrypted
>>>>>> more
>>>>>> than once.
>>>>>>
>>>>>> There's also some sub-optimal code there that results in a
>>>>>> redundant (
>>>>>> but harmless) Cipher creation for the 2nd/etc recipient
>>>>>>
>>>>>>> Could you please let us know when are we going to have version
>>>>>>> 3.1.7?
>>>>>> We are working toward the release, I honestly hope it will be out by
>>>>>> the
>>>>>> end of the month
>>>>>>
>>>>>> Cheers, Sergey
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ella
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
>>>>>>>
>>>>>>>
>>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sergey Beryozkin
>>>>>>
>>>>>> Talend Community Coders
>>>>>> http://coders.talend.com/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770547.html
>>>>>
>>>>>
>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>
>>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770772.html
>>
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Multiple Recipient for JAX-RS JOSE
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ella
No problems, whenever you get a chance
Cheers, Sergey
On 26/07/16 04:56, ellachen wrote:
> Hi Sergey,
>
> Sorry that I didn't get this reply earlier. I will give it a try and let you
> know.
>
> Cheers,
> Ella
>
> Sergey Beryozkin wrote
>> By the way, can you check JWS JSON JAX-RS filters if you get a chance.
>> I added them last and the out filters are not streaming yet, but they
>> should be quite useful.
>> On the out side multiple recipients are supported, ob the in side the
>> immediate recipient is directly supported and the data for the extra
>> ones are saved in the context properties, for example, the server can
>> use them to build a new JWS JSON request and propagate the remaining
>> entries further...
>>
>> Sergey
>> On 21/07/16 17:43, Sergey Beryozkin wrote:
>>> Hi Ella
>>> On 21/07/16 02:26, ellachen wrote:
>>>> Hi Sergey,
>>>>
>>>> We are very looking forward to getting the release. Currently, there
>>>> isn't
>>>> any other decent implementation for multiple recipient yet.
>>>>
>>> It just a matter of time before more than one implementation appears :-)
>>>
>>> FYI, I've created
>>> https://issues.apache.org/jira/browse/CXF-6974
>>>
>>> You might want to experiments with those tests too, such as this one:
>>>
>>> https://tools.ietf.org/html/rfc7520#section-5.13
>>>
>>> We'll start adding these tests to the source code later on (def later on
>>> this time :-))
>>>
>>> Cheers, Sergey
>>>> Cheers,
>>>> Ella
>>>>
>>>>
>>>>
>>>> Sergey Beryozkin wrote
>>>>> Hi Ella
>>>>> On 20/07/16 06:32, ellachen wrote:
>>>>>> Hi Sergey,
>>>>>>
>>>>>> Thanks for the quick response and fix the problem in such a short
>>>>>> time.
>>>>> Np, some work still needs to be done to make it a bit simpler.
>>>>>
>>>>> Specifically, extending JweJsonProducer to get CEK & IV shared is all
>>>>> right but ideally one would just reuse the same instance of
>>>>> ContentEncryptionProvider initialized with CEK & IV - but currently
>>>>> ContentEncryptionProvider implementations (AES GCM, etc which can
>>>>> accept
>>>>> CEK and IV in constructors) would fail if they are asked to return IV
>>>>> for more than once - this is correct but in this case it is safe as the
>>>>> cipher text is created only once, it is only CEK which is encrypted
>>>>> more
>>>>> than once.
>>>>>
>>>>> There's also some sub-optimal code there that results in a redundant (
>>>>> but harmless) Cipher creation for the 2nd/etc recipient
>>>>>
>>>>>> Could you please let us know when are we going to have version 3.1.7?
>>>>> We are working toward the release, I honestly hope it will be out by
>>>>> the
>>>>> end of the month
>>>>>
>>>>> Cheers, Sergey
>>>>>>
>>>>>> Cheers,
>>>>>> Ella
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
>>>>>>
>>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sergey Beryozkin
>>>>>
>>>>> Talend Community Coders
>>>>> http://coders.talend.com/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770547.html
>>>>
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770772.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Multiple Recipient for JAX-RS JOSE
Posted by ellachen <El...@sportsbet.com.au>.
Hi Sergey,
Sorry that I didn't get this reply earlier. I will give it a try and let you
know.
Cheers,
Ella
Sergey Beryozkin wrote
> By the way, can you check JWS JSON JAX-RS filters if you get a chance.
> I added them last and the out filters are not streaming yet, but they
> should be quite useful.
> On the out side multiple recipients are supported, ob the in side the
> immediate recipient is directly supported and the data for the extra
> ones are saved in the context properties, for example, the server can
> use them to build a new JWS JSON request and propagate the remaining
> entries further...
>
> Sergey
> On 21/07/16 17:43, Sergey Beryozkin wrote:
>> Hi Ella
>> On 21/07/16 02:26, ellachen wrote:
>>> Hi Sergey,
>>>
>>> We are very looking forward to getting the release. Currently, there
>>> isn't
>>> any other decent implementation for multiple recipient yet.
>>>
>> It just a matter of time before more than one implementation appears :-)
>>
>> FYI, I've created
>> https://issues.apache.org/jira/browse/CXF-6974
>>
>> You might want to experiments with those tests too, such as this one:
>>
>> https://tools.ietf.org/html/rfc7520#section-5.13
>>
>> We'll start adding these tests to the source code later on (def later on
>> this time :-))
>>
>> Cheers, Sergey
>>> Cheers,
>>> Ella
>>>
>>>
>>>
>>> Sergey Beryozkin wrote
>>>> Hi Ella
>>>> On 20/07/16 06:32, ellachen wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Thanks for the quick response and fix the problem in such a short
>>>>> time.
>>>> Np, some work still needs to be done to make it a bit simpler.
>>>>
>>>> Specifically, extending JweJsonProducer to get CEK & IV shared is all
>>>> right but ideally one would just reuse the same instance of
>>>> ContentEncryptionProvider initialized with CEK & IV - but currently
>>>> ContentEncryptionProvider implementations (AES GCM, etc which can
>>>> accept
>>>> CEK and IV in constructors) would fail if they are asked to return IV
>>>> for more than once - this is correct but in this case it is safe as the
>>>> cipher text is created only once, it is only CEK which is encrypted
>>>> more
>>>> than once.
>>>>
>>>> There's also some sub-optimal code there that results in a redundant (
>>>> but harmless) Cipher creation for the 2nd/etc recipient
>>>>
>>>>> Could you please let us know when are we going to have version 3.1.7?
>>>> We are working toward the release, I honestly hope it will be out by
>>>> the
>>>> end of the month
>>>>
>>>> Cheers, Sergey
>>>>>
>>>>> Cheers,
>>>>> Ella
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
>>>>>
>>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770547.html
>>>
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
--
View this message in context: http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770772.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Multiple Recipient for JAX-RS JOSE
Posted by Sergey Beryozkin <sb...@gmail.com>.
By the way, can you check JWS JSON JAX-RS filters if you get a chance.
I added them last and the out filters are not streaming yet, but they
should be quite useful.
On the out side multiple recipients are supported, ob the in side the
immediate recipient is directly supported and the data for the extra
ones are saved in the context properties, for example, the server can
use them to build a new JWS JSON request and propagate the remaining
entries further...
Sergey
On 21/07/16 17:43, Sergey Beryozkin wrote:
> Hi Ella
> On 21/07/16 02:26, ellachen wrote:
>> Hi Sergey,
>>
>> We are very looking forward to getting the release. Currently, there
>> isn't
>> any other decent implementation for multiple recipient yet.
>>
> It just a matter of time before more than one implementation appears :-)
>
> FYI, I've created
> https://issues.apache.org/jira/browse/CXF-6974
>
> You might want to experiments with those tests too, such as this one:
>
> https://tools.ietf.org/html/rfc7520#section-5.13
>
> We'll start adding these tests to the source code later on (def later on
> this time :-))
>
> Cheers, Sergey
>> Cheers,
>> Ella
>>
>>
>>
>> Sergey Beryozkin wrote
>>> Hi Ella
>>> On 20/07/16 06:32, ellachen wrote:
>>>> Hi Sergey,
>>>>
>>>> Thanks for the quick response and fix the problem in such a short time.
>>> Np, some work still needs to be done to make it a bit simpler.
>>>
>>> Specifically, extending JweJsonProducer to get CEK & IV shared is all
>>> right but ideally one would just reuse the same instance of
>>> ContentEncryptionProvider initialized with CEK & IV - but currently
>>> ContentEncryptionProvider implementations (AES GCM, etc which can accept
>>> CEK and IV in constructors) would fail if they are asked to return IV
>>> for more than once - this is correct but in this case it is safe as the
>>> cipher text is created only once, it is only CEK which is encrypted more
>>> than once.
>>>
>>> There's also some sub-optimal code there that results in a redundant (
>>> but harmless) Cipher creation for the 2nd/etc recipient
>>>
>>>> Could you please let us know when are we going to have version 3.1.7?
>>> We are working toward the release, I honestly hope it will be out by the
>>> end of the month
>>>
>>> Cheers, Sergey
>>>>
>>>> Cheers,
>>>> Ella
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
>>>>
>>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770547.html
>>
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Multiple Recipient for JAX-RS JOSE
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ella
On 21/07/16 02:26, ellachen wrote:
> Hi Sergey,
>
> We are very looking forward to getting the release. Currently, there isn't
> any other decent implementation for multiple recipient yet.
>
It just a matter of time before more than one implementation appears :-)
FYI, I've created
https://issues.apache.org/jira/browse/CXF-6974
You might want to experiments with those tests too, such as this one:
https://tools.ietf.org/html/rfc7520#section-5.13
We'll start adding these tests to the source code later on (def later on
this time :-))
Cheers, Sergey
> Cheers,
> Ella
>
>
>
> Sergey Beryozkin wrote
>> Hi Ella
>> On 20/07/16 06:32, ellachen wrote:
>>> Hi Sergey,
>>>
>>> Thanks for the quick response and fix the problem in such a short time.
>> Np, some work still needs to be done to make it a bit simpler.
>>
>> Specifically, extending JweJsonProducer to get CEK & IV shared is all
>> right but ideally one would just reuse the same instance of
>> ContentEncryptionProvider initialized with CEK & IV - but currently
>> ContentEncryptionProvider implementations (AES GCM, etc which can accept
>> CEK and IV in constructors) would fail if they are asked to return IV
>> for more than once - this is correct but in this case it is safe as the
>> cipher text is created only once, it is only CEK which is encrypted more
>> than once.
>>
>> There's also some sub-optimal code there that results in a redundant (
>> but harmless) Cipher creation for the 2nd/etc recipient
>>
>>> Could you please let us know when are we going to have version 3.1.7?
>> We are working toward the release, I honestly hope it will be out by the
>> end of the month
>>
>> Cheers, Sergey
>>>
>>> Cheers,
>>> Ella
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770547.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Re: Multiple Recipient for JAX-RS JOSE
Posted by ellachen <El...@sportsbet.com.au>.
Hi Sergey,
We are very looking forward to getting the release. Currently, there isn't
any other decent implementation for multiple recipient yet.
Cheers,
Ella
Sergey Beryozkin wrote
> Hi Ella
> On 20/07/16 06:32, ellachen wrote:
>> Hi Sergey,
>>
>> Thanks for the quick response and fix the problem in such a short time.
> Np, some work still needs to be done to make it a bit simpler.
>
> Specifically, extending JweJsonProducer to get CEK & IV shared is all
> right but ideally one would just reuse the same instance of
> ContentEncryptionProvider initialized with CEK & IV - but currently
> ContentEncryptionProvider implementations (AES GCM, etc which can accept
> CEK and IV in constructors) would fail if they are asked to return IV
> for more than once - this is correct but in this case it is safe as the
> cipher text is created only once, it is only CEK which is encrypted more
> than once.
>
> There's also some sub-optimal code there that results in a redundant (
> but harmless) Cipher creation for the 2nd/etc recipient
>
>> Could you please let us know when are we going to have version 3.1.7?
> We are working toward the release, I honestly hope it will be out by the
> end of the month
>
> Cheers, Sergey
>>
>> Cheers,
>> Ella
>>
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
--
View this message in context: http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770547.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Multiple Recipient for JAX-RS JOSE
Posted by ellachen <El...@sportsbet.com.au>.
Hi Sergey,
This example exactly meet our expectation. With
AesGcmContentEncryptionAlgorithm, we have the right control over the live
cycle of the CEK. Thanks for updating it in such a quick manner.
Cheer,
Ella
--
View this message in context: http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770546.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Multiple Recipient for JAX-RS JOSE
Posted by Sergey Beryozkin <sb...@gmail.com>.
This is all sorted now
https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+JOSE#JAX-RSJOSE-JWEJSON
This shows an updated producer code - the old way of using the utility
to create a content algo provider with an algorithm property only is
still OK if it is a single recipient - but indeed to avoid the CEK
auto-generation one needs to prepare a byte[] or SecretKey and pass it
to AES GCM provider.
In the test in the source IV is also passed - only to match the expected
output, not required otherwise
Sergey
On 20/07/16 11:36, Sergey Beryozkin wrote:
> Hi Ella
> On 20/07/16 06:32, ellachen wrote:
>> Hi Sergey,
>>
>> Thanks for the quick response and fix the problem in such a short time.
> Np, some work still needs to be done to make it a bit simpler.
>
> Specifically, extending JweJsonProducer to get CEK & IV shared is all
> right but ideally one would just reuse the same instance of
> ContentEncryptionProvider initialized with CEK & IV - but currently
> ContentEncryptionProvider implementations (AES GCM, etc which can accept
> CEK and IV in constructors) would fail if they are asked to return IV
> for more than once - this is correct but in this case it is safe as the
> cipher text is created only once, it is only CEK which is encrypted more
> than once.
>
> There's also some sub-optimal code there that results in a redundant (
> but harmless) Cipher creation for the 2nd/etc recipient
>
>> Could you please let us know when are we going to have version 3.1.7?
> We are working toward the release, I honestly hope it will be out by the
> end of the month
>
> Cheers, Sergey
>>
>> Cheers,
>> Ella
>>
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
>>
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Multiple Recipient for JAX-RS JOSE
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ella
On 20/07/16 06:32, ellachen wrote:
> Hi Sergey,
>
> Thanks for the quick response and fix the problem in such a short time.
Np, some work still needs to be done to make it a bit simpler.
Specifically, extending JweJsonProducer to get CEK & IV shared is all
right but ideally one would just reuse the same instance of
ContentEncryptionProvider initialized with CEK & IV - but currently
ContentEncryptionProvider implementations (AES GCM, etc which can accept
CEK and IV in constructors) would fail if they are asked to return IV
for more than once - this is correct but in this case it is safe as the
cipher text is created only once, it is only CEK which is encrypted more
than once.
There's also some sub-optimal code there that results in a redundant (
but harmless) Cipher creation for the 2nd/etc recipient
> Could you please let us know when are we going to have version 3.1.7?
We are working toward the release, I honestly hope it will be out by the
end of the month
Cheers, Sergey
>
> Cheers,
> Ella
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Multiple Recipient for JAX-RS JOSE
Posted by ellachen <El...@sportsbet.com.au>.
Hi Sergey,
Thanks for the quick response and fix the problem in such a short time.
Could you please let us know when are we going to have version 3.1.7?
Cheers,
Ella
--
View this message in context: http://cxf.547215.n5.nabble.com/Multiple-Recipient-for-JAX-RS-JOSE-tp5770495p5770521.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Multiple Recipient for JAX-RS JOSE
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
I've fixed the per-recipient headers issue (for the incoming CXF 3.1.7),
updated the producer and added a missing consumer test for multiple
recipients, see
https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/test/java/org/apache/cxf/rs/security/jose/jwe/JweJsonProducerTest.java#L272,
the output is here:
https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/test/java/org/apache/cxf/rs/security/jose/jwe/JweJsonProducerTest.java#L98
and the consumer test is here:
https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/test/java/org/apache/cxf/rs/security/jose/jwe/JweJsonConsumerTest.java#L133
Note the reason this test works is here:
https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/test/java/org/apache/cxf/rs/security/jose/jwe/JweJsonProducerTest.java#L229
The CEK and IV is indeed shared, I forgot, when documenting to point it
out. I'm going to update the docs, but will also look later on how to
avoid having to specify CEK manually
Thanks, Sergey
On 19/07/16 11:49, Sergey Beryozkin wrote:
> Hi Ella
>
> Many thanks for starting experimenting with the JOSE code and JWE JSON
> in particular which I'd say is the probably the most complex one when we
> talk about multiple recipients.
>
> Please see comments inline
>
>
> On 19/07/16 04:27, Ella Chen wrote:
>> Hi All,
>>
>> When I tried to setup a POC for multiple recipients for JWE by
>> following the example under section "JWE JSON", I went quite a journey
>> and could not make it working.
>>
>> The first thing that I found was that the example itself never works
>> for the second recipient for below reasons:
>>
>> � it generates different unencrypted CEK for each recipient.
>> However, i think the CEK should be shared across different recipients.
>>
>
> I think you have identified a design flaw when it comes to supporting
> multiple recipients.
> You are right CEK should be shared, ContentEncryptionProvider can be
> initialized with pre-generated CEK, but I'll need to look at making sure
> it is enforced.
>
> I have a producer test:
>
> https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/test/java/org/apache/cxf/rs/security/jose/jwe/JweJsonProducerTest.java#L270
>
>
> This sort of works only because JweJsonProducer assumes the CEK is
> shared when producing the final JWE JSON output sequence and
> unfortunately JweJsonConsumer test for multiple recipients is missing.
>
>
>> � it didn't have per-recipient headers that allows decryption
>> side to locate to the right "encrypted_key".
>> (https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40#appendix-A.4.7)
>>
>>
>> After realize that, I created a shared unencrypted CEK to both
>> recipients with method:
>>
>> JweUtils.getContentEncryptionProvider(CONTENT_KEY,
>> ContentAlgorithm.A128GCM);
>
> Right, I'll need to see if I can enforce it at JweJsonProducer
>
>>
>> , and try to set per-recipient headers to identify the recipients
>> (like using "kid") with method:
>> p.encryptWith(jweList, jweheadersList);
>> //jweheadersList contains per-recipient headers.
>>
>> However, it didn\u2019t allow me to do so. The code that I found prevent me
>> from doing so is in class: JweJsonProducer, line 116-117:
>> jsonHeaders = new JweHeaders(unionHeaders.asMap());
>> jsonHeaders.asMap().putAll(perRecipientUnprotected.asMap());
> I see
>>
>> These lines obtain a reference to the map of unionHeaders, and when
>> add the current recipient's headers to jsonHeaders, as a side effect,
>> unionHeaders is changed as well. And when it try to check the
>> uniqueness of headers for the second recipient, it failed.
>> Could anybody please advise whether it is the expected behavior? If it
>> is, what is the correct way to make multiple recipients working? If it
>> is not, when can we expect multiple recipients works?
>>
> Let me address the above issues. I can not guarantee it will make it
> into CXF 3.1.7 which is coming soon, but I'll work on it and let you
> know once it is fixed
>
> Thanks again, more feedback is welcome
>
> Sergey
>>
>> Cheers,
>> Ella
>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: Multiple Recipient for JAX-RS JOSE
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Ella
Many thanks for starting experimenting with the JOSE code and JWE JSON
in particular which I'd say is the probably the most complex one when we
talk about multiple recipients.
Please see comments inline
On 19/07/16 04:27, Ella Chen wrote:
> Hi All,
>
> When I tried to setup a POC for multiple recipients for JWE by following the example under section "JWE JSON", I went quite a journey and could not make it working.
>
> The first thing that I found was that the example itself never works for the second recipient for below reasons:
>
> � it generates different unencrypted CEK for each recipient. However, i think the CEK should be shared across different recipients.
>
I think you have identified a design flaw when it comes to supporting
multiple recipients.
You are right CEK should be shared, ContentEncryptionProvider can be
initialized with pre-generated CEK, but I'll need to look at making sure
it is enforced.
I have a producer test:
https://github.com/apache/cxf/blob/master/rt/rs/security/jose-parent/jose/src/test/java/org/apache/cxf/rs/security/jose/jwe/JweJsonProducerTest.java#L270
This sort of works only because JweJsonProducer assumes the CEK is
shared when producing the final JWE JSON output sequence and
unfortunately JweJsonConsumer test for multiple recipients is missing.
> � it didn't have per-recipient headers that allows decryption side to locate to the right "encrypted_key". (https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40#appendix-A.4.7)
>
> After realize that, I created a shared unencrypted CEK to both recipients with method:
>
> JweUtils.getContentEncryptionProvider(CONTENT_KEY, ContentAlgorithm.A128GCM);
Right, I'll need to see if I can enforce it at JweJsonProducer
>
> , and try to set per-recipient headers to identify the recipients (like using "kid") with method:
> p.encryptWith(jweList, jweheadersList); //jweheadersList contains per-recipient headers.
>
> However, it didn\u2019t allow me to do so. The code that I found prevent me from doing so is in class: JweJsonProducer, line 116-117:
> jsonHeaders = new JweHeaders(unionHeaders.asMap());
> jsonHeaders.asMap().putAll(perRecipientUnprotected.asMap());
I see
>
> These lines obtain a reference to the map of unionHeaders, and when add the current recipient's headers to jsonHeaders, as a side effect, unionHeaders is changed as well. And when it try to check the uniqueness of headers for the second recipient, it failed.
> Could anybody please advise whether it is the expected behavior? If it is, what is the correct way to make multiple recipients working? If it is not, when can we expect multiple recipients works?
>
Let me address the above issues. I can not guarantee it will make it
into CXF 3.1.7 which is coming soon, but I'll work on it and let you
know once it is fixed
Thanks again, more feedback is welcome
Sergey
>
> Cheers,
> Ella
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/