JDK-4531698 : PKIX CertPathBuilder shouldn't require subject DN of targetConstraints to be set
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 1.4.0
  • Priority: P5
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_7
  • CPU: generic
  • Submitted: 2001-11-27
  • Updated: 2002-12-03
  • Resolved: 2002-09-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
Relates :  
Description
###@###.### 2001-11-27

Sun's implementation of PKIX CertPathBuilder currently requires that the
targetConstraints parameter of a PKIXBuilderParameters object be an
instance of X509CertSelector and the subject criterion be non-null. There
is no good reason for the second condition to be required. For example,
the target certificate can be found in a CollectionCertSore 
by setting just the issuer & serialNumber criteria. This restriction
should be removed, and the following enhancements should be made:

1) If a user specifies target constraints using an X509CertSelector with a non-null certificateEquals criterion, the Sun PKIX CertPathBuilder implementation should not search any specified CertStores for the target certificate, since it has it already!

  Ex:

  X509CertSelector sel = new X509CertSelector();
  sel.setCertificate(targetCertificate);
  PKIXBuilderParameters params = new PKIXBuilderParameters(anchors, sel);
  CertPathBuilder builder = CertPathBuilder.getInstance("PKIX");
  CertPath cp = builder.build(params);

2) It would be nice if our LDAPCertStore.getCertificates() implementation 
  was enhanced to 
  find certificates when the specified X509CertSelector contains a
  subjectAlternativeName criterion with an RFC822 email address (and a
  null subject criterion). The
  implementation should search the directory for
  DN entries containing the "mail" attribute with the specified RFC822 email
  address and then return certificates in that entry with SubjectAltName   
  extensions containing the
  specified email address. This would be especially useful for S/MIME  
  applications, and would
  allow the CertPathBuilder to build a path to a target certificate when
  the subject's email address, but not the subject DN is known. This is
  a common usage case in S/MIME when the relying party wants to send an
  encrypted email to someone but doesn't have their certificate and 
  only knows their email address.

3) The reverse builder uses the target subject name for deciding
which certificates are most promising and ensuring that prospective CA
certificates don't contain name constraints that would prohibit the
desired target subject. This optimization should be done only if a 
non-null subject DN is set. (I think it is simply a matter of checking
if selector.getSubjectAsBytes() == null in ReverseBuilder.java)

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b03 VERIFIED IN: mantis-beta
14-06-2004

EVALUATION Targeted for fix in Mantis. ###@###.### 2002-05-17 (1) has been fixed (2) has been resubmitted as a separate RFE 4731456. (3) is no longer an issue, since we always have a unique subject name and it is parsed when set in X509CertSelector. However, once 4731456 is implemented we may no longer have a unique subject name and this may become an issue. ###@###.### 2002-08-14
14-08-2002