Colm O hEigeartaigh commented on WSS-611:

Thanks for the PR. Could you separate out the CertificateStore changes into a 
separate JIRA/PR? I will then be able to easily apply the fix to 2.1.x, whereas 
the NameConstraint stuff will stay on 2.2.x, as it changes the CryptoBase API. 
In the tests that you added, you could use try-with-resources to load the 
InputStreams, instead of using finally to close the stream.

> CAs with the NameConstraint extension cause exceptions when verifying trust
> ---------------------------------------------------------------------------
>                 Key: WSS-611
>                 URL: https://issues.apache.org/jira/browse/WSS-611
>             Project: WSS4J
>          Issue Type: Bug
>          Components: WSS4J Core
>    Affects Versions: 2.1.10
>            Reporter: Richard Porter
>            Assignee: Colm O hEigeartaigh
>             Fix For: 2.2.0
> When a CA with NameConstraints is in the truststore, it causes a failure with 
> any crypto Cert provider. The underlying cause is an 
> {{IllegalArgumentException}} thrown because the Sequence data has been 
> encoded as an Octet String and it is not being correctly decoded.
> While the relevant RFCs are a bit ambiguous with regard to extensions and 
> whether they are all encoded as Octet Strings or not, the documentation on 
> Java's implementation of 
> [X509Extension|https://docs.oracle.com/javase/8/docs/api/java/security/cert/X509Extension.html#getExtensionValue-java.lang.String-]
>  are unambiguous: it will be a "DER-encoded OCTET string for the extension 
> value.
> Beneath this issue lies another, the fact that the Sun default implementation 
> of PKIX path validation does not support TrustAnchors with NameConstraints 
> attached. So fixing the first issue also requires conditionally constructing 
> TrustAnchors with NameConstraints or with null.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@ws.apache.org
For additional commands, e-mail: dev-h...@ws.apache.org

Reply via email to