need QA test that all cert name attributes are properly encoded

Assigned to


18 years ago
10 years ago


(Reporter: Sonja Mirtitsch, Assigned: Slavomir Katuscak)


Firefox Tracking Flags

(Not tracked)




18 years ago
Test fix for Bug 53127  Accept UTF8String encoding for attributes in Names

 From: (Terry Hayes)
 To: Sonja Mirtitsch <>

 Yes we should eventually build a test for this.  The problem is that
 there isn't any code right now that makes it easy to create a
 certificate with the new encoding.  We can probably write a program
 that builds a certificate request piece by piece and then use certutil
 and other tools to test whether NSS recognizes it.  Ian may be able to
 help with that as well.
 The library should accept the UTF8String encoding of directory string values
 found in X.500 names.  This encoding is mandated for certificates created after
 2003.  It should be added as soon as possible to allow for smooth upgrading of
 the PKI infrastructure.

 NOTE: we do not need to generate UTF8String (yet).

 Change is checked in, but I don't know how to QA this in the test suite.  I've
 built a version of PSM that accepts certificates with this encoding as a
 one-time test.

target release 3.3


18 years ago
Target Milestone: --- → 3.3


18 years ago
Ever confirmed: true

Comment 1

17 years ago
Reassigned bug to Sonja.
Assignee: wtc → sonmi


17 years ago
Component: Tools → Test


17 years ago
Target Milestone: 3.3 → 3.4


16 years ago
Target Milestone: 3.4 → Future

Comment 2

16 years ago
Assigned the bug to Bishakha.
Assignee: sonja.mirtitsch → bishakhabanerjee

Comment 3

16 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Assignee: bishakhabanerjee → jason.m.reid
QA Contact: bishakhabanerjee → jason.m.reid
Target Milestone: Future → ---
Assignee: jason.m.reid → nobody
QA Contact: jason.m.reid → test

Comment 4

12 years ago
Is the certutil limitation about not being able to create that encoding still current ?
RFC 3280 (and other related RFCs) define the correct character set to use 
for each and every type of attribute that can exist in the cert names.
Today, NSS encodes a few of them correctly, a few are known to be incorrectly
encoded, and most of the rest are untested.  

The QA test envisioned here would generate a cert with many MANY name attributes
and then test that each and every one was encoded in the correct character set.

NSS 3.11.x, as it exists today, is guaranteed to fail this test, if the test 
was properly implemented.  But the test does not yet exist.  

I believe that the companies that support NSS care about NSS's ability to 
correctly encode cert names, hence P2.
Priority: P3 → P2
Summary: need QA suite to test fix for UTF8String encoding for attributes in Names → need QA test that all cert name attributes are properly encoded
Bug 329067 documents some of the cert name attributes that are incorrectly
encoded.  This bug doesn't block that one, nor vice versa.  But I wanted to
mark these bugs as related.  One bug documents the encoding error, the
other bug documents the absence of a QA test that would detect such an
encoding error.

It's clear to me that to fulfill this test RFE, we need a new test tool,
one that parses a certificate and checks the encoding type of every 
attribute, to ensure that every attribute is encoded using one of the 
character set types defined for that attribute.  Such a tool would be 
useful for many purposes.  
Blocks: 329067
Reassign to Slavo.
Assignee: nobody → slavomir.katuscak


10 years ago
Priority: P2 → P3

Comment 8

10 years ago
Decreasing priority to P3 (based on priorities set on meeting with Nelson in September).
Readjusting priority back to P2 to be consistent with the priority definitions
used in NSS.  
A fix for this bug/RFE is desired by one of the companies that sponsor NSS.  
By the present definition of NSS priorities, that makes it at least a P2.  
Priority: P3 → P2
You need to log in before you can comment on or make changes to this bug.