Note: There are a few cases of duplicates in user autocompletion which are being worked on.

CERT_AsciiToName doesn't accept all valid values

RESOLVED FIXED in 3.12

Status

NSS
Libraries
P3
normal
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: Nelson Bolyard (seldom reads bugmail), Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Some time ago, bug 39494 was fixed.  NSS's function CERT_NameToAscii was 
enhanced to translate unknown/unrecognized attribute types to decimal strings
that represented the OID values, and unrecognized attribute values were 
translated into hex strings (IIRC).  

But the function CERT_AsciiToName was not enhanced to be able to translate
the ASCII strings produced by  CERT_NameToAscii back into DER DNs.  

Consequently, CERT_AsciiToName now returns errors in response to some strings
returned by CERT_NameToAscii.  This should be fixed.  Ideally, the two functions
should be each other's inverses.
(Assignee)

Comment 1

14 years ago
CERT_FindCertByNameString depends on this function.
(Assignee)

Comment 2

14 years ago
There are more problems with this function than I realized when I first filed it.
The problems include;

a) This function doesn't understand attribute types of the form 
    OID.<dotted-decimal-oid>
where <dotted-decimal-oid> is an oid represented as decimal numbers separated
by periods,  and 

b) This function doesn't understand attribute values that are hex strings 
preceeded by #, and 

c) This function doesn't understand backslash escaping, which include 
escaping of hexadecimal pairs and escaping of special characters such as 
commas, and

d) This function doesn't reconstruct "multi-valued" RDNs, whose attributes
are separated by "+" characters.  

In short, this function needs to accept all input strings that are valid 
according to any of RFCs 2253, 1779 and 1485.
Summary: CERT_AsciiToName doesn't handle decimal or hex values → CERT_AsciiToName doesn't accept all valid values
(Assignee)

Updated

14 years ago
Blocks: 210709
(Assignee)

Comment 3

14 years ago
For this function to work properly, our ASN.1 encoder needs to properly 
encode SET OF, which it does not do now.  Otherwise, the encoded AVAs in 
a multi-valued RDN may (probably will) be encoded in the wrong order, 
producing a non-matching DER DN.  I will file a separate bug.
(Assignee)

Comment 4

14 years ago
Comment 3 above was attached to the wrong bug.  It was meant for bug 210709.
Bug 211655 has now been created, and blocks bug 210709.
(Assignee)

Updated

14 years ago
Depends on: 196360
(Assignee)

Comment 5

14 years ago
Changing dependency.  This bug now depends on bug 124923 instead of bug 196360.
Bug 196360 will become a dup of bug 124923.
Depends on: 124923
No longer depends on: 196360
(Assignee)

Comment 6

12 years ago
*** Bug 292369 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

12 years ago
QA Contact: bishakhabanerjee → jason.m.reid
(Assignee)

Updated

12 years ago
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
(Assignee)

Updated

11 years ago
Priority: -- → P3
(Assignee)

Updated

10 years ago
Depends on: 161326
(Assignee)

Comment 7

10 years ago
All the prerequisite dependencies of this bug are now resolved.  
Neil, please take this.
Assignee: nobody → neil.williams
(Assignee)

Updated

10 years ago
Target Milestone: --- → 3.12

Comment 8

10 years ago
I think you also have to worry about changes to SetupAVAValue() in secname.c.
The switch statement will need to have a new case for 'undefined' type, since we don't know the type of the value. Perhaps you can used '0', since that's the type corresponding to the type for an unknown OID: SEC_OID_UNKNOWN in the name2kinds table in alg1485.c 



(Assignee)

Comment 9

10 years ago
In reply to comment 8:

I think the relevant case is not "unknown" but rather "pre-encoded",
for use with values that are hexadecimal representations of the 
already-DER-encoded values.  

Is that what you had in mind, Steve?

Comment 10

10 years ago
So, we will define '0' in the valueType field of struct NameToKind as meaning:
 - "the associated value is the ASCII string of the form "#ab1234...", or
 - "the byte array resulting from decoding the ASCII string of the form "#ab1234"

Where is the hex encoding scheme specified? Its only mentioned in passing RFC 1485. I am most curious about what structure is to be encoded. Is it the entire "SET OF AttributeValue" field?

Attribute       ::=     SEQUENCE {
      type              AttributeType,
      values    SET OF AttributeValue }
(Assignee)

Comment 11

10 years ago
http://www.rfc-editor.org/rfc/rfc1485.txt     was superseded by

http://www.rfc-editor.org/rfc/rfc1778.txt and
http://www.rfc-editor.org/rfc/rfc1779.txt     which were superseded by

http://www.rfc-editor.org/rfc/rfc2252.txt and 
http://www.rfc-editor.org/rfc/rfc2253.txt     which were superseded by

http://www.rfc-editor.org/rfc/rfc4514.txt and
http://www.rfc-editor.org/rfc/rfc4517.txt and
http://www.rfc-editor.org/rfc/rfc4519.txt     (Basically 4510-4519)

You asked: "Where is the hex encoding scheme specified?"
See RFC 4514 section 2.4 and the example in section 4
The hex attribute value is the entire BER/DER encoding of the AttributeValue.
(Assignee)

Comment 12

10 years ago
Note that this bug was blocked until recently by bug 161326, which reported
the absence of a function to turn ASCII strings of the form OID.n.n.n...
into DER-encoded OIDs.  But bug 161326 is now resolved fixed, and the 
new function SEC_StringToOID() is ready to be used by CERT_AsciiToName.
(Assignee)

Comment 13

10 years ago
Created attachment 274868 [details] [diff] [review]
patch v1, accept OID=#hex ATAV strings.

Steve, can you test this patch and tell me if it solves the problem you're
having in libPKIX?
Assignee: neil.williams → nelson
Status: NEW → ASSIGNED
Attachment #274868 - Flags: review?(sparkins)
(Assignee)

Comment 14

10 years ago
Created attachment 275277 [details] [diff] [review]
patch v2 (tested)

This patch is tested better than the last one.
I had to fix a bug in certutil to test it. 
Will file a separate bug about that.
Attachment #274868 - Attachment is obsolete: true
Attachment #275277 - Flags: superreview?(alexei.volkov.bugs)
Attachment #275277 - Flags: review?(neil.williams)
Attachment #274868 - Flags: review?(sparkins)

Comment 15

10 years ago
Comment on attachment 275277 [details] [diff] [review]
patch v2 (tested)

look good. Seems to be much more robust parsing code.
Attachment #275277 - Flags: superreview?(alexei.volkov.bugs) → superreview+
(Assignee)

Comment 16

10 years ago
Checking in alg1485.c;   new revision: 1.27; previous revision: 1.26
Checking in certi.h;     new revision: 1.19; previous revision: 1.18
Checking in secname.c;   new revision: 1.21; previous revision: 1.20
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Attachment #275277 - Flags: review?(neil.williams)
You need to log in before you can comment on or make changes to this bug.