Return-Path: Delivered-To: apmail-incubator-amber-dev-archive@minotaur.apache.org Received: (qmail 31356 invoked from network); 9 Jul 2010 11:39:28 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Jul 2010 11:39:28 -0000 Received: (qmail 94067 invoked by uid 500); 9 Jul 2010 11:39:27 -0000 Delivered-To: apmail-incubator-amber-dev-archive@incubator.apache.org Received: (qmail 94032 invoked by uid 500); 9 Jul 2010 11:39:26 -0000 Mailing-List: contact amber-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: amber-dev@incubator.apache.org Delivered-To: mailing list amber-dev@incubator.apache.org Received: (qmail 94021 invoked by uid 99); 9 Jul 2010 11:39:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jul 2010 11:39:25 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of pid@pidster.com designates 74.125.82.175 as permitted sender) Received: from [74.125.82.175] (HELO mail-wy0-f175.google.com) (74.125.82.175) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jul 2010 11:39:18 +0000 Received: by wye20 with SMTP id 20so1510306wye.6 for ; Fri, 09 Jul 2010 04:38:57 -0700 (PDT) Received: by 10.216.165.132 with SMTP id e4mr4033857wel.83.1278675537422; Fri, 09 Jul 2010 04:38:57 -0700 (PDT) Received: from Phoenix.local (cpc2-lewi13-2-0-cust269.2-4.cable.virginmedia.com [86.14.119.14]) by mx.google.com with ESMTPS id x37sm1857564weq.0.2010.07.09.04.38.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 04:38:57 -0700 (PDT) Message-ID: <4C370A47.1020003@pidster.com> Date: Fri, 09 Jul 2010 12:38:47 +0100 From: Pid Reply-To: pid@pidster.com Organization: Pidster Inc User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Amber Developers Subject: Re: svn commit: r962443 - /incubator/amber/trunk/spec-api/src/main/java/org/apache/amber/signature/SignatureMethod.java References: <20100709082846.B7427238897A@eris.apache.org> <4C36E719.3090307@pidster.com> <4C36EA10.6060601@pidster.com> <4C36F3C5.7010406@pidster.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: id=62590808 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig780D585A7602531AA1167FB6" X-Virus-Checked: Checked by ClamAV on apache.org --------------enig780D585A7602531AA1167FB6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: >=20 > 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. >=20 > String consumerKey =3D extractFrom(request); > String methodName =3D extractFrom(request); >=20 > SignatureMethod method =3D > signatureMethodsRegistry.get(methodName); > > VerifyingKey key =3D 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 implementatio= ns. 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. >=20 > What someone else experienced? > Simo >=20 > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ >=20 >=20 >=20 > On Fri, Jul 9, 2010 at 12:02 PM, Pid 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 littl= e >>> 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 =3D extractFrom(request); >> SignatureMethod method =3D 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 method =3D 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 writ= e >> code which differentiates between each type, which negates the point o= f >> using generics. >> >> >> p >> >> >> >> >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Fri, Jul 9, 2010 at 11:21 AM, Pid 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 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 a= n RSA >>>>>>> verifying key, that's wrong by nature. >>>>>> >>>>>> I understand that problem, I'm trying to find a way to avoid gener= ics >>>>>> for this package. Otherwise we'll have to hard code each sig meth= od 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 algorith= m >>>>>>> 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 ins= tance >>>>>> using a String identifier as a key. We need a solution to the pro= blem, >>>>>> 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, ca= n you >>>>>>> please advice me before you want to modify it, to avoid we both h= ave >>>>>>> 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/ >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >> >> >> --------------enig780D585A7602531AA1167FB6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iQIcBAEBCgAGBQJMNwpPAAoJEGoM2OGpOvr98NYP/0lpzH61D/D9Sw1Agv1J1tBI IWaUr16DEB1XGzWiEokguF91quqrJJEQb2O+1jR5fr2yYTIjih/qrf+MZV2pj/d1 niWXM9/GQFv4dAfDpNBphd/ITUAKqlHJRYCxhV32xRBNvcXxTAEP0meTLWO3dLt7 4xV5FFt1FbVUJzckQihH6FFCN0iAfMwLyObqGYM5mJIt13BFo5G6Rzh1uDxAlZVo AUBXH9Tcuq5TIT3hH17b9T3uRXpWlqQDG9J0Th88wmUM8KRllrhkeHINrWUPFzFq VTvlGj+bzZzHIo3UfkA+q357NVeBSxGU3yhR3SgnyNUvj+lUTLJzmPg93YlRwOWL 1ROPPMvzp/Z6NC8NkloKscJlwcb26b9RuDQlv51Gq/ZnZuxcxXh5WVGmZSYcIGb9 a/X2x0o+PW+oj9BieRbNgiuYsTVF2wZRrAGi9jbepCE+c4+98LDaPKID2Q2vjTHV xL1ZWmGJdi2eS+oz8aOqeLW727QO+V24OZgjgOOZph5tbCB16VLrcY5D+VDZaai1 tPWvF6tZO5u8YKEAIvkr0EyAOhxfJ9nwjvU/99uWIW3qlsM9q1+t0HDxY/VqiPYt 1VP3s9U+6+K5d0pt+rKc6ClMfYTSj1GdPHEyeVTyQdMi+ZOQn9GiCCkP5hVKzPeZ PQb/gPnArQ4+bA8nboW1 =sO2j -----END PGP SIGNATURE----- --------------enig780D585A7602531AA1167FB6--