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/
