From owner-mcg-talk Wed Jun 24 12:34:47 1998 Received: (from majordom@localhost) by localhost (8.8.7/8.8.7) id MAA12480 for mcg-talk-outgoing; Wed, 24 Jun 1998 12:33:23 -0300 Message-Id: <199806241533.MAA12480@localhost> Date: Wed, 24 Jun 1998 12:33:17 -0300 (EST) From: "416720" To: MCG Subject: [MCG] Must e-commerce deals expire with certs? Sender: owner-mcg-talk@mcwg.org Status: RO X-Status: A perfect legal act is set for undefined time. A digital signature that is not repudiated by its signer and is confirmed every time you enquire about it SHOULD BE just like an ordinary signature that an honest man affixes in a contract and which he always confirms. However, that is not so under today's X.509 and CA use -- certificates expire in a very short time, usually one year. After the certificate expires, the signature is considered to be legally unreliable. Credit-card transactions though, may need one year to be considered firm and non-repudiable. In Germany, for example, legal documents (eg, a digitally signed cert or document) may need to be verifiable for 35 years -- in other countries this limit may be as low as five years, but still much larger than a CA certificate lifetime. Wills, hardware sales, patent licensing and almost all other acts that may require a signature usually imply duties, rights, warranties, liabilities, etc. that spill over the one year mark. Thus, this issue is a fundamental current difference between legal digital signatures and legal handwritten signatures -- which must be discussed and bridged if we want to allow e-commerce to be commerce. This point has received no specific attention from CAs and current CA legislation, to the author's knowledge, and in fact, it is considered only solvable by a series of frequent and costly certificate overlaping and updating, which must involve all parties and which opens several doors for attacks. Can we avoid to let e-commerce deals expire with the certs that signed them? The target is clear. Since digitally signed documents neeed to be confirmed *in the future*, then certificates need to be verifiable also *in the future*. Further, since the *future* is defined by business law, it may be from 5 to 35 years. Thus, any provider of security services such as a CA that provides certificates which fulfill the legal role of a signature MUST provide services which have _methods_ adequate to purpose -- if it needs to walk like a signature, quack like a signature, then it needs to be verified within the legal lifetime of a signature. Such legal need is all too common in traditional commerce -- hence protected by existing laws. To discuss this issue, I initially call attention that, as with any business, CA's are legally obliged to maintain records of their transactions, expired warranties and fullfiled liabilities to the extent mandated by local law. Which is usually from 35 to 5 years as mentioned and, does NOT depend on a CA's CPS or any special legislation. Thus, the availability of cert and CRL records can be legally demanded from public CAs by customers or by any user, even after cert expiration, for the legal book-keeping time. This fact is used in a simple solution to the discussed issue, called passive certs, aka zombie certs, as the author and colleagues have recently discussed [1], [2] -- both for passive CA certs as well as for passive subscriber certs. What is a passive cert? A passive cert is a non-revoked cert for a public-key, for example an ordinary X.509 cert, which however had its associated private-key securely destroyed. Passive certs may begin their lives as ordinary active certs and turn into passive certs upon the cert's expiration, when its associated private-key is destroyed. Since it has no private-key, forgery of any documents signed by that cert is not possible -- within cryptographic limits. Further, the cert does not need any new CRL lists for future behavior, only for past behavior (when it was still active). In other words, a passive CA cert is just a CA cert that is no longer supported by the CA and which the CA no longer uses for signing new certs. However, it had a useful life and did sign certs which can still be verified -- they can be relied upon to some extent (ie, they can be trusted). The same applies to subscriber certs. Regarding CRLs, if a now passive CA cert was not listed in any CRL lists issued by that CA until its expiration date then this is an affirmation by that CA to the effect that the now passive CA cert remained valid until it died to the CA and that the CA potentially used it for signing until it expired in the CA time zone. The same applies to subscriber certs. Thus, passive certs can be relied upon, for a long time and with high-reliance since forgery does not depend on operational factors any more. The reliance issue has three main aspects. A subscriber/user can rely upon a passive CA cert for: (a) cryptographic verification of any cert signed by the passive CA cert during its lifetime, which lifetime can be its validity period or a shorter span as given by past CRL lists, (b) legal warranty by the CA to the subscribers, according to the CA's CPS and as mandated by general law, regarding correctness of the now passive CA cert, during its lifetime as an active CA root cert, (c) legal warranty by the CA to the subscribers, according to the CA's CPS and as mandated by general law, regarding correctness of any cert signed by the now passive CA cert, during its lifetime as an active CA root cert. Which is not bad at all. Item (a) is based on current cryptographic knowledge and warranties provided under (b) and (c) are the same as CAs offer to subscribers, with active certs. For subscriber passive certs, simialr reliance and legal warranties items apply -- see [1], [2], So, for subscribers and users, active and passive certs are equally reliable and warranted by the CA. There is no need for new CRLs -- all needed CRLs were already issued. Perhaps, this is even more reliable since all issued CRLs should have had enough time to propagate an be known. This is what makes passive certs more than just cryptographically useful (which they are, irrespective of any CA's CPS and even though they were not foreseen in X.509). Because CA's can be legally required to keep records of their transactions and issued documents for the legal book-keeping time. So, a CA must inform -- not necessarily on-line -- if cert X was ever revoked, even if cert X is currently expired. What is the bottom-line here? To allow certs to be useful for legal tasks -- such as for e-commerce -- one needs to be able to verify signatures that were done when the cert _was_ valid. However, the digital signatures did not decay to a blob-state but are there, perfectly verifiable. And, perfectly legal. The solution to e-commerce's short-time cert expiration problem is thus immediate. It depends on already legally required cert and CRL registries, for CA and subscriber certs, for any expired non-revoked certs that a relying-party or a subscriber decides to use as a passive cert. The issue of passive certs use does NOT depend on the CA or further laws in any way -- it is entirely in the hands of the user, today. The only need is however to develop software tools that are able to automate passive cert management -- as Meta-Certificates are being designed to fully express [3]. I further examplify the importance of the passive cert for e-commerce by presenting what might be otherwise considered "impossible": a 100% protected digital signature (at least, within crypto limits). It is a signature verified by a passive cert which is publicly available in several independent places, and which had its private-key securely destroyed after N signatures -- which are then 100% protected against forgery. To summarize and regarding X.509, the arguments show that timewise invalid certs (passive certs) that were never revoked are just timewise invalid for signing -- not for verifying documents signed within its lifetime. And, paradoxically, such passive certs are inherently safer than X.509 timewise valid certs -- which have their private-key still in danger. Comments are welcome. Cheers, Ed Gerck ------------ References: [1] "Zombie cert" thread in cert-talk, archives at http://mail.structuredarts.com/cert-talk [2] "Zombie cert" thread in mcg-talk, archives at http://mcwg.org/mcg-mirror/emails.htm [3] http://mcwg.org/mcg-mirror/mcs97.htm ______________________________________________________________________ Dr.rer.nat. E. Gerck egerck@mcwg http://mcwg --- Meta-Certificate Group member, http://mcwg.org/mcg-mirror ---