You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by Tom Howe <tu...@gmail.com> on 2009/08/26 19:05:07 UTC
Re: Use of X.509 Proxy Certificates
I'm working on this problem with Rachana. I wondered if anyone had any
thoughts on how we could incorporate these customizations.
Thanks,
Tom Howe
On Wed, Aug 19, 2009 at 3:31 PM, Rachana Ananthakrishnan <
ranantha@mcs.anl.gov> wrote:
> Hi,
>
> We have requirements to use X.509 Proxy Certificates (
> http://www.ietf.org/rfc/rfc3820.txt) for message signature and validation.
> We have provider implementation of CertPathValidator, that deals with X.509
> Proxy Certificates. We also have a CertStore implementation that deals with
> our trusted certificates and CRL processing, implemented as a provider.
>
> But looking at the WSS4J trunk code, specifically, SingnatureProcessor (
> http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/org/apache/ws/security/processor/SignatureProcessor.java?view=annotate),
> line 360 onwards, it appears that the trust verification is baked into the
> code.
>
> Are there any plans to use the standard Java Security Provider framework
> for this? Can the trust verification and path validation be made
> configurable, with use of the current implementation as a fallback mechanism
> if no other trust verification is configured?
>
> If not, can anyone advice on the best way to integrate this with the
> current code base? We could extend and modify the WSS4J library (we do this
> for the current version of toolkit based on Apache Axis), but before we
> explore that option, if there are suggestions for cleaner integration or any
> planned changes that would accommodate our requirement, that would be great.
> Our main intention here is to use this with Apache CXF, and are happy to
> contribute any pieces we might have to develop to back to the project.
>
> Thanks,
> Rachana
>
> Rachana Ananthakrishnan
> Argonne National Laboratory | University of Chicago
>
--
Tom Howe
Senior Software Engineer
Distributed Systems Lab
University of Chicago/Argonne National Laboratory
Sent from Chicago, Illinois, United States
RE: Use of X.509 Proxy Certificates
Posted by Colm O hEigeartaigh <co...@progress.com>.
Hi guys,
Adding support for X.509 proxy certificates to WSS4J would definitely be
nice.
> line 360 onwards, it appears that the trust verification is baked into
the code.
> Are there any plans to use the standard Java Security Provider
framework for this?
> Can the trust verification and path validation be made configurable,
with use of the current implementation as a fallback mechanism if no
other trust verification is configured?
Trust verification is baked into the code as it's generally a standard
thing to verify trust on an X.509 certificate that is associated with a
signed message. I don't see a problem with adapting the current code to
provide support for proxy certificates. The current code validates all
of the received certificate chain, but then only verifies trust on the
base certificate. It does this by:
- Checking to see if the cert is in the keystore
- If not, then find all certs in the keystore that might issue
the received cert
- For all of the certs found construct a certificate chain and
validate it via a CertPathValidator implementation
To support proxy certificates I would envisage something like the
following happening:
- Check to see if the base cert is in the keystore as before
- If not, then find all certs in the keystore that might issue
the received base cert
- If we find a match then proceed as before
- If there is no match, then look for an issuer of any of the
other certs that were received
- Construct a cert chain from the base cert, to the other
received certs, to the issuer cert in the keystore and validate it
Take a look at AbstractCrypto.validateCertPath(X509Certificate[]
certs)...do you think this suits your needs in terms of cert path
validation? I'm open to any concrete suggestions you have to modify the
current code to support your requirements.
Colm.
________________________________
From: Tom Howe [mailto:turtlebender@gmail.com]
Sent: 26 August 2009 18:05
To: Rachana Ananthakrishnan
Cc: WSS4J Dev-list
Subject: Re: Use of X.509 Proxy Certificates
I'm working on this problem with Rachana. I wondered if anyone had any
thoughts on how we could incorporate these customizations.
Thanks,
Tom Howe
On Wed, Aug 19, 2009 at 3:31 PM, Rachana Ananthakrishnan
<ra...@mcs.anl.gov> wrote:
Hi,
We have requirements to use X.509 Proxy Certificates
(http://www.ietf.org/rfc/rfc3820.txt) for message signature and
validation. We have provider implementation of CertPathValidator, that
deals with X.509 Proxy Certificates. We also have a CertStore
implementation that deals with our trusted certificates and CRL
processing, implemented as a provider.
But looking at the WSS4J trunk code, specifically, SingnatureProcessor
(http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/org/apache/ws/
security/processor/SignatureProcessor.java?view=annotate), line 360
onwards, it appears that the trust verification is baked into the code.
Are there any plans to use the standard Java Security Provider framework
for this? Can the trust verification and path validation be made
configurable, with use of the current implementation as a fallback
mechanism if no other trust verification is configured?
If not, can anyone advice on the best way to integrate this with the
current code base? We could extend and modify the WSS4J library (we do
this for the current version of toolkit based on Apache Axis), but
before we explore that option, if there are suggestions for cleaner
integration or any planned changes that would accommodate our
requirement, that would be great. Our main intention here is to use this
with Apache CXF, and are happy to contribute any pieces we might have to
develop to back to the project.
Thanks,
Rachana
Rachana Ananthakrishnan
Argonne National Laboratory | University of Chicago
--
Tom Howe
Senior Software Engineer
Distributed Systems Lab
University of Chicago/Argonne National Laboratory
Sent from Chicago, Illinois, United States