Signing just the entity seems to make the most sense to me too.
my 2 cents
--K
On 3/19/13 12:41 PM, Alex O'Ree wrote:
Perhaps it would make more sense to sign just the entity. That is, a
business signed by Cert A, then signed by Cert B. Cert B's signature
is only a hash of the business entity itself, not inclusive of Cert
A's signature. At least this way its slightly more modular. In order
to validate the signature, the signature elements would have to all
removed, then one at a time, inserted for validation
On Mon, Mar 18, 2013 at 10:48 PM, Jesse Sightler
<jesse.sight...@gmail.com> wrote:
I see you are now well on your way down the rabbit hole that is digital
signatures with UDDI. :)
Basically, all of your concerns are valid. It is possible to sign a business
w/o any transformation, and then later sign a service within the business,
exactly as you have described. This will invalidate the business' entire
signature, until it is rewritten. I suspect that any entity saved by a third
party UDDI client would also present issues within the current JUDDI
architecture, without a fairly sophisticated transform being used.
Ultimately, in order to avoid both issues, you will have to make sure to
sign with a transformer that is appropriate for your use-case. XSLT
transforms are generally a good place to start, IMO, and it would be
reasonable to write a standard transform that only signed the elements that
made up the "business" meaning being stored within JUDDI. That is really
what I would recommend if you want to make this really easy to use.
On Mon, Mar 18, 2013 at 9:10 PM, Alex O'Ree <spyhunte...@gmail.com> wrote:
Jesse
Have you ran into the multiple signatures on a uddi entity? Consider
the following scenario:
1) business 1 signed by Cert A
2) business 1 signature is validated - ok
3) business 1 is also signed by Cert B,
4) business 1 signature validation fails
I think whats happening is that when the entity is signed by B, the
signature of A is included in the 2nd signature. The other possibility
is that the validation code has the wrong transform or that the
signatures need to be validated in a specific order.
The real question is, should Cert B's signature be inclusive or
exclusive of Cert A's signature? This effects both the signing and
validation portions
On Mon, Mar 18, 2013 at 4:27 PM, Alex O'Ree <spyhunte...@gmail.com> wrote:
Yes, that's sort of a must have IMO. Basically, I'm setting it up for
either JKS or Windows cert stores, all parameters are set via HashMap
or potentially a properties file. Since there's such a variety of dsig
settings, all of them will be configurable.
On Mon, Mar 18, 2013 at 11:54 AM, Jesse Sightler
<jesse.sight...@gmail.com> wrote:
I assume that you will be changing it to use a truststore for
validation
(certificate chain validation)? Ie, there has to be some step to insure
that
the cert within the signature itself is a trusted cert.
On Mon, Mar 18, 2013 at 11:49 AM, Alex O'Ree <spyhunte...@gmail.com>
wrote:
thanks for the reply. I've since figured it out and I'm working on
moving the relevant code into the juddi-client project to make it a
bit more functional from an end user/dev perspective. I'm also working
on removing the requirement for specifying the certificate when
validating a signature, since the x509 cert is included with the
signature already.
On Sun, Mar 17, 2013 at 11:25 PM, Jesse Sightler
<jesse.sight...@gmail.com> wrote:
Hi Alex,
I'd be happy to help in understanding the code if need be. Samples
are
available in TckBusiness, via the signBusiness and verifyBusiness
methods.
These are used by the saveJoePublisherBusinessX509Signature test,
which
is
run from the UDDI_030_BusinessEntityIntegrationTest (method is
testJoePublisherBusinessEntitySignature).
Keep in mind that all of this code is extremely sensitive to the XML
signature transformations used, as well as the serialization methods
used.
The best documentation for it all is the XML Signature standard and
the
JUDDI specification itself.
Thanks,
Jess
On Sun, Mar 17, 2013 at 11:49 AM, Alex O'Ree <spyhunte...@gmail.com>
wrote:
So I'm looking at the following files
http://svn.apache.org/repos/asf/juddi/tags/juddi-3.1.4/uddi-tck-base/src/main/java/org/apache/juddi/v3/tck/TckSigningUtil.java
http://svn.apache.org/repos/asf/juddi/tags/juddi-3.1.4/juddi-core/src/main/java/org/apache/juddi/mapping/MappingApiToModel.java
with the overall goal of providing a digital signature type of
capability from the browser to a publish/inquiry endpoint, however
I'm
not really seeing anything to connect the dots.
Does anyone have a working example of a uddi client which digitally
signs a uddi element using the juddi client api, then posting it to
juddi?
Is there anything along the lines of validating the signature? or
the
certificate for that matter?
It looks like the TckSiginingUtil could be refactored into the
client
api or the core which would add the required functionality, more or
less. Unfortunately, its not documented very well (at all). I found
that it's used in
\uddi-tck-base\src\main\java\org\apache\juddi\v3\tck\TckBusiness.java
but how it translates to a functional test isn't clear.
