-----BEGIN PGP SIGNED MESSAGE----- [To: cypherpunks list ## Date: 01/11/96 02:25 pm ## Subject: Limiting reuse of certificates. ]
Date: Mon, 08 Jan 1996 17:31:24 -0500 (EST) From: Michael Froomkin <froomkin@law.miami.edu> Subject: Certificates: limiting your liability with reuse limitations
Suppose I am a CA. I am worried that by issuing a certificate with a lifespan of more than 2 milliseconds I am opening myself up to unlimited liability if for some reason, despite my best efforts, I issue an erroneous certificate.
I know I can put an expiration date on the certificate, but that's not enough. I can accumulate a lot of exposure in a few seconds, much less weeks.
I know I can put a reliance limit in the X.509 ver 3 certificate, but that's not enough. Even a $1 limit could be used many millions of times.
Is it feasabile to say: Can only be relied on once per day/week/month? Is this something the relying parties can reasonably be expected to monitor?
This is a hard problem. The only way I can see to do this is to require interaction with the CA (or its proxy) for each signature. The good news is that if you're doing certificate revokation lists online, then there is probably already some interaction with the server to verify that a certificate is still valid, before it is accepted. The trick here is to flip around who has to check the CRL server. a. Bob forms D = document he wants signed, ID_B = Bob's ID, and sends to Alice M_0 = ID_B, D. b. Alice forms T = timestamp and sends to the Server M_1 = T, hash(ID_B, D), Sign_{SK_A}(T, hash(ID_B, D)). c. The Server verifies the timestamp, the signature, and that Alice is currently allowed to sign things (her certificate is valid and hasn't been overused today). If not, it drops the connection and ends the protocol. If things all check out, however, it forms M_2 = T, Sign{SK_S}(T, hash(ID_B, D), Certificate_A). d. Alice now has (until the timestamp T becomes too stale) an authorization to sign D. She does so, and sends to Bob (who's been waiting all this time) M_3 = T, ID_B, D, Certificate_A, M_2, Sign_{SK_A}(ID_B, D). Now, the trick is to redefine valid signatures as only those that look like M_3. The recipient has to verify the timestamp, and that he hasn't received an identical signature from Alice recently, and has to verify the two signatures. (I make no promises about the soundness of this protocol--it's meant to illustrate the idea, not to be used directly.) Other than that, I can't think of anything that will fit the bill.
A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin@law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's warm here.
Note: Please respond via e-mail as well as or instead of posting, as I get CP-LITE instead of the whole list. --John Kelsey, jmkelsey@delphi.com PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMPV110Hx57Ag8goBAQFVggP+P9ilz7cM8BQX+nDgjByG4avAoHxgDpDw cWsx7dw31MQsPCEkzvuvCcwf36e4xEQd3jKMh5rYmWrYRAMQAoB4yGm7ixN4tqXH 1g6Xw9QPCLnW4OJvjfynzFfKb5i8KcvOSBnCXzOd1Z/LYEI23/6phdNd9rRf/YjL mxbKS7gDrHI= =dn6t -----END PGP SIGNATURE-----