I think I prefer option 1. It's much harder to support client side key stores.
my 2 cents --Kurt Sent from my iPad On Mar 30, 2013, at 11:15 AM, "Alex O'Ree" <spyhunte...@gmail.com> wrote: > So provided i can figure out the transforms, I've ran into an issue > that I need some input on. > > From a thick client, if they recieve a signed uddi entity and valid > it, trust would assumed to be available from the local machine or from > a user provided trust store. No problem. > > From a thin client, such as the new web gui I'm working on, what makes > the most sense to use as a trust store? I'd like to have a browser > message stating whether or not the signature is valid and if the cert > is trusted and still valid timewise and if it hasn't been revoked > (perhaps via OCSP/CRL). Options are: > 1) A server side provided trust store > 2) An applet that relies on access to a client side trust store > 3) Some combination of the two > > > > On Sat, Mar 23, 2013 at 7:59 AM, Alex O'Ree <spyhunte...@gmail.com> wrote: >> I'm inclined to say both client and server. Probably called directly >> from the example >> >> On Fri, Mar 22, 2013 at 10:42 PM, Kurt Stam <kurt.s...@gmail.com> wrote: >>> Seems reasonable, would this be a dependency on the client or server side, >>> or both? >>> >>> Well we be using it directly or behind an interface? >>> >>> -Kurt >>> >>> On Mar 22, 2013, at 20:33, "Alex O'Ree" <spyhunte...@gmail.com> wrote: >>> >>>> I'd like to make a suggestion. Include Apache Santuario has a client >>>> dependency. It provides a well tested digital signature and validation >>>> capabilities, is well document and has a number of samples that would >>>> be a perfect addition for providing signatures for UDDI registries. >>>> Any other opinions? >>>> >>>> On Tue, Mar 19, 2013 at 8:02 PM, Kurt T Stam <kurt.s...@gmail.com> wrote: >>>>> Signing just the entity seems to make the most sense to me too. >>>>> >>>>> my 2 cents >>>>> >>>>> --K >>>>> >>>>> >>>>> On 3/19/13 12:41 PM, Alex O'Ree wrote: >>>>>> >>>>>> Perhaps it would make more sense to sign just the entity. That is, a >>>>>> business signed by Cert A, then signed by Cert B. Cert B's signature >>>>>> is only a hash of the business entity itself, not inclusive of Cert >>>>>> A's signature. At least this way its slightly more modular. In order >>>>>> to validate the signature, the signature elements would have to all >>>>>> removed, then one at a time, inserted for validation >>>>>> >>>>>> On Mon, Mar 18, 2013 at 10:48 PM, Jesse Sightler >>>>>> <jesse.sight...@gmail.com> wrote: >>>>>>> >>>>>>> I see you are now well on your way down the rabbit hole that is digital >>>>>>> signatures with UDDI. :) >>>>>>> >>>>>>> Basically, all of your concerns are valid. It is possible to sign a >>>>>>> business >>>>>>> w/o any transformation, and then later sign a service within the >>>>>>> business, >>>>>>> exactly as you have described. This will invalidate the business' entire >>>>>>> signature, until it is rewritten. I suspect that any entity saved by a >>>>>>> third >>>>>>> party UDDI client would also present issues within the current JUDDI >>>>>>> architecture, without a fairly sophisticated transform being used. >>>>>>> >>>>>>> Ultimately, in order to avoid both issues, you will have to make sure to >>>>>>> sign with a transformer that is appropriate for your use-case. XSLT >>>>>>> transforms are generally a good place to start, IMO, and it would be >>>>>>> reasonable to write a standard transform that only signed the elements >>>>>>> that >>>>>>> made up the "business" meaning being stored within JUDDI. That is really >>>>>>> what I would recommend if you want to make this really easy to use. >>>>>>> >>>>>>> >>>>>>> On Mon, Mar 18, 2013 at 9:10 PM, Alex O'Ree <spyhunte...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Jesse >>>>>>>> >>>>>>>> Have you ran into the multiple signatures on a uddi entity? Consider >>>>>>>> the following scenario: >>>>>>>> 1) business 1 signed by Cert A >>>>>>>> 2) business 1 signature is validated - ok >>>>>>>> 3) business 1 is also signed by Cert B, >>>>>>>> 4) business 1 signature validation fails >>>>>>>> >>>>>>>> I think whats happening is that when the entity is signed by B, the >>>>>>>> signature of A is included in the 2nd signature. The other possibility >>>>>>>> is that the validation code has the wrong transform or that the >>>>>>>> signatures need to be validated in a specific order. >>>>>>>> >>>>>>>> The real question is, should Cert B's signature be inclusive or >>>>>>>> exclusive of Cert A's signature? This effects both the signing and >>>>>>>> validation portions >>>>>>>> >>>>>>>> On Mon, Mar 18, 2013 at 4:27 PM, Alex O'Ree <spyhunte...@gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Yes, that's sort of a must have IMO. Basically, I'm setting it up for >>>>>>>>> either JKS or Windows cert stores, all parameters are set via HashMap >>>>>>>>> or potentially a properties file. Since there's such a variety of dsig >>>>>>>>> settings, all of them will be configurable. >>>>>>>>> >>>>>>>>> On Mon, Mar 18, 2013 at 11:54 AM, Jesse Sightler >>>>>>>>> <jesse.sight...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>> I assume that you will be changing it to use a truststore for >>>>>>>>>> validation >>>>>>>>>> (certificate chain validation)? Ie, there has to be some step to >>>>>>>>>> insure >>>>>>>>>> that >>>>>>>>>> the cert within the signature itself is a trusted cert. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Mar 18, 2013 at 11:49 AM, Alex O'Ree <spyhunte...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> thanks for the reply. I've since figured it out and I'm working on >>>>>>>>>>> moving the relevant code into the juddi-client project to make it a >>>>>>>>>>> bit more functional from an end user/dev perspective. I'm also >>>>>>>>>>> working >>>>>>>>>>> on removing the requirement for specifying the certificate when >>>>>>>>>>> validating a signature, since the x509 cert is included with the >>>>>>>>>>> signature already. >>>>>>>>>>> >>>>>>>>>>> On Sun, Mar 17, 2013 at 11:25 PM, Jesse Sightler >>>>>>>>>>> <jesse.sight...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Alex, >>>>>>>>>>>> >>>>>>>>>>>> I'd be happy to help in understanding the code if need be. Samples >>>>>>>>>>>> are >>>>>>>>>>>> available in TckBusiness, via the signBusiness and verifyBusiness >>>>>>>>>>>> methods. >>>>>>>>>>>> These are used by the saveJoePublisherBusinessX509Signature test, >>>>>>>>>>>> which >>>>>>>>>>>> is >>>>>>>>>>>> run from the UDDI_030_BusinessEntityIntegrationTest (method is >>>>>>>>>>>> testJoePublisherBusinessEntitySignature). >>>>>>>>>>>> >>>>>>>>>>>> Keep in mind that all of this code is extremely sensitive to the >>>>>>>>>>>> XML >>>>>>>>>>>> signature transformations used, as well as the serialization >>>>>>>>>>>> methods >>>>>>>>>>>> used. >>>>>>>>>>>> The best documentation for it all is the XML Signature standard and >>>>>>>>>>>> the >>>>>>>>>>>> JUDDI specification itself. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jess >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Mar 17, 2013 at 11:49 AM, Alex O'Ree >>>>>>>>>>>> <spyhunte...@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> So I'm looking at the following files >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://svn.apache.org/repos/asf/juddi/tags/juddi-3.1.4/uddi-tck-base/src/main/java/org/apache/juddi/v3/tck/TckSigningUtil.java >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://svn.apache.org/repos/asf/juddi/tags/juddi-3.1.4/juddi-core/src/main/java/org/apache/juddi/mapping/MappingApiToModel.java >>>>>>>>>>>>> >>>>>>>>>>>>> with the overall goal of providing a digital signature type of >>>>>>>>>>>>> capability from the browser to a publish/inquiry endpoint, however >>>>>>>>>>>>> I'm >>>>>>>>>>>>> not really seeing anything to connect the dots. >>>>>>>>>>>>> >>>>>>>>>>>>> Does anyone have a working example of a uddi client which >>>>>>>>>>>>> digitally >>>>>>>>>>>>> signs a uddi element using the juddi client api, then posting it >>>>>>>>>>>>> to >>>>>>>>>>>>> juddi? >>>>>>>>>>>>> >>>>>>>>>>>>> Is there anything along the lines of validating the signature? or >>>>>>>>>>>>> the >>>>>>>>>>>>> certificate for that matter? >>>>>>>>>>>>> >>>>>>>>>>>>> It looks like the TckSiginingUtil could be refactored into the >>>>>>>>>>>>> client >>>>>>>>>>>>> api or the core which would add the required functionality, more >>>>>>>>>>>>> or >>>>>>>>>>>>> less. Unfortunately, its not documented very well (at all). I >>>>>>>>>>>>> found >>>>>>>>>>>>> that it's used in >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> \uddi-tck-base\src\main\java\org\apache\juddi\v3\tck\TckBusiness.java >>>>>>>>>>>>> but how it translates to a functional test isn't clear. >>>>>
