RFC 1274 domainComponent OID

RESOLVED WONTFIX

Status

NSS
Libraries
P2
enhancement
RESOLVED WONTFIX
17 years ago
13 years ago

People

(Reporter: Ian McGreer, Assigned: Wan-Teh Chang)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rfc2459] [cert])

(Reporter)

Description

17 years ago
Moving from bugsplat:



Both RFC 1274 and RFC 2247 define a "DC" OID for domainComponent.  RFC 2247 "DC"
fields are currently recognized.  However, AOL CA S/MIME certs use a "DC"
associated with RFC 1274, currently this type is not recognized.  This OID needs
to be added in order to do lookup (by subject name) of certs using this spec.
(Assignee)

Comment 1

17 years ago
Ian, should we consider this for NSS 3.4's S/MIME work?
(Reporter)

Comment 2

17 years ago
Probably.  It shouldn't be difficult to add the OID, but it will be difficult to
ensure we understand the difference between the two.

We should ask someone on the CMS team if they still see these kind of certs.
I vote yes (add this into 3.4).  Because of this bug, NSS has been unable
to display and handle certain valid certs for years.
(Assignee)

Updated

17 years ago
Priority: -- → P2
Target Milestone: --- → 3.4
In rev 1.4 of secoid.c  (dated June 20, 2000) ChrisK wrote:

"Fix OID for DC AVAs - the root OID in RFC2247 is not different from
the root OID in RFC1274 - so the one we had was WRONG.
I don't know where it came from."

His change was to delete the old value RFC2247_ATTR_TYPE, and to use
RFC1274_ATTR_TYPE everywhere instead.  

SO, this begs some questions.  Like: Why is NSS unable to convert
the subject name in an AOL S/MIME cert to Ascii??
(Reporter)

Comment 5

17 years ago
Does anyone at AOL have one of these certs that they could attach to this bug as
a test case?
(Assignee)

Comment 6

16 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
(Assignee)

Comment 7

16 years ago
Set target milestone to NSS 3.5.
Target Milestone: 3.4 → 3.5

Comment 8

16 years ago
FYI - RFC 2459 specifies that implementations must accept the domainComponent
attribute specified in RFC 2247.
Whiteboard: [rfc2459]
(Assignee)

Updated

16 years ago
Whiteboard: [rfc2459] → [rfc2459] [cert]
(Assignee)

Updated

16 years ago
Severity: normal → enhancement
(Assignee)

Updated

16 years ago
Target Milestone: 3.5 → Future
Terry, Can you help us determine if this bug is valid any more?
Can you attach a sample afflicted cert to this bug?

The original bug report claims that NSS didn't recognize an OID 
from RFC 1274, but other bug comments and CVS log entries claim that 
NSS does support it.  

I think this bug needs to say:  NSS doesn't recognized THIS OID
and state the OID in dotted decimal fasion, or else be marked invalid.
I propose this bug be marked invalid if the offending OID isn't 
identified by 7/1/2005
Assignee: bugz → wtchang
QA Contact: bishakhabanerjee → jason.m.reid
Target Milestone: Future → ---

Comment 10

13 years ago
The information given in comment #4 is correct.  The value in RFC2247 is the
same as the one in RFC1274.  The correct value is 0.9.2342.19200300.100.1.25.
This is represented correctly by the hex value for RFC1274_ATTR_TYPE found in
secoid.c.

The incorrect value for RFC2247_ATTR_TYPE corresponds to an OID value with
1920030 substituted for the correct 19200300. Certificates encoded using NSS
previous to this change would have had the incorrect OID for domainComponent.  I
don't think there is any need to support certificates that have this error.

I susgest closing as invalid.
Marking Wontfix.  
Thanks for the analysis, Terry.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.