You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oltu.apache.org by Simone Tripodi <si...@apache.org> on 2014/06/26 11:01:46 UTC

Refactoring the Hmac and Rsa signature methods APIs in JWS

Hi Antonio, All,

following up the old discussion, I found some spare time to make a
proposal and pasted in on Gist[1], if it looks fine for you I'd be
happy to track it on JIRA and continue the discussion/development
there.

Main concerns I was focused on while making the proposal:

 * simplify the RSA/HMAC usage for users not familiar with
java.security APIs, introducing KeyFactory;

 * reduce drastically the magic role of Strings in the RSA algorithms,
I would avoid end users have to manipulate strings in order to obtain
different RSA algorithms, but IMHO it has to be clear which algorithm
they are going to use by simply instantiating classes;

 * have classes well organised, collected in different packages
depending by the signature method.

Any feedback would be much more than appreciated, many thanks in advance!
-Simo

[1] https://gist.github.com/simonetripodi/740ec4a8c1fdf06d5f3f

http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi


On Fri, Apr 11, 2014 at 1:51 PM, Simone Tripodi
<si...@apache.org> wrote:
> Hi Tonino,
>
> just few considerations:
>
>> +public class JwsConstants {
>> +
>> +    public static final String RS256 = "RS256";
>> +
>> +    public static final String RS384 = "RS384";
>> +
>> +    public static final String RS512 = "RS512";
>> +}
>
> I'd reduce this class constructor as 'private'
>
>>
>> Added: oltu/trunk/jose/jws/src/main/java/org/apache/oltu/jose/jws/signature/impl/PrivateKey.java
>
> I wouldn't add that classes to a generic 'impl' package, they refer to
> specific 'java.security' implementation, so I would suggest to:
>
>  * having them implemented in a separated module/bundle
>
>  * package name be renamed
>
> WDYT?
> Best,
> -Simo

Re: Refactoring the Hmac and Rsa signature methods APIs in JWS

Posted by Antonio Sanso <as...@adobe.com>.
thanks a lot for your effort Simone.

I might need a little more time to dig it deeper though in order to better review.

As a side note it would be also nice if we will replace the crypto done there with jose4j… [0]

WDYT?

regards

antonio

[0] https://bitbucket.org/b_c/jose4j/wiki/Home
On Jun 26, 2014, at 11:01 AM, Simone Tripodi <si...@apache.org> wrote:

> Hi Antonio, All,
> 
> following up the old discussion, I found some spare time to make a
> proposal and pasted in on Gist[1], if it looks fine for you I'd be
> happy to track it on JIRA and continue the discussion/development
> there.
> 
> Main concerns I was focused on while making the proposal:
> 
> * simplify the RSA/HMAC usage for users not familiar with
> java.security APIs, introducing KeyFactory;
> 
> * reduce drastically the magic role of Strings in the RSA algorithms,
> I would avoid end users have to manipulate strings in order to obtain
> different RSA algorithms, but IMHO it has to be clear which algorithm
> they are going to use by simply instantiating classes;
> 
> * have classes well organised, collected in different packages
> depending by the signature method.
> 
> Any feedback would be much more than appreciated, many thanks in advance!
> -Simo
> 
> [1] https://gist.github.com/simonetripodi/740ec4a8c1fdf06d5f3f
> 
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
> 
> 
> On Fri, Apr 11, 2014 at 1:51 PM, Simone Tripodi
> <si...@apache.org> wrote:
>> Hi Tonino,
>> 
>> just few considerations:
>> 
>>> +public class JwsConstants {
>>> +
>>> +    public static final String RS256 = "RS256";
>>> +
>>> +    public static final String RS384 = "RS384";
>>> +
>>> +    public static final String RS512 = "RS512";
>>> +}
>> 
>> I'd reduce this class constructor as 'private'
>> 
>>> 
>>> Added: oltu/trunk/jose/jws/src/main/java/org/apache/oltu/jose/jws/signature/impl/PrivateKey.java
>> 
>> I wouldn't add that classes to a generic 'impl' package, they refer to
>> specific 'java.security' implementation, so I would suggest to:
>> 
>> * having them implemented in a separated module/bundle
>> 
>> * package name be renamed
>> 
>> WDYT?
>> Best,
>> -Simo