I have not worked with digital signatures using PGP. I'm not sure where the sample's PGP could have come from.
On Sat, Jan 11, 2014 at 12:59 PM, Alex O'Ree <spyhunte...@gmail.com> wrote: > Jess > > By any chance you have experimented with using PGP keys to sign xml? I > see in the source trunk that there are a few examples of signed xml > using pgp, but I have no idea how they were generated. Thanks > > Alex > > On Sat, Mar 30, 2013 at 1:05 PM, Kurt Stam <kurt.s...@gmail.com> wrote: > > I think I prefer option 1. It's much harder to support client side key > stores. > > > > my 2 cents > > > > --Kurt > > > > Sent from my iPad > > > > On Mar 30, 2013, at 11:15 AM, "Alex O'Ree" <spyhunte...@gmail.com> > 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 <spyhunte...@gmail.com> > 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 <kurt.s...@gmail.com> > 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" <spyhunte...@gmail.com> > 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 <kurt.s...@gmail.com> > 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 > >>>>>>> <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. > >>>>>> >
