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. >>
