You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by ji...@apache.org on 2004/05/13 15:47:56 UTC
[jira] Created: (WSFX-6) Validation of the certificate that was used to sign the message
Message:
A new issue has been created in JIRA.
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/WSFX-6
Here is an overview of the issue:
---------------------------------------------------------------------
Key: WSFX-6
Summary: Validation of the certificate that was used to sign the message
Type: New Feature
Status: Unassigned
Priority: Major
Project: WSFX
Components:
WSS4J
Assignee:
Reporter: Christof Soehngen
Created: Thu, 13 May 2004 6:47 AM
Updated: Thu, 13 May 2004 6:47 AM
Environment: CVS snapshot from 2004/13/05
Description:
Here is my proposal for a validation of the certificate that was used to sign the message.
This validation could be used for authorization: Accept only messages that were signed by a trusted certificate. Trust is assigned by installing the certificate itself or the certificates issuer in the local keystore (based on the #X509v3 ValueType that allows only one certificate to be transmitted).
The architecture of WSS4J should allow subclasses of WSDoAllReceiver to replace the default behaviour with custom validation algorithms.
To achieve these goals (implementation of the validation-algorithm described above and hook for custom algorithms) the following modifications should to be made:
org.apache.ws.axis.security.WSDoAllReceiver:
- modify the method invoke()
take the signers certificate from the ResultVector and verify its trust
- new method: boolean verifyTrust(X509Certificate)
implementation of the validation-algorithm described above
org.apache.ws.security.components.crypto.Crypto (and Merlin):
- new method: boolean validateCertPath(X509Certificate[] certs)
Uses the CertPath API to validate a certificate chain
- new method: String[] getAliasesForDN(String subjectDN)
Looks up all aliases for a given DN in the keystore
org.apache.ws.security.errors.properties:
- new error: certpath = Error during certPath validation: {0}
org.apache.ws.security.util.WSSecurityUtil:
- new method: fetchActionResult(Vector wsResultVector, int action)
Makes fetching results from the SecurityEngineResults more comfortable
The patches for those modifications are attached.
NOTE: The validation of the certificate path via CertPath API (in Merlin.validateCertPath())is still hardcoded to BC! This is because I was not able to avoid the following exception when not using BC classes directly:
java.security.NoSuchAlgorithmException: class configured for CertPathValidator: org.bouncycastle.jce.provider.PKIXCertPathValidatorSpi not a CertPathValidator
Any hint how to make this part provider-independent (just like the CertificateFactory) would be appreciated!
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (WSFX-6) Validation of the certificate that was used to sign the message
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Christof Soehngen (mailto:christof.soehngen@syracom.de)
Date: Thu, 13 May 2004 6:48 AM
Changes:
Attachment changed to Merlin.java.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/WSFX-6?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/WSFX-6
Here is an overview of the issue:
---------------------------------------------------------------------
Key: WSFX-6
Summary: Validation of the certificate that was used to sign the message
Type: New Feature
Status: Unassigned
Priority: Major
Project: WSFX
Components:
WSS4J
Assignee:
Reporter: Christof Soehngen
Created: Thu, 13 May 2004 6:47 AM
Updated: Thu, 13 May 2004 6:48 AM
Environment: CVS snapshot from 2004/13/05
Description:
Here is my proposal for a validation of the certificate that was used to sign the message.
This validation could be used for authorization: Accept only messages that were signed by a trusted certificate. Trust is assigned by installing the certificate itself or the certificates issuer in the local keystore (based on the #X509v3 ValueType that allows only one certificate to be transmitted).
The architecture of WSS4J should allow subclasses of WSDoAllReceiver to replace the default behaviour with custom validation algorithms.
To achieve these goals (implementation of the validation-algorithm described above and hook for custom algorithms) the following modifications should to be made:
org.apache.ws.axis.security.WSDoAllReceiver:
- modify the method invoke()
take the signers certificate from the ResultVector and verify its trust
- new method: boolean verifyTrust(X509Certificate)
implementation of the validation-algorithm described above
org.apache.ws.security.components.crypto.Crypto (and Merlin):
- new method: boolean validateCertPath(X509Certificate[] certs)
Uses the CertPath API to validate a certificate chain
- new method: String[] getAliasesForDN(String subjectDN)
Looks up all aliases for a given DN in the keystore
org.apache.ws.security.errors.properties:
- new error: certpath = Error during certPath validation: {0}
org.apache.ws.security.util.WSSecurityUtil:
- new method: fetchActionResult(Vector wsResultVector, int action)
Makes fetching results from the SecurityEngineResults more comfortable
The patches for those modifications are attached.
NOTE: The validation of the certificate path via CertPath API (in Merlin.validateCertPath())is still hardcoded to BC! This is because I was not able to avoid the following exception when not using BC classes directly:
java.security.NoSuchAlgorithmException: class configured for CertPathValidator: org.bouncycastle.jce.provider.PKIXCertPathValidatorSpi not a CertPathValidator
Any hint how to make this part provider-independent (just like the CertificateFactory) would be appreciated!
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (WSFX-6) Validation of the certificate that was used to sign the message
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Christof Soehngen (mailto:christof.soehngen@syracom.de)
Date: Thu, 13 May 2004 6:49 AM
Changes:
Attachment changed to WSSecurityUtil.java.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/WSFX-6?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/WSFX-6
Here is an overview of the issue:
---------------------------------------------------------------------
Key: WSFX-6
Summary: Validation of the certificate that was used to sign the message
Type: New Feature
Status: Unassigned
Priority: Major
Project: WSFX
Components:
WSS4J
Assignee:
Reporter: Christof Soehngen
Created: Thu, 13 May 2004 6:47 AM
Updated: Thu, 13 May 2004 6:49 AM
Environment: CVS snapshot from 2004/13/05
Description:
Here is my proposal for a validation of the certificate that was used to sign the message.
This validation could be used for authorization: Accept only messages that were signed by a trusted certificate. Trust is assigned by installing the certificate itself or the certificates issuer in the local keystore (based on the #X509v3 ValueType that allows only one certificate to be transmitted).
The architecture of WSS4J should allow subclasses of WSDoAllReceiver to replace the default behaviour with custom validation algorithms.
To achieve these goals (implementation of the validation-algorithm described above and hook for custom algorithms) the following modifications should to be made:
org.apache.ws.axis.security.WSDoAllReceiver:
- modify the method invoke()
take the signers certificate from the ResultVector and verify its trust
- new method: boolean verifyTrust(X509Certificate)
implementation of the validation-algorithm described above
org.apache.ws.security.components.crypto.Crypto (and Merlin):
- new method: boolean validateCertPath(X509Certificate[] certs)
Uses the CertPath API to validate a certificate chain
- new method: String[] getAliasesForDN(String subjectDN)
Looks up all aliases for a given DN in the keystore
org.apache.ws.security.errors.properties:
- new error: certpath = Error during certPath validation: {0}
org.apache.ws.security.util.WSSecurityUtil:
- new method: fetchActionResult(Vector wsResultVector, int action)
Makes fetching results from the SecurityEngineResults more comfortable
The patches for those modifications are attached.
NOTE: The validation of the certificate path via CertPath API (in Merlin.validateCertPath())is still hardcoded to BC! This is because I was not able to avoid the following exception when not using BC classes directly:
java.security.NoSuchAlgorithmException: class configured for CertPathValidator: org.bouncycastle.jce.provider.PKIXCertPathValidatorSpi not a CertPathValidator
Any hint how to make this part provider-independent (just like the CertificateFactory) would be appreciated!
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Closed: (WSFX-6) Validation of the certificate that was used to sign the message
Posted by ji...@apache.org.
Message:
The following issue has been closed.
Resolver: Davanum Srinivas
Date: Thu, 13 May 2004 7:28 AM
Applied your fix.
thanks,
dims
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/WSFX-6
Here is an overview of the issue:
---------------------------------------------------------------------
Key: WSFX-6
Summary: Validation of the certificate that was used to sign the message
Type: New Feature
Status: Closed
Priority: Major
Resolution: FIXED
Project: WSFX
Components:
WSS4J
Assignee:
Reporter: Christof Soehngen
Created: Thu, 13 May 2004 6:47 AM
Updated: Thu, 13 May 2004 7:28 AM
Environment: CVS snapshot from 2004/13/05
Description:
Here is my proposal for a validation of the certificate that was used to sign the message.
This validation could be used for authorization: Accept only messages that were signed by a trusted certificate. Trust is assigned by installing the certificate itself or the certificates issuer in the local keystore (based on the #X509v3 ValueType that allows only one certificate to be transmitted).
The architecture of WSS4J should allow subclasses of WSDoAllReceiver to replace the default behaviour with custom validation algorithms.
To achieve these goals (implementation of the validation-algorithm described above and hook for custom algorithms) the following modifications should to be made:
org.apache.ws.axis.security.WSDoAllReceiver:
- modify the method invoke()
take the signers certificate from the ResultVector and verify its trust
- new method: boolean verifyTrust(X509Certificate)
implementation of the validation-algorithm described above
org.apache.ws.security.components.crypto.Crypto (and Merlin):
- new method: boolean validateCertPath(X509Certificate[] certs)
Uses the CertPath API to validate a certificate chain
- new method: String[] getAliasesForDN(String subjectDN)
Looks up all aliases for a given DN in the keystore
org.apache.ws.security.errors.properties:
- new error: certpath = Error during certPath validation: {0}
org.apache.ws.security.util.WSSecurityUtil:
- new method: fetchActionResult(Vector wsResultVector, int action)
Makes fetching results from the SecurityEngineResults more comfortable
The patches for those modifications are attached.
NOTE: The validation of the certificate path via CertPath API (in Merlin.validateCertPath())is still hardcoded to BC! This is because I was not able to avoid the following exception when not using BC classes directly:
java.security.NoSuchAlgorithmException: class configured for CertPathValidator: org.bouncycastle.jce.provider.PKIXCertPathValidatorSpi not a CertPathValidator
Any hint how to make this part provider-independent (just like the CertificateFactory) would be appreciated!
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (WSFX-6) Validation of the certificate that was used to sign the message
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Christof Soehngen (mailto:christof.soehngen@syracom.de)
Date: Thu, 13 May 2004 6:48 AM
Changes:
Attachment changed to errors.properties.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/WSFX-6?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/WSFX-6
Here is an overview of the issue:
---------------------------------------------------------------------
Key: WSFX-6
Summary: Validation of the certificate that was used to sign the message
Type: New Feature
Status: Unassigned
Priority: Major
Project: WSFX
Components:
WSS4J
Assignee:
Reporter: Christof Soehngen
Created: Thu, 13 May 2004 6:47 AM
Updated: Thu, 13 May 2004 6:48 AM
Environment: CVS snapshot from 2004/13/05
Description:
Here is my proposal for a validation of the certificate that was used to sign the message.
This validation could be used for authorization: Accept only messages that were signed by a trusted certificate. Trust is assigned by installing the certificate itself or the certificates issuer in the local keystore (based on the #X509v3 ValueType that allows only one certificate to be transmitted).
The architecture of WSS4J should allow subclasses of WSDoAllReceiver to replace the default behaviour with custom validation algorithms.
To achieve these goals (implementation of the validation-algorithm described above and hook for custom algorithms) the following modifications should to be made:
org.apache.ws.axis.security.WSDoAllReceiver:
- modify the method invoke()
take the signers certificate from the ResultVector and verify its trust
- new method: boolean verifyTrust(X509Certificate)
implementation of the validation-algorithm described above
org.apache.ws.security.components.crypto.Crypto (and Merlin):
- new method: boolean validateCertPath(X509Certificate[] certs)
Uses the CertPath API to validate a certificate chain
- new method: String[] getAliasesForDN(String subjectDN)
Looks up all aliases for a given DN in the keystore
org.apache.ws.security.errors.properties:
- new error: certpath = Error during certPath validation: {0}
org.apache.ws.security.util.WSSecurityUtil:
- new method: fetchActionResult(Vector wsResultVector, int action)
Makes fetching results from the SecurityEngineResults more comfortable
The patches for those modifications are attached.
NOTE: The validation of the certificate path via CertPath API (in Merlin.validateCertPath())is still hardcoded to BC! This is because I was not able to avoid the following exception when not using BC classes directly:
java.security.NoSuchAlgorithmException: class configured for CertPathValidator: org.bouncycastle.jce.provider.PKIXCertPathValidatorSpi not a CertPathValidator
Any hint how to make this part provider-independent (just like the CertificateFactory) would be appreciated!
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (WSFX-6) Validation of the certificate that was used to sign the message
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Christof Soehngen (mailto:christof.soehngen@syracom.de)
Date: Thu, 13 May 2004 6:48 AM
Changes:
Attachment changed to Crypto.java.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/WSFX-6?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/WSFX-6
Here is an overview of the issue:
---------------------------------------------------------------------
Key: WSFX-6
Summary: Validation of the certificate that was used to sign the message
Type: New Feature
Status: Unassigned
Priority: Major
Project: WSFX
Components:
WSS4J
Assignee:
Reporter: Christof Soehngen
Created: Thu, 13 May 2004 6:47 AM
Updated: Thu, 13 May 2004 6:48 AM
Environment: CVS snapshot from 2004/13/05
Description:
Here is my proposal for a validation of the certificate that was used to sign the message.
This validation could be used for authorization: Accept only messages that were signed by a trusted certificate. Trust is assigned by installing the certificate itself or the certificates issuer in the local keystore (based on the #X509v3 ValueType that allows only one certificate to be transmitted).
The architecture of WSS4J should allow subclasses of WSDoAllReceiver to replace the default behaviour with custom validation algorithms.
To achieve these goals (implementation of the validation-algorithm described above and hook for custom algorithms) the following modifications should to be made:
org.apache.ws.axis.security.WSDoAllReceiver:
- modify the method invoke()
take the signers certificate from the ResultVector and verify its trust
- new method: boolean verifyTrust(X509Certificate)
implementation of the validation-algorithm described above
org.apache.ws.security.components.crypto.Crypto (and Merlin):
- new method: boolean validateCertPath(X509Certificate[] certs)
Uses the CertPath API to validate a certificate chain
- new method: String[] getAliasesForDN(String subjectDN)
Looks up all aliases for a given DN in the keystore
org.apache.ws.security.errors.properties:
- new error: certpath = Error during certPath validation: {0}
org.apache.ws.security.util.WSSecurityUtil:
- new method: fetchActionResult(Vector wsResultVector, int action)
Makes fetching results from the SecurityEngineResults more comfortable
The patches for those modifications are attached.
NOTE: The validation of the certificate path via CertPath API (in Merlin.validateCertPath())is still hardcoded to BC! This is because I was not able to avoid the following exception when not using BC classes directly:
java.security.NoSuchAlgorithmException: class configured for CertPathValidator: org.bouncycastle.jce.provider.PKIXCertPathValidatorSpi not a CertPathValidator
Any hint how to make this part provider-independent (just like the CertificateFactory) would be appreciated!
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (WSFX-6) Validation of the certificate that was used to sign the message
Posted by ji...@apache.org.
The following issue has been updated:
Updater: Christof Soehngen (mailto:christof.soehngen@syracom.de)
Date: Thu, 13 May 2004 6:47 AM
Changes:
Attachment changed to WSDoAllReceiver.java.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/WSFX-6?page=history
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/WSFX-6
Here is an overview of the issue:
---------------------------------------------------------------------
Key: WSFX-6
Summary: Validation of the certificate that was used to sign the message
Type: New Feature
Status: Unassigned
Priority: Major
Project: WSFX
Components:
WSS4J
Assignee:
Reporter: Christof Soehngen
Created: Thu, 13 May 2004 6:47 AM
Updated: Thu, 13 May 2004 6:47 AM
Environment: CVS snapshot from 2004/13/05
Description:
Here is my proposal for a validation of the certificate that was used to sign the message.
This validation could be used for authorization: Accept only messages that were signed by a trusted certificate. Trust is assigned by installing the certificate itself or the certificates issuer in the local keystore (based on the #X509v3 ValueType that allows only one certificate to be transmitted).
The architecture of WSS4J should allow subclasses of WSDoAllReceiver to replace the default behaviour with custom validation algorithms.
To achieve these goals (implementation of the validation-algorithm described above and hook for custom algorithms) the following modifications should to be made:
org.apache.ws.axis.security.WSDoAllReceiver:
- modify the method invoke()
take the signers certificate from the ResultVector and verify its trust
- new method: boolean verifyTrust(X509Certificate)
implementation of the validation-algorithm described above
org.apache.ws.security.components.crypto.Crypto (and Merlin):
- new method: boolean validateCertPath(X509Certificate[] certs)
Uses the CertPath API to validate a certificate chain
- new method: String[] getAliasesForDN(String subjectDN)
Looks up all aliases for a given DN in the keystore
org.apache.ws.security.errors.properties:
- new error: certpath = Error during certPath validation: {0}
org.apache.ws.security.util.WSSecurityUtil:
- new method: fetchActionResult(Vector wsResultVector, int action)
Makes fetching results from the SecurityEngineResults more comfortable
The patches for those modifications are attached.
NOTE: The validation of the certificate path via CertPath API (in Merlin.validateCertPath())is still hardcoded to BC! This is because I was not able to avoid the following exception when not using BC classes directly:
java.security.NoSuchAlgorithmException: class configured for CertPathValidator: org.bouncycastle.jce.provider.PKIXCertPathValidatorSpi not a CertPathValidator
Any hint how to make this part provider-independent (just like the CertificateFactory) would be appreciated!
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira