Brian Tvedt wrote: > > If I was that concerned about misuse of my private key, I would password protect > it. This seems much superior to relying on a complicated mechanism (CSL) being > correctly implemented in every security application out there. My private key IS password-protected, and nonetheless I could fear its misuse should I forget it around. This fear is even greater in Public Administrations with automatic signature servers. Since the law explicitly states that such servers sign on behalf of a real person, this guy has a real fear to be held responsible for signatures emitted during non-working hours. And as these servers typically use a crypto board, it is not that easy to disable it (could be used for SSL support too). Revoking and issuing new certs is a real trouble, especially when a smart-card (Or crypto board) with one-time on-board private-key generation is involved. Perhaps I have the wrong understanding of the Hold code in a RFC-2459 conformant CRL. I could not find a clear definition of how is a certificate "temporarily suspended" and yet placed in a CRL. In my understanding, a CRL is a monotonically non-decreasing list of revoked certificates. There is no way to state that a cert is valid again. Issuing another cert for the same key is simply not possible in certain environments. Either a CRL is augmented in meaning to be a list of invalid certs within specific timeframes (i.e. invalidity start - invalidity end, the latter being infinite for truly revoked certs), or a separate concept has to be created: CSL. OCSP can then be the vehicle to convey punctual information about a cert status, but given teh current legislation in several countries, CRLs (and may be CSLs) have to be produced and archived for legal use. Antonio Lioy
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature