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