[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Invalidity Dates
Part of the confusion, I believe, is that Al and others were lumpng both the functionality of a compromised key list and a CRL into one place.
I agree that "retroactive" revocation should not occur because it weakens the system from a business standpoint, but I also agree that some implementations of identity and privacy systems need to record the actual or closest date of key compromise in case action of the system owners need to occur. For example, in a government situation with a crypto key reported compormised, then the security administration needs to assess their exposure.
In the private sector model, I used a false will as an example. If I had strongly suspected that my identitiy was compromised, then I would personally file an affidavid with some notare or state clerk with some proof that I was out of the country to attempt to mitigate my own exposure. I would not expect the CA or any merchants to relieve me of my responsibility. In some cases, law protects both the CA and others because the law (like Utah) puts the security of the private key for identity completely with the "subscriber" or certificate user.
Some private models, like credit card holders may wish to use password or biometric controlled certificates as enhanced identity authentication and retain theor current licability models or even offer higher protection for people with this system, but I doubt that they will assume any liability for time periods before they new about the compromise.
Hope this helps,
michael
>>> Juergen Walter <walter@deh.de> 12/16/98 03:37AM >>>
****************** InterScan Message (on zbc2)
noname is scanned and no virus found
*********************************************************