Key parsing in MP JWT code (Re: TomEE MicroProfile and Jakarta)

[David Blevins <da...@gmail.com>]

> On Apr 15, 2022, at 1:10 PM, Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
> 
> David, yes I figured you'd want to work on JWT. I looked and it seems our
> setup needs some love. Some additional tests with EC based algorithms and a
> couple of other endpoints need to be updated.

On the note of EC keys, I wonder what people think about potentially using this key parsing library I wrote:

 - https://github.com/tomitribe/churchkey

It does parse EC keys in several different formats, supports 100+ curves and has 1450 unit tests.  If you have a public or private key in a handful of PEM formats, OpenSSH format, SSH2 format, JWT format or plain binary DIR format it will parse the key.

The very significant con is that it would be the first time we adding a library from that org to our server.  It's something I've deliberately avoided.  I've always preferred to keep lines clean.  I'm not sure how I feel about adding such a dependency and potentially opening a can of worms.

I'd like to hear some thoughts from others.  Perhaps I'm being overly cautious.


-David

Re: Key parsing in MP JWT code (Re: TomEE MicroProfile and Jakarta)

[David Blevins <da...@gmail.com>]

> On Apr 15, 2022, at 2:25 PM, David Blevins <da...@gmail.com> wrote:
> 
>> On Apr 15, 2022, at 1:10 PM, Jean-Louis Monteiro <jl...@tomitribe.com> wrote:
>> 
>> David, yes I figured you'd want to work on JWT. I looked and it seems our
>> setup needs some love. Some additional tests with EC based algorithms and a
>> couple of other endpoints need to be updated.
> 
> On the note of EC keys, I wonder what people think about potentially using this key parsing library I wrote:
> 
> - https://github.com/tomitribe/churchkey
> 
> It does parse EC keys in several different formats, supports 100+ curves and has 1450 unit tests.  If you have a public or private key in a handful of PEM formats, OpenSSH format, SSH2 format, JWT format or plain binary DIR format it will parse the key.
> 
> The very significant con is that it would be the first time we adding a library from that org to our server.  It's something I've deliberately avoided.  I've always preferred to keep lines clean.  I'm not sure how I feel about adding such a dependency and potentially opening a can of worms.
> 
> I'd like to hear some thoughts from others.  Perhaps I'm being overly cautious.

I thought about this for a few weeks and came to the conclusion I'm not being overly cautious.  I don't think we want corporate names of any kind being imported in our source or visible in our Maven dependencies of the server itself.  Tools are ok, but the actual thing people are downloading and putting in production.

My first thought was to fork it all over, but that would create a maintenance headache.  I checked and there was a good domain name available so I repackaged all the code and maven groupId to the following completely neutral names:

 package: io.churchkey
 groupId: io.churchkey

It's already been released and is in Maven Central.  Our key parsing will get a serious upgrade shortly.


-David