ok let's drop the use of generic, so only Verifying/Signing key type
are enough. At the same time that means that the SignatureMethod
implementation has to check if the current key is valid for
signing/verifying the signature:
if (SignatureMethod#getAlgorithm() is contained into Key#getAlgorithmMethods() {
that's a good key!!!
}
sounds good, not efficient like the type checking but that's a good compromise.
Going to modify the interface in a short while!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Jul 9, 2010 at 1:38 PM, Pid <[email protected]> wrote:
> On 09/07/2010 11:27, Simone Tripodi wrote:
>> Ok I understood your point of view, thanks for showing the use case.
>> I see things different, because of the past experiences, this is what
>> we successfully did in the past:
>>
>> On the Server side, the scenario is that when receiving the OAuth
>> request, extracting oauth_consumer_key AND oauth_signature_method we
>> retrieve (from a proper Storage that's currently missing) the relative
>> key.
>> We can't assume things too generic because for the RSA algorithm that
>> works with certificates, and things are totally different.
>>
>> String consumerKey = extractFrom(request);
>> String methodName = extractFrom(request);
>>
>> SignatureMethod<SignatureKey, VerifyingKey> method =
>> signatureMethodsRegistry.get(methodName);
>>
>> VerifyingKey key = fromStorage(consumerKey, methodName);
>> method.verify(key, request);
>
> Yes, I got that far, but can we not achieve the same without generics?
>
> Also, doesn't the fromStorage() method need to hard code the class
> instantiation of the implementation for each key class?
>
> How does it know which class to use? We only know about the
> SignatureMethod at this point - we don't know about the key implementations.
>
> This is why I was thinking about adding a method to the SignatureMethod
> interface which provides the key implementation for the method in use.
>
>
>> If you play a little with providers (try oauthplayground) you can see
>> how it is a common practice associating ONE key/certificates for each
>> method for each consumer, clients shall not be able to sign request
>> with more than one key for the same method, otherwise Providers should
>> guess with which of n keys for the same method the signature has been
>> signed.
>
> I completely agree with that, no issue there from me.
> The key selection logic would prevent the wrong key being used with the
> wrong type anyway, no?
>
>
> p
>
>> At the same time, it doesn't mean that Consumers have just one key,
>> they can have the RSA certificate, a secret for HMAC, a secret for
>> PLAINTEXT... but just one for method.
>>
>> What someone else experienced?
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Fri, Jul 9, 2010 at 12:02 PM, Pid <[email protected]> wrote:
>>> 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/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
