207711 - Recognize all cert name attribute types in RFC 3280

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

I thought we already had a bug about this, bug I cannot find it now.

RFC3280 says that a conforming implementations MUST recognize these name
attribute types:
   country                                   C=
   organization                              O=
   organization-unit                         OU=
   distinguished name qualifier              dnQualifier=
   state/province name                       ST=
   common name                               CN=
   serial number                          ???
and SHOULD recognize these attribute types
   locality                                  L=
   title                                  ???
   surname                                ???
   given name                             ???
   initials                               ???
   pseudonym                              ???
   generation qualifier (jr, 3rd, etc.)   ???

nss/lib/certdb/alg1485.c recognizes the attributes types shown above with 
equal signs, and also the ones listed below.  It does not recognize the 
ones shown above with question marks.  Additional ones recognized by 
NSS include
   domainComponent                        DC=
   PKCS9 email address                    E=
   RFC1274 UID                            UID=
   RFC1274 email                          MAIL=

NSS's absent recognition of some of the above attribute types has already
been an issue for some NSS users.  It should be easy to add the additional
types to alg1485.c.  Let's do it.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

The question is: what strings should be used to identify these new attribute
types in the RFC 1485-style srings?  

I propose to use these strings for these OIDs:

"CN",             64, SEC_OID_AVA_COMMON_NAME
"ST",            128, SEC_OID_AVA_STATE_OR_PROVINCE
"OU",             64, SEC_OID_AVA_ORGANIZATIONAL_UNIT_NAME
"DC",            128, SEC_OID_AVA_DC
"C",               2, SEC_OID_AVA_COUNTRY_NAME
"O",              64, SEC_OID_AVA_ORGANIZATION_NAME
"L",             128, SEC_OID_AVA_LOCALITY
"dnQualifier", 32767, SEC_OID_AVA_DN_QUALIFIER
"E",             128, SEC_OID_PKCS9_EMAIL_ADDRESS
"UID",           256, SEC_OID_RFC1274_UID
"MAIL",          256, SEC_OID_RFC1274_MAIL
"SURNAME",        64, SEC_OID_AVA_SURNAME
"SERIAL",         64, SEC_OID_AVA_SERIAL_NUMBER
"STREET",        128, SEC_OID_AVA_STREET_ADDRESS
"TITLE",          64, SEC_OID_AVA_TITLE
"ADDRESS",       128, SEC_OID_AVA_POSTAL_ADDRESS
"CODE",           40, SEC_OID_AVA_POSTAL_CODE
"BOX",            40, SEC_OID_AVA_POST_OFFICE_BOX
"GIVEN",          64, SEC_OID_AVA_GIVEN_NAME
"INITIALS",       64, SEC_OID_AVA_INITIALS
"GENERATION",     64, SEC_OID_AVA_GENERATION_QUALIFIER
"HOUSE",          64, SEC_OID_AVA_HOUSE_IDENTIFIER
"AKA",            64, SEC_OID_AVA_PSEUDONYM

If anyone has any better suggestions, please set them forth here.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Attachment: Augment name attribute table, eliminate duplication

This patch adds the new attribute types and strings shown above to the table.
It also adds a new column to the table, which contains the maximum permitted
length of an attribute of that type.
It removes several switch statements that duplicated information that is in 
the table, and uses the value in the table instead.  
It also removes some dead old code that was #if 0.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Attachment: patch, part 2, prerequisite to patch above.

attachment 125057 [details] [diff] [review] depends on these changes to the table of known SEC OIDs.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

The above patches were checked in on the trunk on June 6.
I left the bug open because I wasn't completely convinced that the new
"short names" introduced by this patch were the right ones.  There was 
not a clear consensus among IETF documents about this, and still is not,
AFAIK.  

So, I will mark this fixed, with the understanding that we may need to 
revisit this if/when the IETF standardizes short names for some of these.

Also, I have heard that OpenSSL has established short names for some of 
these.  Our table probably should recognize OpenSSL's short names.