Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Aug 2013 15:05:48 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
Subject: X.509 name constraints and potential interpretation conflict

NSS CA roots are widely reused, but the implementation deviates from RFC 
5280 in such a way that NSS can safely accept additional root 
certificates as long as they have name constraints.  I think this is a 
bug in RFC 5280, and the fix in NSS is sound, but it could still result 
in surprising behavior if the root store is used unfiltered with TLS 
implementations that lack this bug fix.

For reference, here is the RFC 5280 errata I submitted:

--------------------------------------
Type: Technical
Reported by: Florian Weimer <fweimer@...hat.com>

Section: 4.2.1.10

Original Text
-------------
    DNS name restrictions are expressed as host.example.com.  Any DNS
    name that can be constructed by simply adding zero or more labels to
    the left-hand side of the name satisfies the name constraint.  For
    example, www.host.example.com would satisfy the constraint but
    host1.example.com would not.


Corrected Text
--------------
[Add this to the paragraph]

    If an implementation extracts DNS names from the subject
    distinguished name, DNS name restrictions MUST be applied
    to these names as well.


Notes
-----
When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, 
Name Constraints, is technically a NOP that doesn't constraint the CA 
that has this attribute because RFC 2818 mandates processing of the 
common name attribute in the subject distinguished name. 
Consequentially, the constraint can be bypassed by issuing a certificate 
without a subject alternative name.  The fix is to apply the DNS name 
restrictions to the relevant parts of the subject distinguished name, 
too, as implemented here:

https://bugzilla.mozilla.org/show_bug.cgi?id=394919

-- 
Florian Weimer / Red Hat Product Security Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.