Possible reasons for key revocation

[sgoendoer]

Reasons a user might want to revoke the keypair used to create the GUID

RFC3280 defined two main states of a revocation: HOLD (temporary) and REVOKED (indefinitely). RFC5280 defines the following reasons for a key revocation:

unspecified (0)
keyCompromise (1)
CACompromise (2)
affiliationChanged (3)
superseded (4)
cessationOfOperation (5)
certificateHold (6)
removeFromCRL (8)
privilegeWithdrawn (9)
AACompromise (10)

I don't think we would need all of those. Here is a (incomplete?) list of reasons in the rethink-context. Please feel free to extend and/or discuss the list items:

severe reasons

• [Encryption algorithm compromised] The key algorithm has been broken (i.e. the key is not secure anymore)
• [Key generation compromised] Due to a security issue, the key was (might have been) created with insecure parameters
• [Key compromised] Someone obtained a copy of the user's private key
• [CA compromised] Someone obtained a copy of the CA's private key

other reasons

• [Key might have been compromised] Suspicion that someone got hold of the private key
• [Key outdated] The key is old and should be replaced
• [Key inaccessible/destroyed] The key file cannot be read/has been deleted
• [Account cessation] The account should be deleted indefinitely
• [New identity] The user wants to abandon a GUID and create a new one. (No key revocation needed!?)
• [Architecture change] The GUID creation changed significantly, so that "old" keys cannot be used anymore

[rjflp]

These are all valid reasons, but for implementation purposes do we need them all? If necessary, I would say we can simplify by considering that:

• [Key compromised] and [Key might have been compromised] are one and the same. Especially if we only have REVOKED but not temporary revocation.
• [Key outdated] should not be required. The certificate will have an expiration date. Is this a way to shorten the expiration date after the certificate is created? Do we really need it?
• [New identity] is a subset of [Account cessation] ?
• [Architecture change] is a subset of [Encryption algorithm compromised] ?

A general "unspecified" could be useful for future, unforeseen cases.

I can't come up with a case that is not already covered by @sgoendoer 's list.

[sgoendoer]

Well, I made this list not as a proposal to use ALL of them, just to have a list of all (?) possible reasons why someone would want to revoke a key. Hence, as Ricardo already pointed out, a much smaller subset of reasons might suffice.
"Key outdated": No, I guess, this reason in the certificate would be just an "explanation" why your key is not in use anymore. As already noted, after a certificate expired, noone is forced to (manually) revoke the key additionally.