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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 >>>> <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 >>>>>>> <[email protected]> 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 <[email protected]> >>>>>>>> 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 >>>>>>>>> <[email protected]> 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 <[email protected]> >>>>>>>>>> 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. >>>
