[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    [jira] [Comment Edited] (WSS-611) CAs with the NameConstraint extension cause exceptions when verify
From:       "Colm O hEigeartaigh (JIRA)" <jira () apache ! org>
Date:       2017-08-08 16:49:01
Message-ID: JIRA.13092301.1501793105000.118809.1502210941077 () Atlassian ! JIRA
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/WSS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16118613#comment-16118613 \
] 

Colm O hEigeartaigh edited comment on WSS-611 at 8/8/17 4:48 PM:
-----------------------------------------------------------------

Thanks for the PR. Could you separate out the CertificateStore changes into a \
separate JIRA/PR? In the tests that you added, you could use try-with-resources to \
load the InputStreams, instead of using finally to close the stream.


was (Author: coheigea):
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
(v6.4.14#64029)

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


[prev in list] [next in list] [prev in thread] [next in thread]