On 07/07/2010 09:39, Simone Tripodi wrote: > Hola Pid > > On Tue, Jul 6, 2010 at 10:38 PM, Pid <p...@pidster.com> wrote: >> >> I'm working on a prototype integrating the signature-api with the config >> stuff & the spec api. Couple of things: >> >> #1 >> > > no problems/objections, feel free to commit it ;) > >> #2 >> >> I'm trying to understand whether it would be possible for the >> SignatureMethodAlgorithm interface to be refactored to just use the Key >> interface, or (SigningKey, VerifyingKey) directly. >> > > Unfortunately, nope. That would be easier if we could take in > consideration only algorithms such PLAINTEXT and HMAC_SHA1, where the > same key is used to both sign/verify the signature, but with RSA > things are quite more complicated. > Using RSA involves users have to use a private key to sign, and a > public certificate to validate. Sounds reasonable - at least to me - > that keys have to be typed, since, potentially, trying to verify an > HMAC signature with an RSA public key is wrong.
I thought as much. Hmm.
>> I assume it's defined like this so an implementation can require it's
>> own key classes to be used?
>>
>>
>> The problem is that I don't think we will be able to use the
>> ServiceLoader mechanism to discover and use signature implementations.
>>
>
> I think your idea is still valid, adding just minor modifications,
> something similar that I already did in the past[1]:
> - with the service loader mechanism, you discover all SignatureMethod
> implementations and optionally store them in a Registry;
> - when a client try to generate/verify a signature, by the key it
> could access to the registry and take the relative algorithm.
Yep. That's the idea.
> Quite clean and easy, thoughts?
In principal, yes, in practice there's some problems that I can't quite
work out. Whether we use ServiceLoader or an equivalent duplicate, the
problem is as as follows...
Very simply:
Map<String, SignatureMethod> registry = ...;
ClassLoader loader = ...;
ServiceLoader<SignatureMethod> services =
ServiceLoader.load(SignatureMethod.class, loader);
for (SignatureMethod sm : services) {
registry.put(sm.getAlgorithm(), sm);
}
Without doing massive quantities of reflection - and I don't know if
even that will do it - the SignatureMethod can only be loaded if it is
not enhanced with generic types.
Even if it was possible to store it efficiently, I can't see a way to
then use it.
String algorithm = oAuthRequest.getAlgorithm();
SignatureMethod method = registry.get(algorithm);
If method was extracted:
SignatureMethod<K,V> method = registry.get(algorithm);
We then need *another* mechanism which helps us create the proper,
matching keys K and V so we can create a concrete object.
K key = createTheKey(oAuthRequest.getSigBase());
// how do we do this?
String signature = calculate(key, oAuthRequest);
I'm a bit stumped. How were you handling this?
p
> Simo
>
> [1]
> http://code.google.com/p/asmx-oauth/source/browse/trunk/core/commons/src/main/java/com/asemantics/oauth/core/signers/RequestSignerRegistry.java
signature.asc
Description: OpenPGP digital signature
