1625527 - NSS doesn't send whole client certificate chain when issuer and subject have different datatypes (PrintableString, UTF8String)

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Sharath Kapilavai]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Steps to reproduce:

Browser version: ESR 52.8.0.
In the Issuer DN of a certificate the data type of organization & organization unit fields is PrintableString and the subject dn of its issuer, data type of same fields is UTF8String. This is acceptable according to RFC-5280 Section-4.1.2.6 exceptions. But Firefox skips these certificates during exchange with server

Actual results:

Browser is ignoring these two certificates during exchange with server. Other intermediate and user certificates are shared properly

Expected results:

Irrespective of the datatype used for issuer and subject, all certificates should be shared by browser.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Dana Keeler (she/her) [:keeler]]

RFC 5280 section 4.1.2.6.a says:

           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.

which to my understanding explicitly forbids what you're describing. Am I misunderstanding what you're saying?

Comment 3

[Sharath Kapilavai]

The quote that is referred (from 4.1.2.6.a) above is under "exception".

When encoding attribute values of type DirectoryString, conforming CAs MUST use PrintableString or UTF8String encoding, with the
following exceptions:
(a) 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

So, I assume that the SSL libraries should be able to handle this scenario may be by converting them into a common format? If my interpretation of the above is not correct then I am ready to be corrected.

Thanks
Sharath

Comment 4

[Dana Keeler (she/her) [:keeler]]

My interpretation is that whole section is saying "CAs MUST use PrintableString or UTF8String. However, there are some cases where this isn't possible. For example, because the encoding of the subject distinguished name MUST match the encoding of the issuer distinguished name, if the subject DN already uses another encoding (i.e. not PrintableString or UTF8String), the issuer DN MUST use that same encoding."

The requirement that the encodings match is restated more clearly in section 8:

   CAs MUST encode the distinguished name in the subject field of a CA
   certificate identically to the distinguished name in the issuer field
   in certificates issued by that CA.

Comment 5

[Sharath Kapilavai]

Looks like you are right. Was going through some sections of RFC again & I could see what you stated above + the following.

"Inconsistent application of name comparison rules can result in acceptance of invalid X.509 certification paths or rejection of valid
ones." The X.500 series of specifications defines rules for comparing distinguished names that require comparison of strings without regard
to case, character set, multi-character white space substring, or leading and trailing white space. "This specification relaxes these requirements, requiring support for binary comparison at a minimum."

I am awaiting a confirmation from the security experts in my team. I may close this as invalid soon.
Thanks Dana for your prompt answers and pointing me to the right sections in RFC.
Regards
Sharath

Comment 6

[Sharath Kapilavai]

Hi Again,
Sorry for coming back on this. From section 7, does the following text say that there should be a common way of decoding either PrintableString or UTF-8?
"Conforming implementations MUST support UTF8String and PrintableString. RFC 3280 required only binary comparison of attribute values encoded in UTF8String, however, this specification requires a more comprehensive handling of comparison...."
"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."

I am a bit confused again on the fact that the above is applicable across subject and issuer(the reason for raising this issue) or a mix of Printable & UTF8 across various fields in one one of the attribute like subject or issuer?

Regards
Sharath

Comment 7

[Dana Keeler (she/her) [:keeler]]

I think that's referring to comparing distinguished names in the context of name constraints. Issuer/subject distinguished names should really use the same encodings. Is this an issue you're only seeing in Firefox?

Comment 8

[Sharath Kapilavai]

Hi,
The problem is seen with Openssl but fixed in some recent release of curl, which I think 7.19.x.
I can try checking other browsers and get back.
Thanks & Regards
Sharath

Comment 9

[Sharath Kapilavai]

Hi,
The environment that we have is RHEL 6 and there is no access to any other browser. I tried to reproduce the issue locally but couldn't sign the certificates with different formats. Tried using the ones from production environment but cannot import them into my keystore with openssl. Tried it for a couple of day and it is not going anywhere. I am sorry but I couldn't answer the question on other browsers' behavior now.
Any other suggestions on reproducing the issue locally on a laptop will be much appreciated.

Does firefox use NSS libraries for TLS communication? And is it by design that the difference in types is not considered in certificate parsing or validation? Do you see a possibility of addressing this issue?

Regards
Sharath

Comment 10

[Sharath Kapilavai]

Hi there,
I could finally setup the environment on my laptop and could reproduce the issue. The certificate chain is as below: External CA used PrintableString for Organization to issue Internal Root CA. It means that for Intermediate CA1's issuer has a different format compared to subject of Internal Root CA.

External Root CA
|-----Internal Root CA
|-----Intermediate CA1
|-----Intermediate CA2
|-----client certificate

I could see that firefox (74.0 64-bit) is ignoring External Root CA & Internal Root CA and sending the remaining 3. But Chrome (Version 80.0.3987.149 )(Official Build) sends all 4 certificates (including Internal Root CA) except External Root CA. I think it is ok to ignore the External Root CA.
So, could you get back if this can be addressed?
Regards
Sharath

Comment 11

[Dana Keeler (she/her) [:keeler]]

I misunderstood - this is an NSS issue.

Comment 12

[Sharath Kapilavai]

Hi Dana,

Can I ask you a couple of questions please? As you agree that the issue is with NSS (I raised this my earlier comment, "does firefox use NSS libraries for TLS communication? And is it by design that the difference in types is not considered in certificate parsing or validation?" ),

1. can you please elaborate the problem in NSS?
2. can you please explain if the RFC5280 is mis-interpreted from our previous discussions? If so which section is mis-interpreted?
3. May I get any planned fixed date?

Regards
Sharath

Comment 13

[Ryan Sleevi]

If Chrome is allowing this, then that's a bug I can see about fixing in Chrome. Killing off string normalization in Chrome has been something we've been trying to do, and done on most of our platforms, so I'm betting it's probably only on Windows this works anymore.

NSS does not implement RFC 5280. Its implementation is closer aligned with RFC 3280, although quite a bit of the code dates to earlier (RFC 2459). Strict adherence to 5280 is not necessarily a project goal either; elements such as supporting LDAP StringPrep bring with them a host of complexities and dependencies that are not otherwise needed in a common Internet client.

As Dana mentioned, the certificates themselves don't comport to the 3280/5280 rules. I can understand the argument that clients should handle if the certificates don't, but that's not a position widely held anymore.

Dana/JC: I'm definitely the hard-liner here, so I'm inclined to WontFix with prejudice :) I think the most sympathetic voice would be Bob.

The relevant NSS function is going to be https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/cmpcert.c#25 which compares by SECITEM rather than using CERT_CompareName. That's how we found that CERT_CompareName security issue way back when. Chrome's implementation of this, on Linux, similarly compares by name, while our macOS and Windows implementations using entirely different implementations. Only Chrome/Windows supports STRINGPREP, and that's only because it's "free" because Windows ships a full LDAP client.

Comment 14

[Dana Keeler (she/her) [:keeler]]

Thanks for the input! My vote would also be for wontfix.

Comment 15

[J.C. Jones [:jcj] (he/they)]

Thanks for all weighing in here, Ryan, Dana.

I agree also to WONTFIX this - I am sorry, Sharath.

Normalizing strings for cert matching leads to all kinds of unintended consequences, some of which have security and availability implications - like selecting lookalike certificates during pathbuilding.

Ultimately, the Web PKI relies upon binary matching for X500 Name fields, even though LDAP permits more flexibility. This is a standard we hold all CAs to, and it would be prosecuted as mis-issuance to produce certificates that rely on normalization to match. Whenever possible, we recommend internal CAs rely on the same technical footing as the public CAs, and do so in this case as well.

Comment 16

[Sharath Kapilavai]

Appreciate your prompt response on the issue everytime. Thanks everyone.
Regards
Sharath