So provided i can figure out the transforms, I've ran into an issue that I need some input on.
>From a thick client, if they recieve a signed uddi entity and valid it, trust would assumed to be available from the local machine or from a user provided trust store. No problem. >From a thin client, such as the new web gui I'm working on, what makes the most sense to use as a trust store? I'd like to have a browser message stating whether or not the signature is valid and if the cert is trusted and still valid timewise and if it hasn't been revoked (perhaps via OCSP/CRL). Options are: 1) A server side provided trust store 2) An applet that relies on access to a client side trust store 3) Some combination of the two On Sat, Mar 23, 2013 at 7:59 AM, Alex O'Ree <[email protected]> wrote: > I'm inclined to say both client and server. Probably called directly > from the example > > On Fri, Mar 22, 2013 at 10:42 PM, Kurt Stam <[email protected]> wrote: >> 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" <[email protected]> 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 <[email protected]> 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 >>>>> <[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. >>>>
