Cool, we are currently compiling to java 1.5. Maybe we can drop 1.5 support for the 3.2 release, and compile to 1.6.
Sent from my iPad On Mar 30, 2013, at 12:32 PM, "Alex O'Ree" <[email protected]> wrote: > It looks like including santuario may be unnecessary. > https://blogs.oracle.com/mullan/entry/using_more_recent_apache_xml > > The JDK implementation includes pretty much the same code. > > On Sat, Mar 30, 2013 at 11:15 AM, Alex O'Ree <[email protected]> wrote: >> 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. >>>>>>
