204788 - DirectoryString type should be defined as UTF8String encoding

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Ian McGreer]

From bugtraq 4719957.  Pasting in report:

1. Access to iWS60 admin server from Netscape Communicator.
2. Change the browser coding to Unicode (UTF-8)
3. Create a CSR from Admin server -> Security tab -> Request a Certificate
   In the request, enter a utf-8 character for Requestor name, Common name,
Organization.
Example, here's a CSR file with utf-8:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBwTCCASoCAQAwgYAxCzAJBgNVBAYTAkphMRUwEwYDVQQIHAwAADBLAAAwSwAA
MEsxFTATBgNVBAccDAAAMEoAADBKAAAwSjEVMBMGA1UEChwMAAAwRgAAMEYAADBG
MRUwEwYDVQQLHAwAADBIAAAwSAAAMEgxFTATBgNVBAMcDAAAMEQAADBEAAAwRDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyt1yoszKL0gvvybKBkr1NWWbEukJ
o1CSUONykhC147rej/X5BD0D7y3qEFmGMxDM5sQAuF+BwA8Rqh/r74V4bXT4BDOV
XPjPRPic4YNY1d2MF4dRXLsxZe05aUmv7hHD5+JpWyRtDRCLygm2KFCmP9+S6dOm
BWo/OxPGzpkDMLcCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GBACLHLJW7qQNxFlLL
R5f7lZP7TTrQe3HdvUolv2HmX4DoHi1HkB5jr+BAiGQuPcF/dc79wv50aPStrSYQ
nRenHnDgJJC1PZ678A6c6oNv5M7DbhEYUMS1HalrP0y383bNC4WQpA9qOzNqDWzw
b87pkp/kUDMTb2E5sQaSgB3laMYz
-----END NEW CERTIFICATE REQUEST-----

4. Dump CSR: use the openssl as following - 

# openssl asn1parse -i -in <CSR file> -inform PEM

    0:d=0  hl=4 l= 449 cons: SEQUENCE
    4:d=1  hl=4 l= 298 cons:  SEQUENCE
    8:d=2  hl=2 l=   1 prim:   INTEGER           :00
   11:d=2  hl=3 l= 128 cons:   SEQUENCE
   14:d=3  hl=2 l=  11 cons:    SET
   16:d=4  hl=2 l=   9 cons:     SEQUENCE
   18:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
   23:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :Ja
   27:d=3  hl=2 l=  21 cons:    SET
   29:d=4  hl=2 l=  19 cons:     SEQUENCE
   31:d=5  hl=2 l=   3 prim:      OBJECT            :stateOrProvinceName
   36:d=5  hl=2 l=  12 prim:      UNIVERSALSTRING
   50:d=3  hl=2 l=  21 cons:    SET
   52:d=4  hl=2 l=  19 cons:     SEQUENCE
   54:d=5  hl=2 l=   3 prim:      OBJECT            :localityName
   59:d=5  hl=2 l=  12 prim:      UNIVERSALSTRING
   73:d=3  hl=2 l=  21 cons:    SET
   75:d=4  hl=2 l=  19 cons:     SEQUENCE
   77:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
   82:d=5  hl=2 l=  12 prim:      UNIVERSALSTRING
   96:d=3  hl=2 l=  21 cons:    SET
   98:d=4  hl=2 l=  19 cons:     SEQUENCE
  100:d=5  hl=2 l=   3 prim:      OBJECT            :organizationalUnitName
  105:d=5  hl=2 l=  12 prim:      UNIVERSALSTRING
  119:d=3  hl=2 l=  21 cons:    SET
  121:d=4  hl=2 l=  19 cons:     SEQUENCE
  123:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
  128:d=5  hl=2 l=  12 prim:      UNIVERSALSTRING
  142:d=2  hl=3 l= 159 cons:   SEQUENCE
  145:d=3  hl=2 l=  13 cons:    SEQUENCE
  147:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
  158:d=4  hl=2 l=   0 prim:     NULL
  160:d=3  hl=3 l= 141 prim:    BIT STRING
  304:d=2  hl=2 l=   0 cons:   cont [ 0 ]
  306:d=1  hl=2 l=  13 cons:  SEQUENCE
  308:d=2  hl=2 l=   9 prim:   OBJECT            :md5WithRSAEncryption
  319:d=2  hl=2 l=   0 prim:   NULL
  321:d=1  hl=3 l= 129 prim:  BIT STRING

As can be seen from above, it looks like DirectoryString is UniversalString and
not a 
UTF8String. Here's the RFC(under 4.1.2.4 ):

http://www.faqs.org/rfcs/rfc3280.html

It states the following:
"The DirectoryString type is defined as a choice of PrintableString,
TeletexString, BMPString, UTF8String, and UniversalString.  The
UTF8String encoding [RFC 2279] is the preferred encoding, and all
certificates issued after December 31, 2003 MUST use the UTF8String
encoding of DirectoryString (except as noted below)."

As per the RFC, UTF8String encoding is the preferred encoding. So customer
is requesting us to use UTF8String encoding and hence this RFE.

Comment 1

[Ian McGreer]

more info:

WS uses CERT_AsciiToName() to create a CERTName from a string of the form 
"CN=x, OU=x, O=x, L=x, ST=x, C=x" (where the OU, L, and ST are optional). This
ends up calling CERT_ParseRFC1485AVA() which contains the following code:

    /* Hack -- for rationale see X.520 DirectoryString defn */
    if (IsPrintable((unsigned char*)valBuf, valLen)) {
        vt = SEC_ASN1_PRINTABLE_STRING;
    } else if (Is7Bit((unsigned char *)valBuf, valLen)) {
        vt = SEC_ASN1_T61_STRING;
    } else {
        vt = SEC_ASN1_UNIVERSAL_STRING;
    }

Comment 2

[Ian McGreer]

Attachment: change default from UniversalString to UTF8String

Comment 3

[Ian McGreer]

Comment on attachment 123407 [details] [diff] [review]
change default from UniversalString to UTF8String


After looking around, I found there's more work to do.

Comment 4

[Ian McGreer]

Attachment: another place where UniversalString was assumed

Comment 5

[Ian McGreer]

Comment on attachment 123414 [details] [diff] [review]
another place where UniversalString was assumed


I'll see if I can make a cert with UTF8 chars to test this with.  I believe
these are all the places that need to be changed.

Comment 6

[Ian McGreer]

Managed to get certutil to create a CSR with a UTF8 character, here's before:

C-Sequence  (374)
   C-Sequence  (224)
      Integer  (1)
         00 
      C-Sequence  (55)
         C-Set  (53)
            C-Sequence  (51)
               Object Identifier  (3)
                  2 5 4 3 (X520 Common Name)
               Universal String  (44)
                  00 00 00 49 00 00 00 61 00 00 00 6e 00 00 00 20 00 00 
                  00 b5 00 00 00 63 00 00 00 67 00 00 00 72 00 00 00 65 
                  00 00 00 65 00 00 00 72 
...

and after:

C-Sequence  (342)
   C-Sequence  (192)
      Integer  (1)
         00 
      C-Sequence  (23)
         C-Set  (21)
            C-Sequence  (19)
               Object Identifier  (3)
                  2 5 4 3 (X520 Common Name)
               UTF8 String  (12)
                  49 61 6e 20 c2 b5 63 67 72 65 65 72 
...

The actual DN was:

        Subject: CN=Ian µcgreer

Comment 7

[Ian McGreer]

checked in at tip:

Checking in alg1485.c;
/cvsroot/mozilla/security/nss/lib/certdb/alg1485.c,v  <--  alg1485.c
new revision: 1.11; previous revision: 1.10
done
Checking in secname.c;
/cvsroot/mozilla/security/nss/lib/certdb/secname.c,v  <--  secname.c
new revision: 1.10; previous revision: 1.9
done

and 3.3 branch:

Checking in alg1485.c;
/cvsroot/mozilla/security/nss/lib/certdb/alg1485.c,v  <--  alg1485.c
new revision: 1.3.48.2; previous revision: 1.3.48.1
done
Checking in secname.c;
/cvsroot/mozilla/security/nss/lib/certdb/secname.c,v  <--  secname.c
new revision: 1.3.68.1; previous revision: 1.3
done

Comment 8

[John G. Myers]

It's after December 31, 2003.  RFC 3280 requires *all* new certs to use
UTF8String encoding.

Comment 9

[John G. Myers]

Attachment: Use UTF8String exclusively

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Yes, RFC 3280 says that, but a number of the major CAs are not complying,
and (based on private correspondence) are in no hurry to do so.  

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 139529 [details] [diff] [review]
Use UTF8String exclusively

Nonetheless, I agree this is the right thing to do.

Comment 12

[John G. Myers]

I don't consider myself capable of adequately testing this, so I'd appreciate
someone else landing the patch.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

This change should go into 3.10, and not 3.9.1 IMO, so perhaps we should make
the 3.9 branch now.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Actually, upon further reflection, I think the solution may be more 
complicated than this.

The functions that create an encoded DN are sometimes used when creating a
new cert request, and at other times are used to create a DN for an older
cert.  

When creating a new cert request, we should use UTF8 exclusively, but
when creating an encoded DN for other purposes, such as looking for 
an old cert with that name, we want to create the encoded DN with the 
encoding it would have had when it was created.  

This issue is related to bug http://bugzilla.mozilla.org/show_bug.cgi?id=210709
and its blockers.

We could choose to 
a) have two sets of functions for building encoded DNs from attribute type/value
pairs, one for new CSRs and one for older certs, or 
b) have a function for that that takes a date argument, upon which the function
decides which encodings to use, or
c) Other suggestions?   (John?)

BTW, I think we should open a new bug for this coverstion-to-UTF8-always 
issue, and not morph this bug into that one.  Agreed?

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

I'm marking this bug fixed again, so that it will serve as a record of some
bugs that were fixed in NSS 3.9.

I will shortly open a new bug for this issue of using only UTF8 in new CSRs.

Comment 16

[John G. Myers]

(In reply to comment #15)
> I will shortly open a new bug for this issue of using only UTF8 in new CSRs.

Have you gotten around to this?  What is the new bug?

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

John,  It's but 232775.  You added comments to it the same day I filed it.

They say memory is the second human faculty to go.  
I don't remember what the first thing is.  :)