Name: bsC130419 Date: 06/22/2001


java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

A trusted anchor A with subject: CN=GTE CyberTrust Root, O=GTE Corporation, C=US

Two certificate chains
Chain 1: (3 certificates)
  certificate 1: subject: EmailAddress=###@###.###, CN=twF1266648311,
OU=eSecureRA, OU=TAIWAN-CA.COM Inc., O=Certification Service Provider -
  Evaluation Only, O=TaiCA Secure CA - Evaluation Only, C=TW
                 issuer: CN=TaiCA Secure CA - Evaluation Only, OU=Certification
Service Provider - Evaluation Only, O=TAIWAN-CA.COM Inc., C=TW
  certificate 2: subject: CN=TaiCA Secure CA - Evaluation Only,
OU=Certification Service Provider - Evaluation Only, O=TAIWAN-CA.COM Inc., C=TW
                 issuer: CN=GTE CyberTrust Root, O=GTE Corporation, C=US
  certificate 3: subject: CN=GTE CyberTrust Root, O=GTE Corporation, C=US
                 issuer: CN=GTE CyberTrust Root, O=GTE Corporation, C=US

Chain 2: (2 certificates)
  certificate 1: subject: EmailAddress=###@###.###, CN=twF1266648311,
OU=eSecureRA, OU=TAIWAN-CA.COM Inc., O=Certification Service Provider -
  Evaluation Only, O=TaiCA Secure CA - Evaluation Only, C=TW
                 issuer: CN=TaiCA Secure CA - Evaluation Only, OU=Certification
Service Provider - Evaluation Only, O=TAIWAN-CA.COM Inc., C=TW
  certificate 2: subject: CN=TaiCA Secure CA - Evaluation Only,
OU=Certification Service Provider - Evaluation Only, O=TAIWAN-CA.COM Inc., C=TW
                 issuer: CN=GTE CyberTrust Root, O=GTE Corporation, C=US

It was interesting Chain 2 could be verified via the class
java.security.cert.CertPathValidator with the trusted anchor A, but not Chain 1
just because the chain contained the trusted anchor. Note that the trusted
anchor A was a self-signed X.509v1 certificate.

In practice, most running CAs issue PKCS#7 certificate chain with certificates
starting from a most trusted anchor with its certificate also being included in
the chain. It makes no sense that security applications have to strip out the
trusted certificate from a chain to make CertPathValidator work.

The output from a test program showed up as:
scl: getPermissions ProtectionDomain (file:/C:/eSignX/source/ <no
certificates>)
 sun.misc.Launcher$AppClassLoader@310d42
 <no principals>
 java.security.Permissions@ed465 (
 (java.lang.RuntimePermission exitVM)
 (java.io.FilePermission \C:\eSignX\source\- read)
)


scl:
properties: reading security properties file: C:\Program Files\JavaSoft\JRE\1.4
\lib\security\java.security
PKIXParameters established.
CertPathCheckers: 0
CertPath established.
certpath: PKIXCertPathValidator.engineValidate()...
certpath: PKIXCertPathValidator.engineValidate() reversing certpath...
certpath: PKIXCertPathValidator.engineValidate() anchor.getTrustedCert() != null
certpath: anchor.getTrustedCert().getSubjectDN() = CN=GTE CyberTrust Root,
O=GTE Corporation, C=US
certpath: --------------------------------------------------------------
certpath: Executing PKIX certification path validation algorithm.
certpath: Checking cert1 ...
certpath: -Using checker1 ...
certpath: -checker1 validation succeeded
certpath: -Using checker2 ...
certpath: ---checking basic constraints...
certpath: prevPathLen = 3
certpath: currPathLen = -1
certpath: remainingCerts = 2
certpath: This is not the target
java.security.cert.CertPathValidatorException: basic constraints check failed:
this is not a CA certificate
at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate
(Unknown Source)
at sun.security.provider.certpath.PKIXCertPathValidator.doValidate
(Unknown Source)
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate
(Unknown Source)
at java.security.cert.CertPathValidator.validate(Unknown Source)
at TestCertPath.main(TestCertPath.java:58)
Exception in thread "main"
(Review ID: 127141)
======================================================================