52210 - Remove dependencies of O= in cert name from NSS

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P3)

Description

[Steve Parkinson]

In CERT_MakeCANickname(), there is still some code which assumes
that the CA subject name has certain composition.

We have customers who want to create more flexible CA's, and this
is a problem for them.

In this particular case, the customer is using DC='S instead of
O=, so 'CERT_GetOrgName()' returns null, and then so does
CERT_MakeCANickname().

Comment 1

[Steve Parkinson]

I should add that this then causes CERT_ImportCAChain() to return failure

Comment 2

[Steve Parkinson]

Attachment: Patch to workaround problem

Comment 3

[Steve Parkinson]

I have create a patch to allow the nickname to be created when the O=
is missing. This solves the customer's problem for now. But the cert
still must have either CN or OU in it. What if it's all DC?

There needs to be a better scheme for nicknames. How about, if we can't
make the nickname using our current algorithm, we just use the entire
subject name for the nickname?

Comment 4

[Steve Parkinson]

Hmm - that patch is bad since at the end of the code, it tries to 
PORT_Free() the memory. But you get the idea.

Comment 5

[Jamie Nicolson]

Reassigning to myself since it's a JSS deliverable.

Comment 6

[Jamie Nicolson]

Attachment: proposed patch

Comment 7

[Jamie Nicolson]

The proposed patch will use the full subject name, encoded in RFC1485, if the 
components that are usually used are missing. We need to get this change 
reviewed, approved, and checked in, and NSS needs to be respun for CMS.

Comment 8

[Robert Relyea]

Hmm. I talked to Steve about this, I didn't realize you had a patch in the bug.
I don't think the full DN is necessary as the loop will pick up a counter to
make sure the nickname is unique. Here's my proposed patch.

bob

Comment 9

[Robert Relyea]

Attachment: don't fail if the issuer doesn't have an organization

Comment 10

[Robert Relyea]

Fixed in NSS 3.3 and 2.8.5