Since I'm not sure I got this right, I've chosen to write it here instead of creating a jira.
When using "useReqSigCert" I thought I didn't need to have a keystore for the encryption since it should come from/be found in processing the signature in the request. I've found out that if I don't provide a "encryptionPropFile" I get an error, so I've tried a dummy one, and it works. I'm not really sure if it's needed. When verifying a signature what should the keystore contain? If the message use DirectReference the certificate is in the message, and the keystore isn't needed, unless to do certificate path validation, but that isn't enabled right?. Whereas if it's one of the other identifier types the public key is needed from the keystore, and possibly also the trusted root certificate(s). So in this scenario the need for a keystore for validation depends on how the certificate is referenced. If this is true, there should not be a need for a keystore for the encryption when using "useReqSigCert". During my experiments with WSE 2.0 interop I've found out that WSE always uses/wants DirectReference for signatures and SubjectKeyIdentifier for encryption (shouldn't it be "SubjectKeyIdentifier" instead of "SKIKeyIdentifier"). Given this subset of the wss-standard it's more simple, as to what is needed in the verification/"useReqSigCert"-encryption. Have I got this right, and should it be possible to leave out the "signaturePropFile"/"encryptionPropFile" in this scenario? Regards Brian
