You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@juddi.apache.org by Alex O'Ree <sp...@gmail.com> on 2013/03/17 16:49:44 UTC
Digital signature example?
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.
Re: Digital signature example?
Posted by Kurt Stam <ku...@gmail.com>.
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" <sp...@gmail.com> 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 <sp...@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 <sp...@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 <ku...@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" <sp...@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 <ku...@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
>>>>>>> <je...@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 <sp...@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 <sp...@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
>>>>>>>>>> <je...@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 <sp...@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
>>>>>>>>>>>> <je...@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 <sp...@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.
>>>>>>
Re: Digital signature example?
Posted by Alex O'Ree <sp...@gmail.com>.
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 <sp...@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 <sp...@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 <ku...@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" <sp...@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 <ku...@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
>>>>>> <je...@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 <sp...@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 <sp...@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
>>>>>>>>> <je...@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 <sp...@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
>>>>>>>>>>> <je...@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 <sp...@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.
>>>>>
Re: Digital signature example?
Posted by Jesse Sightler <je...@gmail.com>.
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 <sp...@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 <ku...@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" <sp...@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 <sp...@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 <ku...@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" <sp...@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 <ku...@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
> >>>>>>> <je...@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 <
> spyhunter99@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 <
> spyhunter99@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
> >>>>>>>>>> <je...@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 <
> spyhunter99@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
> >>>>>>>>>>>> <je...@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 <
> spyhunter99@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.
> >>>>>>
>
Re: Digital signature example?
Posted by Alex O'Ree <sp...@gmail.com>.
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 <ku...@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" <sp...@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 <sp...@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 <ku...@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" <sp...@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 <ku...@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
>>>>>>> <je...@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 <sp...@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 <sp...@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
>>>>>>>>>> <je...@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 <sp...@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
>>>>>>>>>>>> <je...@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 <sp...@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.
>>>>>>
Re: Digital signature example?
Posted by Kurt Stam <ku...@gmail.com>.
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" <sp...@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 <sp...@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 <ku...@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" <sp...@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 <ku...@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
>>>>>> <je...@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 <sp...@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 <sp...@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
>>>>>>>>> <je...@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 <sp...@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
>>>>>>>>>>> <je...@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 <sp...@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.
>>>>>
Re: Digital signature example?
Posted by Alex O'Ree <sp...@gmail.com>.
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 <sp...@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 <ku...@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" <sp...@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 <ku...@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
>>>>> <je...@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 <sp...@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 <sp...@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
>>>>>>>> <je...@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 <sp...@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
>>>>>>>>>> <je...@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 <sp...@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.
>>>>
Re: Digital signature example?
Posted by Alex O'Ree <sp...@gmail.com>.
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 <ku...@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" <sp...@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 <ku...@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
>>>> <je...@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 <sp...@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 <sp...@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
>>>>>>> <je...@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 <sp...@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
>>>>>>>>> <je...@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 <sp...@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.
>>>
Re: Digital signature example?
Posted by Kurt Stam <ku...@gmail.com>.
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" <sp...@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 <ku...@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
>>> <je...@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 <sp...@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 <sp...@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
>>>>>> <je...@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 <sp...@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
>>>>>>>> <je...@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 <sp...@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.
>>
Re: Digital signature example?
Posted by Alex O'Ree <sp...@gmail.com>.
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 <ku...@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
>> <je...@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 <sp...@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 <sp...@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
>>>>> <je...@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 <sp...@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
>>>>>>> <je...@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 <sp...@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.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>
Re: Digital signature example?
Posted by Kurt T Stam <ku...@gmail.com>.
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
> <je...@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 <sp...@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 <sp...@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
>>>> <je...@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 <sp...@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
>>>>>> <je...@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 <sp...@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.
>>>>>>>
>>>>>
>>
Re: Digital signature example?
Posted by Jesse Sightler <je...@gmail.com>.
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 <sp...@gmail.com> 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
> <je...@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 <sp...@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 <sp...@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
> >> > <je...@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 <sp...@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
> >> >>> <je...@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 <
> spyhunter99@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.
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >
> >
>
Re: Digital signature example?
Posted by Alex O'Ree <sp...@gmail.com>.
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
<je...@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 <sp...@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 <sp...@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
>> > <je...@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 <sp...@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
>> >>> <je...@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 <sp...@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.
>> >>> >
>> >>> >
>> >>
>> >>
>
>
Re: Digital signature example?
Posted by Jesse Sightler <je...@gmail.com>.
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 <sp...@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 <sp...@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
> > <je...@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 <sp...@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
> >>> <je...@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 <sp...@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.
> >>> >
> >>> >
> >>
> >>
>
Re: Digital signature example?
Posted by Alex O'Ree <sp...@gmail.com>.
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 <sp...@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
> <je...@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 <sp...@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
>>> <je...@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 <sp...@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.
>>> >
>>> >
>>
>>
Re: Digital signature example?
Posted by Alex O'Ree <sp...@gmail.com>.
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
<je...@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 <sp...@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
>> <je...@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 <sp...@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.
>> >
>> >
>
>
Re: Digital signature example?
Posted by Jesse Sightler <je...@gmail.com>.
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 <sp...@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
> <je...@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 <sp...@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.
> >
> >
>
Re: Digital signature example?
Posted by Alex O'Ree <sp...@gmail.com>.
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
<je...@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 <sp...@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.
>
>
Re: Digital signature example?
Posted by Jesse Sightler <je...@gmail.com>.
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 <sp...@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.
>