Open Bug 386871 Opened 17 years ago Updated 2 years ago

match cert name attributes with different character encodings

Categories

(NSS :: Libraries, enhancement, P4)

Product:
NSS
Component:
Libraries
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: marcos.marado, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) 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 2.0.0.4 
:|
Filipe Polido:

you probably already accepted the certificate permanently in the past and now firefox dont show the warning... just tested in 2 firefox 2.0.0.4 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.
Blocks: 164421
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 2.0.0.6 

2 Ubuntu Feisty; Firefox 2.0.0.6

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 2.0.0.7 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 2.0.0.8
- (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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.