Open Bug 386871 Opened 12 years ago Updated 7 years ago
match cert name attributes with different character encodings
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20070510 Iceape/1.0.9 (Debian-1.0.9-0etch1) Build Identifier: Some background on this appeared at https://bugzilla.mozilla.org/show_bug.cgi?id=245609 , but the issue is a different bug than the original, so I'm reporting this here. When an https server sends a certificate with the complete certificate_list, but some name components are presented with different charsets, the browser is unable to see the complete chain, and acts as if the chain is broken. RFC 4630 says: Since name comparison assumes that attribute values encoded in different types (e.g., PrintableString and UTF8String) are assumed to represent different strings, any name components that appear in both the subject field and the issuer field SHOULD use the same encoding throughout the certification path. The bug here is that Mozilla is acting as if the "SHOULD" was a "MUST", thus considering the chain broken. Since it is a SHOULD, the browser has to see the complete chain and present the certificate as valid. An example when this happens is presented. BTW, as an "extra incentive", there's a 1000€ reward to whomever fixes this bug: http://mv.asterisco.pt/cat.cgi?1000%20Euro%20Firefox%20Bounty Reproducible: Always Steps to Reproduce: 1. Go with a Mozilla browser to https://private.eu2007.pt/ Actual Results: A message telling that the chain is broken appears Expected Results: The browser should see that the certificate is valid.
By now, even a quick look at the code will show that PrintableString was planned to be converted but isnt/wasnt and that FF is lacking in relation to other browsers. http://lxr.mozilla.org/mozilla1.8/source/security/nss/lib/certdb/secname.c#606 -- MV
The IETF's thinking about the treatment of cert name attributes has been evolving. RFC 3280 said "attribute values encoded in different types (e.g., PrintableString and BMPString) MAY be assumed to represent different strings". But RFC 4630, which is an update to RFC 3280, now says "attribute values encoded in different types (e.g., PrintableString and UTF8String) *are assumed* to represent different strings". More comments to follow.
Assignee: dveditz → nobody
Component: Security → Libraries
Product: Core → NSS
QA Contact: toolkit → libraries
Summary: when the name bad behaviour when cert's name components use different character encodings → cert name attributes with different character encodings do not match
Version: unspecified → 3.0
RFC 3280 said "all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString", and suggested the use of "name rollover" certificates to facilitate the transition. "name rollover" certificates are intermediate CA certificates with "the CA's UTF8String encoded name as issuer and and the old name encoding as subject, or vice-versa." But RFC 4630 changes that UTF8String requirement, specifically to eliminate the need for name rollover certificates. It says: CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString, with one exception. When CAs have previously issued certificates with issuer fields with attributes encoded using the TeletexString, BMPString, or UniversalString, the CA MAY continue to use these encodings of the DirectoryString to preserve the backward compatibility. The issue is not merely one of being able to compare two certificates' names for equality, but also includes the much larger problem of being able to search for a certificate with a name that doesn't quite match. The solution involves translating all DNs' attributes into a canonical type, and indexing databases with that canonical form of the DN. This is no small undertaking, and is not required for compliance with either RFC 3280 or RFC 4630. So, I am turning this into a request for enhancement, asking that NSS be enhanced to match AND FIND cert names with different character encodings of attributes. Note that the PKCS#11 API, which facilitates searches for certificates by DN, does not perform any such canonicalization. I believe it would be necessary to introduce such canonicalization into the API definition to accomplish the desired change. There is a trivial solution to this Portugese CA's dilemma, one that should cost much less than 1000€, and can be done unilaterally by the CA without any changes to any browsers. Can you guess what it is?
Severity: normal → enhancement
Summary: cert name attributes with different character encodings do not match → match cert name attributes with different character encodings
(In reply to comment #3) > There is a trivial solution to this Portugese CA's dilemma, one that > should cost much less than 1000€, and can be done unilaterally by the CA > without any changes to any browsers. Can you guess what it is? Add a correct signature to this one here...? ("fill in the blanks") -----BEGIN CERTIFICATE----- MIIFDDCCAvSgAwIBAgIQc6JDhZgH+D9EqSk0eISKSTANBgkqhkiG9w0BAQUFADAz MQswCQYDVQQGEwJQVDENMAsGA1UEChMEU0NFRTEVMBMGA1UEAxMMRUNSYWl6RXN0 YWRvMB4XDTA2MDcwMzE0MjcwMFoXDTE4MDYyMzA4NDk0N1owPjELMAkGA1UEBhMC UFQxDTALBgNVBAoMBFNDRUUxETAPBgNVBAsMCEVDRXN0YWRvMQ0wCwYDVQQDDARF Q0NFMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzR3ZwOJ4zV8fbHZM PjUbQ0cBnpj3J6PUqHrGM6yCY/gbbeqF20zDYoy/UnK5BNbPleEAarWtSeqvkQs/ O372C6WarjloKuClpgTju+uWBgKL4p0YJyqJNDzal16k6nYhaRPIR4/3LKqtIeOk Tb8yxMjA6TsriZiRarl4JgTl1EAru76Bgrw+5LmYTN6qRzykma/KkX0sD78BEfI/ gpotfuMbS29rJD3D7bn+rvQQyXMxDXy6vBpxT/oQ+bfV7VJTgd+aNqQu/xJQIHEN n3/9TVSb8TZnNGzlt6g3MvBkj9gH+VXDU4kdCkj+lyLmKl7vTI77DWsbNyrPxmdp oti/fQIDAQABo4IBDzCCAQswDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUWQtm zPp7FphoDvZcAPO5remmOnQwHwYDVR0jBBgwFoAUcX813vV3cW0dEpzhkKS68KmD j4AwDgYDVR0PAQH/BAQDAgEGMDsGA1UdIAQ0MDIwMAYEVR0gADAoMCYGCCsGAQUF BwIBFhpodHRwOi8vd3d3LmVjZWUuZ292LnB0L2RwYzA0BggrBgEFBQcBAQQoMCYw JAYIKwYBBQUHMAGGGGh0dHBzOi8vb2NzcC5lY2VlLmdvdi5wdDA1BgNVHR8ELjAs MCqgKKAmhiRodHRwOi8vY3Jscy5lY2VlLmdvdi5wdC9jcmxzL0FSTC5jcmwwDQYJ KoZIhvcNAQEFBQADggIBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA -----END CERTIFICATE----- (Not sure if that's really much less than EUR 1000, though - depending on how many people you need for signing this...)
I don't get it... It works fine to me. Mozzila Firefox 18.104.22.168 :|
Filipe Polido: you probably already accepted the certificate permanently in the past and now firefox dont show the warning... just tested in 2 firefox 22.214.171.124 in different machines (linux and windows) and still gives the "unable to verify certificate" warning
(In reply to comment #3) > Note that the PKCS#11 API, which facilitates searches for certificates > by DN, does not perform any such canonicalization. I believe it would > be necessary to introduce such canonicalization into the API definition > to accomplish the desired change. Does the PKCS#11 spec. disallow canonicalization or just say nothing about it? > There is a trivial solution to this Portugese CA's dilemma, one that > should cost much less than 1000€, and can be done unilaterally by the CA > without any changes to any browsers. Can you guess what it is? Use a "name rollover" certificate? >
Mark, Re: comment 7, the PKCS#11 spec version 2.20 says the following about C_FindObjectsInit on page 152 : "pTemplate points to a search template that specifies the attribute values to match; ulCount is the number of attribute sin the search template. The matching criterion is an exact byte-for-byte match with all attributes in the templates."
Julien, Thanks for looking that PKCS#11 passage up for me. Mark, The problem is that there are two certs, both intermediate CA certs, that do not agree on the encoding of a name. Let's call them "Parent" and "child". The solution I had in mind was the issuance of a new cert for child. It would be exactly like the existing child cert except for these differences: - encoding of the issuer name - serial number - binary value of the Parent's signature There would be no need to revoke any certs. That "child" CA would simply have two valid certs for itself thereafter. The server would send a chain that included the new child cert instead of the old child cert.
Can somebody change the status of this bug from UNCONFIRMED?
Severity: enhancement → normal
No. Our position is that this behavior, while acknowledged, is not a bug. You would like NSS to do more than it is now doing, to go beyond the requirements of the standards, into the areas that are permitted but not required by the Internet standards. That is a request for enhancement. I am willing to confirm this as an enhancement request, but not as a bug.
I've tested this on 2 machines: 1 Windows Xp sp2; Firefox 126.96.36.199 2 Ubuntu Feisty; Firefox 188.8.131.52 both accepted the certificate, works fine on this version i guess.
Nelson: You're still looking to this issue as if the "SHOULD" was a "MUST" in RFC 4630 (see the original bug report). Nuno: The issue is not fixed yet. Maybe you accepted the certificate in the past?
I did not accept this certificate before, on either machine...
I just wanted to say that we had an EV Cert issued by Thawte today and encountered this issue. Cert works properly at least in IE 7.0 on both XP and Vista. Tested in Mozilla 184.108.40.206 and get the unable to verify the identity of the trusted site error. Followed Thawte's knowledge base and updated the root and intermediate certs on the server, but didn't matter. Got Thawte on the line and they pointed me here. So, my question is... your stance is that this is not a bug, rather a feature request. That you are following the RFCs and that this is an enhancement? What recourse do you suggest? As a financial institution, when users see cert errors, specifically with keywords like trusted they freak out. If I have thawte reissue the cert will that take care of it or is this a bug/enhancement that needs to come from Mozilla. If so, when can users expect to see it? Feel free to test at www.pioneertrustbank.com
(In reply to comment #15) > Followed Thawte's knowledge base and updated the root > and intermediate certs on the server, but didn't matter. Got Thawte on the > line and they pointed me here. It's most likely a false alarm, in your case. Thawte consistently encodes the RDNs in all certificates; however, it's issue with the chain your server sends, which is: thawte Extended Validation SSL CA \ www.pioneertrustbank.com This is fine for MSIE, since the Windows root cert store already includes the new "thawte Primary Root CA" (issued in November 2006, for the new EV certs), so MSIE will use this hierarchy: thawte Primary Root CA \ thawte Extended Validation SSL CA \ www.pioneertrustbank.com Mozilla (and other browsers, probably) do not yet include the "thawte Primary Root CA" from 2006, so Thawte issued another intermediate CA - which you can see by visiting https://www.thawte.com with Firefox, e.g.: Thawte Premium Server CA \ thawte Primary Root CA \ thawte Extended Validation SSL CA \ www.pioneertrustbank.com Since your server apparently runs IIS, the fact that the chain of your server does not include the "thawte Primary Root CA" intermediate is probably a side effect of the self-signed "thawte Primary Root CA" being present in your root cert store. Even if you added the additional intermediate cert (as per the instructions on Thawte's site), the Windows CryptoAPI will find a (shorter) path to the new "thawte Primary Root CA", so it will (correctly) use that one and omit the intermediate "thawte Primary Root CA". > What recourse do you suggest? Try to delete the self-signed version of the "thawte Primary Root CA" in the machine cert store of your server, make sure that the intermediate version is present (as explained at http://search.thawte.com/thawte/solution.jsp?id=vs40611) and restart IIS. That should do the trick. If someone from Thawte/Verisign is reading this, then I would recommend that an official representative files another bug for inclusion of the new "thawte Primary Root CA" in Mozilla's cert store (cf. http://www.mozilla.org/projects/security/certs/policy/).
Kaspar, Thanks very much for your research on pioneertrustbank's issue. It is indeed a server configuration issue, and will affect all browsers that do not have all the latest new EV root CA certs. The solution, as you have already explained, is to configure the server(s) with a certificate chain that is understood by all browsers, including older MSIE browsers, and not just by IE7. I regard it as a different issue than the issue presented by the original reporter of this RFE, for https://private.eu2007.pt/ Bug 398153 appears to be the same issue as the issue originally presented in this RFE. So, I agree that it is a duplciate of this RFE. Although X.509v3 explicitly allows Distinguished Names to be matched without regard for their character encodings, the Internet standards body (the IETF) has standardized on a subset (a so-called "profile") of X.509. That subset does not require that IETF standards compliant implementations match name attributes of different encodings. Let me say that again: the IETF RFC standards that govern the Internet do NOT require full X.509 name matching. Indeed the latest RFC for certificates says that name attributes of different encodings ARE ASSUMED to be different names. The IETF RFCs provide for the use of "name rollover" certificates, which are certificates that exist precisely to make the connection between two different encodings of a name. I will describe them below. There are several different possible solutions for each situation wherein the Issuer name in a subordiante cert (Call it "cert 1") uses a different encoding than the Subject Name in the issuer's CA cert ("cert 2"). Here are 3 of the many possible solutions: a) Reissue cert 1 to have an Issuer name with the same encoding as the Subject Name in cert 2. b) If cert 2 is itself an intermediate CA cert, issued by a third superior CA (call it "cert 3"), with a chain of (cert 1 -> cert 2 -> cert 3) then have the CA for cert 3 (the issuer of cert 2) reissue cert 2 with a Subject Name that matches the encoding in the Issuer name in cert 1. Note that this does not need to obsolete the original cert 2. The CA represented by cert 2 can now have two separate certs, with different encodings for its subject name, both of which are simultaneously valid. c) The CA whose cert is cert 2 can issue itself a "name rollover" cert. This is an intermediate CA cert whose Issuer name exactly matches the Subject Name encoded in cert 2, and whose Subject Name exactly matches the Issuer name in cert 1. This "name rollover" cert (call it "cert R") is put into the cert chain between cert 1 and cert 2, so that the chain appears to be (cert 1 -> cert R -> cert 2). Cert R can (should) have the same public key as in cert 2. With each of these possibilities, there are considerations for revocation, Subject Key ID (SKID) and Authority Key ID (AKID) extensions, and cert path length limits in various types of extensions, such as Basic Constraints. The full discussion of those considerations is beyond the scope of this bug comment. :)
Severity: normal → enhancement
Priority: -- → P4
Nelson, did I miss something? Per comment 3, we have a situation where a certificate chain that complies with the RFC in question is treated as invalid by NSS. Confirming, and I don't think this should be an enhancement, but that's not really my call to make...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Boris, I think you might have missed something. But I'm not sure what. Maybe the following text will help. None of the RFCs for certs has ever required conformant implementations to match names encoded with different encodings. RFC 3280 explicitly does not require implementations to match names with different encodings. Its successor, RFC 4630, goes farther and says that names with different encodings ARE ASSUMED to be different names. It doesn't forbid implementationsfrom attempting to match ignoring encoding, but it effectly tells issuers that IF they're going to use different encodings, they must use name rollover certs, or risk experiencing the very problem described here. RFC 3280 (published in 2002) required that all certs issued after the year 2003 MUST use a certain encoding (UTF8). That created a situation in which certs issued after 2003 would have a different encoding of names than certs issued before 2004. But that RFC did NOT add a requirement that conformant implementations must perform encoding-independent name matching. Instead, that RFC effectively required issuers to issue name rollover certs (certs that bridge the gap between the old encodings and the new one). The RFC even suggested/explained that rollover certs could be used for that purpose. Together, those requirements implied that rollover certs should have been issued before the year 2004, BTW. RFC 4630, published in 2006, rescinded the requirement that cert names use only UTF8 encoding, precisely so that certs could continue to use the same encodings as before 2004, and thereby obviate name rollover certs. In this case, the issuer issued at cert compliant with RFC 3280, using UTF8, but did not issue the name rollover cert. So, they've experienced the very problem that that RFC warned about, which was why the RFC suggested the use of name rollover certs. Most of the cert issuers in the world have understood all this stuff, and have avoided problems. A few have not, and as always, they ask us to change our software to work around it. This is no different than when authors of web sites whose content only works with IE ask us to change the browser to work with that content. You know how mozilla generally responds to requests like this. Think of this in the same way. I have no problem with this being an enhancement request (and I said that in comment 11), but I will resist any attempts to change this into a confirmed bug, because NSS is behaving as intended, per the RFC requirements. There are other standards that are also relevant. One of them is the standard for "modules" that store certificates, PKCS#11. It defines a certificate search facility that searches for certs by exact name match. It does not define a search facility that is insensitive to name encoding. NSS uses that standard API, as do most crypto hardware vendors in the world. Even NSS's own software certificate stores use that very API. At this point, changing that standard to provide encoding-insensitive name comparison, and getting the countless deployed products that use it to change would be a huge task. Given that the certs issued by the vast majority of issuers in the world do not necessitate this change, I doubt it will receive high priority.
I just read this news, so I never opened the site https://private.eu2007.pt/ So, I did open https://private.eu2007.pt/, it asks for accept or not the certificate. I chose "yes, temporary..", then it accepted and I am in, fully. To proof, I took a snapshot: http://img508.imageshack.us/img508/2528/nobugax2.jpg My system: - Windows XP sp2 - Firefox 220.127.116.11 - (windowblinds for skin).
Has anyone ever checked the chain of THE example page is correct? Please correct me where I was wrong: https://bugzilla.mozilla.org/show_bug.cgi?id=245609#c24
Do IE6 or IE7 on either WinXP or Vista accept this server's chain as valid?
X.520, chapter 5, defines the DN attribute types in terms of semantics, allowed encodings and matching rules. Most of the attributes are defined as the base type "name" whose matching rule is "caseIgnoreMatch" (and not "bitStringMatch"). The matching rules are specified later in chapter 7. For caseIgnoreMatch, a "string preparation" (chapter 6) must be performed previous to the comparison (just what someone has already proposed as a "canonicalization"). RFCs 3280/5280, being profiles of the X.5xx series, are allowed to make choices over what is optional on the X.5xx (e.g., whether extension foo should be marked critical or not), define extensions (e.g., authorityInformationAccess), etc. But profile RFCs shouldn't redefine anything. In this case, they redefined the matching rules of "name" based attributes, saying that they have to be interpreted as bitStringMatch at a minimum, and, optionally, for those who care, caseIgnoreMatch. The RFCs should only give a brief description of the algorithm and reference the relevant sections of the X.5xx series.
Sorry, Nuno. On the Internet, the IETF's RFCs are authoritative. If they disagree with some other standards, the RFCs win, on the internet.
Agree, they are authoritative. But these RFCs in particular are called "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". The keywords here are "X.509" and "profile". As they are specified, they should be named "IETF's X.509 branch"... :-D
You need to log in before you can comment on or make changes to this bug.