1008133 - mozilla::pkix does not canonicalize names when matching names during path building

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[jan.gyselinck]

User Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130818084258

Steps to reproduce:

Connect to https://ocpcheck2.cmtest.omniroot.com


Actual results:

A message appears: This Connection Is Untrusted

Technical details: ocpcheck2.cmtest.omniroot.com uses an invalid security certificate.  The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer)

When proceeding to add an exception, one can look up the certificate chain.  This only returns 2 certificates:
- Verizon Global Issuing CA
- ocpcheck2.cmtest.omniroot.com

The server provides the full chain (2 additional certificates) but the browser doesn't accept it.

Testing with OpenSSL shows no issues.  





Expected results:

Firefox should have connected to the site without any issues.

Comment 1

[ricardosaul25]

URL: https://ocpcheck2.cmtest.omniroot.com/
OS: Windows 8.1 x64
FF: 29.0.1

Firefox says the connection is untrusted.

Comment 2

[Camilo Viecco (:cviecco)]

The issue is that the CN for verizon global root ca(C=US/O=Verizon Business/OU=OmniRoot/CN=Verizon Global Root CA) as signed by baltimore is a PrintableString "Verizon Global Root CA", while the issuer of Verizon Global Issuing CA (C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Global Issuing CA) is a UTF8String.

Whether this is the correct behavior, I am unsure right now (rereading rfcs)

Comment 3

[Camilo Viecco (:cviecco)]

NSS behavior is correct according to RFC 5280 and 3280 (deprecated by 5280) 

From 5280 section 7.1: (http://tools.ietf.org/html/rfc5280#section-7.1):
"
   Two naming attributes match if the attribute types are the same and
   the values of the attributes are an exact match after processing with
   the string preparation algorithm. 
"

This is not a firefox/nss bug. The set of certs exposes a bug in name processing for openssl and a issuance of a certificate by Verizon with a matching key but a mismatching cert.

Comment 4

[Camilo Viecco (:cviecco)]

OK So I might have closed this too soon. Please answer back if you think my analysis is incorrect.

Comment 5

[Kaspar]

(In reply to Camilo Viecco (:cviecco) from comment #3)
>    the values of the attributes are an exact match after processing with
>    the string preparation algorithm. 

The essential point here is *after processing with the string preparation algorithm*. Specifically, this means the StringPrep profile from RFC 4518, whose first step is "Transcode":

   Each non-Unicode string value is transcoded to Unicode.

   PrintableString [X.680] values are transcoded directly to Unicode.

> This is not a firefox/nss bug.

It is an incomplete implementation of RFC 5280, which requires:

   Conforming implementations MUST use the LDAP StringPrep profile
   (including insignificant space handling), as specified in [RFC4518],
   as the basis for comparison of distinguished name attributes encoded
   in either PrintableString or UTF8String.

(see also bug 556792 comment 12 and bug 556792 comment 15 for more background)

Comment 6

[jan.gyselinck]

Impressive debugging, guys, thank you!  Wouldn't have found the issue without your help.  We've recreated one of the intermediate certs so the encoding now matches.  Note that Chrome didn't like it either.  So, we'll make sure to have matching encodings from our side.  I'll leave it up to you guys if you want to keep this bugzilla open or not.

Note that you cannot test anymore using https://ocpcheck2.cmtest.omniroot.com as we've deployed the chain with the fixed certificate on there.

Comment 7

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kaspar Brand from comment #5)
> The essential point here is *after processing with the string preparation
> algorithm*. Specifically, this means the StringPrep profile from RFC 4518,
> whose first step is "Transcode":
> 
>    Each non-Unicode string value is transcoded to Unicode.
> 
>    PrintableString [X.680] values are transcoded directly to Unicode.
> 
> > This is not a firefox/nss bug.
> 
> It is an incomplete implementation of RFC 5280, which requires:
> 
>    Conforming implementations MUST use the LDAP StringPrep profile
>    (including insignificant space handling), as specified in [RFC4518],
>    as the basis for comparison of distinguished name attributes encoded
>    in either PrintableString or UTF8String.
> 
> (see also bug 556792 comment 12 and bug 556792 comment 15 for more
> background)

RFC 5280 also says (at https://tools.ietf.org/html/rfc5280#section-4.1.2.6):

           When the subject of the certificate is a CA, the subject
           field MUST be encoded in the same way as it is encoded in the
           issuer field (Section 4.1.2.4) in all certificates issued by
           the subject CA.  Thus, if the subject CA encodes attributes
           in the issuer fields of certificates that it issues using the
           TeletexString, BMPString, or UniversalString encodings, then
           the subject field of certificates issued to that CA MUST use
           the same encoding.

Thus, mozilla::pkix, NSS, and the CA here are all non-conformant.

This is not a regression because NSS matches names the same way as mozilla::pkix does.

Whether or not we should start doing stringprep is something that we should continue to debate. My personal opinion is that the WebPKI X.509 profile should require all names within a certificate to be normalized and that it should remove the requirement for stringprep to be done during validation--that is, we should consider the mozilla::pkix and NSS behavior to be conformant to the WebPKI profile.

Comment 8

[Kaspar]

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #7)
> RFC 5280 also says (at https://tools.ietf.org/html/rfc5280#section-4.1.2.6):
> 
>            When the subject of the certificate is a CA, the subject
>            field MUST be encoded in the same way as it is encoded in the
>            issuer field (Section 4.1.2.4) in all certificates issued by
>            the subject CA.  Thus, if the subject CA encodes attributes
>            in the issuer fields of certificates that it issues using the
>            TeletexString, BMPString, or UniversalString encodings, then
>            the subject field of certificates issued to that CA MUST use
>            the same encoding.

That's a pretty misleading extract of section 4.1.2.6 of RFC 5280. What is equally important are the three preceding lines in said section:

>    When encoding attribute values of type DirectoryString, conforming
>    CAs MUST use PrintableString or UTF8String encoding, with the
>    following exceptions:
>
>       (a)  

The snippet you quoted just applies to the case of TeletexString, BMPString, or UniversalString encodings - i.e., to maintain compatibility with legacy end-entity certificates which do not meet the "MUST use PrintableString or UTF8String encoding" which was introduced with RFC 5280.

> Thus, mozilla::pkix, NSS, and the CA here are all non-conformant.

The former two yes, the latter not.

Comment 9

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I am leaning towards resolving this as INVALID (i.e. "Works as intended"). The extra complication, and the associated security risk that comes from it, are not justified, considering that we've not had any compatibility issues with the current simpler behavior that weren't easy to resolve by regenerating the certificates. I'll leave this bug open for a while so people who disagree can make the case for this. A list of websites with certificates that do not validate correctly due to this bug would be part of a good argument, for example.

Comment 11

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I still agree with comment 9, so resolving as INVALID.