Yes, that would make more sense. However, to be compliant with the UDDI/XML Signature specification, you will have to do this via the digital signature's transform element. It has been a while since I was looking at this in detail, but I should be able to help if you need some assistance with it.
The specification includes an example with XPath to accomplish something like this: XPath: http://www.w3.org/TR/xmldsig-filter2/#sec-Examples XSLT is also possible: XSLT Documentation: http://www.w3.org/TR/xmldsig-core/#sec-XSLT On Tue, Mar 19, 2013 at 12:41 PM, Alex O'Ree <[email protected]> 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. > >> >>> > > >> >>> > > >> >> > >> >> > > > > >
