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