#60 2nd CSR shows up as signed i.s.o. first

[Jaap Keuter]

XCA 0.8.1, may be related to bug 3047029
After completing the 'create key pair, create CSR, export CSR, import CSR, sign CSR into Cert, export Cert, import Certs' cycle we have a user repository with a signed user certificate and CA certificate(s).
Now we 'rinse, repeat' this cycle: we create a new CSR, with the same CN and for the same key, just different purposes.

This new CSR is added to the list (with Name <subject>_1) and instantly marked as signed, just as the first CSR.
This can't be of course, the new CSR wasn't presented to the CA yet. Also if you look at the Certificates page only the Cert of the first CSR is present, which can be determined from the Cert extensions.
Close the database and open the database again. Now only the new CSR is marked signed, the first is now marked unhandled. This is the inverse of the real situation.
Removing the new CSR, closing and opening the database shows the correct situation again.

[Christian Hohnstaedt]

This is hard to fix.
The only 100% common thing of a request and the final cert is the public key.
The CA may decide to change parts of the Distinguished name, copy the extensions or not or parts of them
during signing the request.
So the current implementation uses the key to relate a cert to a request dynamically when opening a db and deleting/importing/signing requests and certificates.

1) The "signed" indicator means "there is at least one certificate with the same public key".
2) After opening the database, all requests with the same key and at least one corresponding certificate should be marked as "signed", which is currently not the case and a bug.
3) Did I already mention, that using the same key for more than one request/certificate is usually not a good idea ?

I can imagine an other approach:
After successfully signing a request, it is marked as signed and this information is stored in the DB.
This way it remains "signed", even after deleting the corresponding cert.
After deleting and reimporting an already signed request it will be marked as "unhandled" in this approach.
A newly imported, almost identical request will only be marked as signed after the signing procedure for this request succeeded.

There are pros and cons for the current implementation and the approach above.
I personally delete all requests after I signed them, They are not needed anymore afterwards.

Any opinions and proposals are welcome.