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