On 09/07/2010 10:44, Simone Tripodi wrote:
> sure! with just a very simple key proto we should be able to fill the
> lack caused by generics. for RSA, as already know, things are a little
> more complicated, where SigningKey and VerifyingKey implementations
> are totally different.
> just thinking about how to reuse the same key for new custom
> algorithms implementations.
>
> public final class BasicKey implements SigningKey, VerifyingKey {What I'm getting at is this: String methodName = extractFrom(request); SignatureMethod method = registry.get(methodName); // create keys method.verify(etc, etc) It's very difficult to do the above when you don't know the key types, if SignatureMethod is parameterized. SignatureMethod<K,V> method = registry.get(methodName); // how to select/create the key K? I'm trying to work on the discovery of SignatureMethods and some mechanism for selecting them. The current design only works if I write code which differentiates between each type, which negates the point of using generics. p > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Jul 9, 2010 at 11:21 AM, Pid <[email protected]> wrote: >> On 09/07/2010 10:18, Simone Tripodi wrote: >>> Hi Pid, >>> thanks for understanding, in a while I'll be able to show you the >>> alternative we're looking for to sign/verify signatures simply with >>> String, I hope you'll enjoy the solution :P >> >> I'd prefer to have a discussion about it, even if it's a short one, >> before code is committed, if possible. >> >> >> p >> >> >>> On Fri, Jul 9, 2010 at 11:08 AM, Pid <[email protected]> wrote: >>>> On 09/07/2010 09:43, Simone Tripodi wrote: >>>>> Hi Pid, >>>>> in that way you're able to verify an HMAC signed signature with an RSA >>>>> verifying key, that's wrong by nature. >>>> >>>> I understand that problem, I'm trying to find a way to avoid generics >>>> for this package. Otherwise we'll have to hard code each sig method in >>>> the implementation. >>>> >>>>>> + >>>>>> + /** >>>>>> + * @param value >>>>>> + * @return key >>>>>> + */ >>>>>> + SigningKey createSigningKey(String... value); >>>>>> + >>>>>> + /** >>>>>> + * @param value >>>>>> + * @return key >>>>>> + */ >>>>>> + VerifyingKey createVerifyingKey(String... value); >>>>>> >>>>> >>>>> uhm I really don't think keys have to be generated by an algorithm >>>>> that the task to sign/verify a signature, Keys can be defined >>>>> independently by the algorithm implementation. >>>> >>>> Please see my previous email thread on this topic. >>>> >>>> Currently it will not be possible to look up a SignatureMethod instance >>>> using a String identifier as a key. We need a solution to the problem, >>>> either by working around it or by coming up with an alternative. >>>> >>>> The current interface design simply will not work, as far as I can tell >>>> - please advise if you believe otherwise. >>>> >>>> >>>>> BTW I was integrating the Signature api to the implementation to the >>>>> already existing codebase and that modification broke my work, can you >>>>> please advice me before you want to modify it, to avoid we both have >>>>> problems? Can you please rollback that class? Thanks in advance, very >>>>> appreciated :) >>>> >>>> Apologies, done. >>>> >>>> >>>> p >>>> >>>>> Simo >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://www.99soft.org/ >>>> >>>> >>>> >> >> >>
signature.asc
Description: OpenPGP digital signature
