CXF doesn't do that AFAIK and fully relies on the JVM API, Tomcat has some code ( https://github.com/apache/tomcat/blob/trunk/java/org/apache/tomcat/util/net/openssl/OpenSSLContext.java) but it is not much reusable so having a kind of commons-keys (bouncycastle @asf to not hide it ;)).
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> 2018-05-02 10:28 GMT+02:00 Matthew Broadhead <matthew.broadh...@nbmlaw.co.uk >: > aren't there apache projects already dealing with public key formats? cxf > must have done a lot of work on that? would this just be a wrapper to > existing libs? > > > > On 02/05/18 10:03, Jean-Louis Monteiro wrote: > >> PCS8 "standard" or not is probably the one to no miss >> >> -- >> Jean-Louis Monteiro >> http://twitter.com/jlouismonteiro >> http://www.tomitribe.com >> >> On Wed, May 2, 2018 at 6:27 AM, Rudy De Busscher <rdebussc...@gmail.com> >> wrote: >> >> Primarily what I'd like to do is really nail the public key format >>>> manipulation. I did a huge amount of research in this and would like to >>>> come up with an extremely well tested library that can natively read all >>>> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line >>>> >>> tools >>> >>>> for converting between them. >>>> >>> >>> That would be super awesome. I have been working on the same thing the >>> past >>> month or so. >>> >>> Rudy >>> >>> On 2 May 2018 at 00:13, David Blevins <david.blev...@gmail.com> wrote: >>> >>> Requested a repo we could potentially use for this. >>>> >>>> Primarily what I'd like to do is really nail the public key format >>>> manipulation. I did a huge amount of research in this and would like to >>>> come up with an extremely well tested library that can natively read all >>>> the dominate file formats PKCS 1 & 5 PEM, JWK{S} and has command-line >>>> >>> tools >>> >>>> for converting between them. >>>> >>>> This could be useful to both the TomEE and Geronimo MicroProfile JWT >>>> >>> impls. >>> >>>> >>>> -- >>>> David Blevins >>>> http://twitter.com/dblevins >>>> http://www.tomitribe.com >>>> >>>> On Apr 4, 2018, at 5:32 AM, Jean-Louis Monteiro < >>>>> >>>> jlmonte...@tomitribe.com> wrote: >>>> >>>>> The code still is in a PR (#123) for the moment >>>>> >>>>> I'm in to help. >>>>> Still some small fixes to do and I'd like MP-Config to be used to >>>>> >>>> configure >>>> >>>>> keys, issues, and others. >>>>> >>>>> -- >>>>> Jean-Louis Monteiro >>>>> http://twitter.com/jlouismonteiro >>>>> http://www.tomitribe.com >>>>> >>>>> On Wed, Apr 4, 2018 at 1:06 PM, Mark Struberg >>>>> >>>> <strub...@yahoo.de.invalid >>> >>>> wrote: >>>>> >>>>> As noted elsewhere: the vote question was a mixture of 'what do you >>>>>> think' (consensus -> majority vote) and 'is it ok' (technical -> >>>>>> >>>>> unanimous >>>> >>>>> vote). >>>>>> I'd also be in favour to do the generic parts in Geronimo and only do >>>>>> >>>>> the >>>> >>>>> integration in TomEE. So yes, in a consensus vote I'd also vote -1. If >>>>>> >>>>> this >>>> >>>>> is interpreted as commit vote then I vote -0 >>>>>> The work is the same and as long as it's been done I'm fine either >>>>>> >>>>> ways. >>> >>>> Now that we did all the 3 weeks of rambling and discussions let's >>>>>> >>>>> focus >>> >>>> on >>>> >>>>> the important stuff. >>>>>> Where is the code? Who did already work on it? Or do we again have 30 >>>>>> people discussing but just 2 working? ;) >>>>>> >>>>>> LieGrue,strub >>>>>> On Wednesday, 4 April 2018, 01:14:57 CEST, David Blevins < >>>>>> david.blev...@gmail.com> wrote: >>>>>> >>>>>> On Mar 31, 2018, at 2:16 AM, Romain Manni-Bucau < >>>>>>> >>>>>> rmannibu...@gmail.com >>> >>>> wrote: >>>>>> >>>>>>> It was more as a "if im always the only one seeing tomee differently >>>>>>> >>>>>> i >>> >>>> can >>>>>> >>>>>>> leave to let you space". Not as a threat. >>>>>>> >>>>>> That's a generous sentiment. Either way the best outcome is that you >>>>>> >>>>> stay >>>> >>>>> and we all learn the lesson that disagreeing is ok and healthy. How >>>>>> >>>>> is >>> >>>> the >>>> >>>>> most important part. >>>>>> >>>>>> Disagreement can be an incredibly productive and innovative thing if >>>>>> >>>>> done >>>> >>>>> right. By definition, that means this project is sitting on some >>>>>> incredible innovative potential. >>>>>> >>>>>> A concrete way I think we can measure ourselves is by the number of >>>>>> >>>>> people >>>> >>>>> who feel comfortable voting. I would consider a vote of 20 people >>>>>> >>>>> that >>> >>>> included 3 -1 votes to be significantly more healthy than a vote of 3 >>>>>> people and all +1s. >>>>>> >>>>>> [...] >>>>>>> There is no veto at apache if you check rules closely. All is more >>>>>>> >>>>>> about >>>> >>>>> respect and overall consensus IIRC. >>>>>>> >>>>>> I want to be careful that we don't learn a false lesson as Apache does >>>>>> have technical vetos. These are more meant for line-of-code level >>>>>> >>>>> input vs >>>> >>>>> community direction. >>>>>> >>>>>> The intention of the two votes was to make the line a little more >>>>>> >>>>> clear. >>> >>>> - The first vote "Merge Pull Request 123 - MicroProfile JWT support" >>>>>> >>>>> was >>> >>>> intended to flush out line-of-code level technical issues with the PR: >>>>>> breaks the build; doesn't follow code style; introduces security >>>>>> >>>>> issues. >>> >>>> It's ultimately a Review-than-Commit vote and a -1 should be viewed >>>>>> >>>>> as a >>> >>>> technical veto. >>>>>> >>>>>> - The second vote "Explore creating a reusable JWT Library" was >>>>>> >>>>> intended >>> >>>> to determine overall desire on what the next step should be. No >>>>>> >>>>> commit >>> >>>> being reviewed, more of a community level discussion. A -1 should not >>>>>> >>>>> be >>>> >>>>> viewed as a veto. >>>>>> >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> >>>> >
