448738 - Need way to change nickname on existing token objects, especially certs

Status: ASSIGNED

(NSS :: Libraries, enhancement, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

As we move towards shared DBs, we know there are going to be nickname 
collisions.  We know there are going to be multiple separate existing 
cert8.db files that have certs with various subject names, but all of 
which share the same nickname (CKA_LABEL, most commonly "Server-Cert").

We need a way to rename the nicknames on existing cert objects.  
We need tools to do it,
We may need softoken changes to do it,
We may need DB changes to do it,
We may need changes in NSS cert caches (the "temp cert DB") to do it.

Customers will be unable to merge existing DBs until we solve this.!

It MIGHT (or might not) be enough to solve this only when/while merging DBs,
but such merges are not interactive processes now.  

Initially, we need someone to architect how this will be done.  
Bob, will you do that?

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Bob wrote:

The following will set the nickname on any object. Unfortunately it's 
not exported.

SECStatus
PK11_SetObjectNickname(PK11SlotInfo *slot, CK_OBJECT_HANDLE id,
                                                const char *nickname)


There are 3 functions which set and get the Nickname on Private, Public, 
and Symetric Key:

SECStatus
PK11_SetPrivateKeyNickname(SECKEYPrivateKey *privKey, const char *nickname)
SECStatus
PK11_SetPublicKeyNickname(SECKEYPublicKey *pubKey, const char *nickname)
SECStatus
PK11_SetSymKeyNickname(PK11SymKey *symKey, const char *nickname)

There is one function which allows you to set any Attribute on any object:

SECStatus
PK11_WriteRawAttribute(PK11ObjectType objType, void *objSpec,
                                CK_ATTRIBUTE_TYPE attrType, SECItem *item)


So it looks like there isn't a specific function to set the Nickname on 
either:

Generic objects, Certs, CRLs, or S/MIME records, other then the generic 
set any attributes.

Certs probably need some conflict resolution code since NSS wants there 
to be a unique subject matching a given nickname (something PKCS #11 
doesn't require or enforce). I suspect we also need to update the view 
of the certs in the cache (though they tend to be short lived in 
practice, so that may not be an issue).

It would be relatively short (The three existing functions simply call 
"SECStatus PK11_SetObjectNickname(PK11SlotInfo *slot, CK_OBJECT_HANDLE id,  
const char *nickname)". A cert version would just call 
SEC_CertNicknameConflict() first and fail if there is one.

Here's what it probably should look like:

SECStatus
CERT_SetCertNickname(CERTCertificate *cert, const char *nickname, void *passwordArg)
{
    PK11SlotInfo *slot
    CK_OBJECT_HANDLE pkcs11Handle;
    if (SEC_CertNicknameConflict(nickname, &cert->derSubject, cert->dbHandle)) {
       PORT_SetError(SEC_ERROR_CERT_NICKNAME_COLLISTION);
       return SECFailure;
    }
   pkcs11Handle = PK11_FindObjectForCert(cert, passwordArg, &slot);
   if (pkcs11Handle == CK_INVALID_OBJECT)  {
       /* need to add a 'cert not found error code */
       return SECFailure;
   }
    return PK11_SetObjectNickname(slot, pkcs11Handle);
}

Since it calls SEC_CertNicknameConflict, it probably should live in 
certdb, though it could be called PK11_XXX and live in pk11cert.c as well.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Julien, since Sun wants this more urgently than Red Hat does, would you take
a look at implementing this?

Comment 3

[Julien Pierre]

Sure.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.

Comment 5

[glen beasley]

Attachment: add --rename option to certutil to rename an existing cert nickname

adding --rename option for cert nickname only, this patch does not provide support to rename a key. Meaning if you change the certificate nickname it's corresponding private key will still have it's old nickname if it had a nickname. Also the description of this bug outline many issues relating to merge of DBs which have been solved in other bugs such as bug 439115. This patch only addresses rename of an existing cert nickname. 

Example: change cert nickname SSLServer to SSLServer-jss

certutil --rename -n SSLServer --new-nickname SSLServer-jss -d .

cases test:

rename cert nickname

return error if unable to find cert nickname:
certutil: could not find certificate named "SSLclient--884276638gh": Unrecognized Object Identifier.

returns error if user's chosen nickname already exists:
certutil: unable to rename certificate: A certificate with the same nickname already exists.

certutil -H:
--rename        rename a single named cert
   -n cert-name      Pretty print named cert
   -d certdir        Cert database directory (default is ~/.netscape)
   -P dbprefix       Cert & Key database prefix
   -X                force the database to open R/W
   --new-nickname    new nickname for cert

certutil -h:
	certutil --rename -n cert-name --new-nickname 
		[-X] [-d certdir] [-P dbprefix]

Tested on dbm (cert8) and sql (cert9) db types.

Comment 6

[Robert Relyea]

Comment on attachment 398302 [details] [diff] [review]
add --rename option to certutil to rename an existing cert nickname

r- for two reasons...

1) I'm worried CERT_SetCertNickname is incomplete. I'm not worried that it's not sufficient for certutil to change the nickname in the db or token, but I am worried that it may not do enough for the nickname to be properly propagated through the CERTCertificate and NSSCert structures. If some other application calls this to rename a certificate that's in the cache, I don't think all the cache instance variable will be properly updated.

2. I would drop the change to the dbm3 code. The change, as is will cause the cert to have a different nickname than the subject record pointing to that cert. This will technically lead to certdb corruption (though I'm not sure how or if it would manifest itself).

If we want to allow dbm databases to change cert nicknames, we will need to update the subjects, and all the certs attached to them. I would suggest just dropping this part of the patch.

bob

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Bob, are you suggesting making this feature be available only for SQL DBs
and not for DBM DBs?  I think that wouldn't help Glen's users.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Bob, Perhaps you can suggest/describe a test program that Glen could write 
that might serve to test the cache issue you described in comment 5 point 1.