Re: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-26 Thread Weijun Wang
On Tue, 26 Oct 2021 15:28:51 GMT, Sean Mullan wrote: >> I was asking if `getIssuerAlternativeNameExtension` can throw the exception >> if IAE exists but not parseable. > > Ok, I understand your comment now. I'm hesitant to change those methods to > throw an exception because to be consistent

Re: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-26 Thread Sean Mullan
On Mon, 25 Oct 2021 23:48:35 GMT, Weijun Wang wrote: >> Unless I am misunderstanding your comment, I don't think this is an issue in >> practice. The code inside the `X509CertImpl.getExtension` method only throws >> an Exception if invalid OIDs or attribute names are passed to the internal >>

Re: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-25 Thread Weijun Wang
On Mon, 25 Oct 2021 20:17:17 GMT, Sean Mullan wrote: >> That's probably a little deeper and changing it will have a mass effect. >> What about at the `getIssuerAlternativeNameExtension` level? > > Unless I am misunderstanding your comment, I don't think this is an issue in > practice. The code

Re: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-25 Thread Sean Mullan
On Mon, 25 Oct 2021 18:29:34 GMT, Weijun Wang wrote: >> To clarify, do you mean this code in `getExtension(ObjectIdentifier)` that >> swallows the exception?: >> >> >> } catch (IOException ioe) { >> return null; >> } > > That's probably a little deeper and changing

Re: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-25 Thread Weijun Wang
On Mon, 25 Oct 2021 15:13:25 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 1618: >> >>> 1616: } >>> 1617: SubjectAlternativeNameExtension subjectAltNameExt = >>> 1618: getSubjectAlternativeNameExtension(); >> >> Does

Re: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-25 Thread Sean Mullan
On Mon, 25 Oct 2021 14:17:56 GMT, Weijun Wang wrote: >> The JDK implementation (as supplied by the "SUN" provider) of >> `X509Certificate::getSubjectAlternativeNames` and >> `X509Certificate::getIssuerAlternativeNames` returns `null` instead of >> throwing a `CertificateParsingException` when

Re: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-25 Thread Sean Mullan
On Mon, 25 Oct 2021 14:20:08 GMT, Weijun Wang wrote: > How about other `X509Certificate` methods that get info of an extension? Good question. There are 3: `getBasicConstraints`, `getKeyUsage` and `getExtendedKeyUsage`. The first two methods are not specified to throw an Exception, so that

Re: RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-25 Thread Weijun Wang
On Mon, 25 Oct 2021 12:53:43 GMT, Sean Mullan wrote: > The JDK implementation (as supplied by the "SUN" provider) of > `X509Certificate::getSubjectAlternativeNames` and > `X509Certificate::getIssuerAlternativeNames` returns `null` instead of > throwing a `CertificateParsingException` when the

RFR: 8251468: X509Certificate.get{Subject, Issuer}AlternativeNames does not throw CertificateParsingException if extension is unparseable

2021-10-25 Thread Sean Mullan
The JDK implementation (as supplied by the "SUN" provider) of `X509Certificate::getSubjectAlternativeNames` and `X509Certificate::getIssuerAlternativeNames` returns `null` instead of throwing a `CertificateParsingException` when the extension is unparseable. This fix changes the behavior to