[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 61574] New: mod_ssl RFC: change uniqueness logic for SSLCADNRequest*


            Bug ID: 61574
           Summary: mod_ssl RFC: change uniqueness logic for
           Product: Apache httpd-2
           Version: 2.5-HEAD
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_ssl
          Assignee: bugs@xxxxxxxxxxxxxxxx
          Reporter: jorton@xxxxxxxxxx
  Target Milestone: ---

Created attachment 35387
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=35387&action=edit
PoC using non-canonical name comparison in SSLCARequestDN*

We've hit an unusual case with a public CA which has issued two intermediate
certificates used for issuing client certificates, where the subject names of
the intermediate CAs only differ in the case of one character of the Subject DN
(i.e. one has lower case, the other upper case).

OpenSSL treats these names as identical - it canonicalizes names internally
(lower case, removing whitespace), and X509_NAME_cmp() compares as equal. 
Other TLS implementations do not treat them as equal.

While the name comparison rules in
https://tools.ietf.org/html/rfc3280#section- are clear, the rules in
https://tools.ietf.org/html/rfc5280#section-7.1 are more ambiguous, with
language like "Conforming implementations MUST support name comparisons using
caseIgnoreMatch" not explicit.  Anyway, the CA apparently thinks this practice
is acceptable.

One way to work around this is in mod_ssl is to change the behaviour of
SSLCARequestDN* to avoid OpenSSL's standard (canonical) name comparison and
rely on a bitwise DN comparison.

On one hand, few people need to use that directive, and the behaviour change
should make no difference to 99.999% of them, so there should be little
downside.  On the other hand, this forces unnecessary complexity into mod_ssl
for a borderline standards violation.

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail: bugs-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: bugs-help@xxxxxxxxxxxxxxxx