I think we can agree on the difficulty of social adoption of signing devices when they are to be used by humans. It was much easier to "invoke type theory" - when only machines were involved. Machines are easy to design for.
Concerning presumptions, there are some interesting issues, that do influence the design of a cardedge that involves public key (signing) technology.
In the US, the core presumptions concerning validity do not change, from traditional to e-signatures. The US Act broadly aligns with the UNCITRAL model law (as do the UK admininistrative regulations and the EC signature directive) and codifies the principle that
"While E-SIGN overrides both state and federal writing and signature requirements, it does not change the underlying, substantive law. It specifies that Title I of the Act does not "limit, alter, or otherwise affect any requirement . . . relating to the rights and obligations of persons" that is imposed under other law "other than a requirement that contracts or other records be written, signed, or in nonelectronic form." (Wiittie and Winn, 01)
If I remember right, from a few years ago, the original German digital signature law (which predated UNCITRAL) did alter the presumption rules for the two cases. However, the argument gave way in UNCITRAL, under the desire to uphold the doctrine of functional equivalence.
The German rule was never tenable, in my view. I remember once briefing the Head Postmaster of Hong Kong (a very important person... in China) on a related issued concerning presumptions; based on the consequences of that post offices policy of not processing revocation requests over the weekend for the certs that accompany the citizen's smartcards.
"So,... your citizen's e-signature, on an e-contract, when construed under the English Statute of Frauds (1633), and using the post office smartcard/certificate,. so.. sir, it may or may not be valid, depending on whether there was a weekend in the way ..... such that there is a large difference in time between (a) when the notice of revocation was delivered to the post office by Ms citizen (absolving Ms citizen of liability) and (b) the time when this vital information might be distributed out to those who might rely upon the timeliness of the certificate/revocation notice for the evaluation of the certificate as evidence of the parties intent to sign."
Im sure I didnt use such formal language, orally, in the second part. But you get the point. He did. A million dollars later, we deployed a real time validation system for the cards/certs. Im not sure what happened to it. it was supposed to go live in Malaysia, singapore and HK. Possibly Thai Post, too.
You cannot alter such a fundamental presumption such as the burden for validating signatures, when the critical infrastructure upon which its equities depend simply cannot cope!
From: Christian Schneider <[EMAIL PROTECTED]> Reply-To: MUSCLE <[EMAIL PROTECTED]> To: MUSCLE <[EMAIL PROTECTED]> Subject: Re: [Muscle] XCard documentation? Date: Fri, 07 May 2004 10:17:26 +0200
Peter Williams wrote:
Yes and no - to the issue of :"knowing (i.e. seeing) what being signed". Im not sure what my feeble relatives would make of it, in the few minutes a day their brain is not addled by illness. Doctors and lawyers have to face this issue, at the harder end of what is obviously a subjective process, when attesting to whether or not the patient "actually signed", when waving their hand in the general direction of their attorney-in-fact.
That�s right of course. I just recently read an article about normal signatures vs eletronic signatures. It stated that when you have done a handwritten signature the other side has to prove it�s yours and it was willfull signed by you. If somone brings on a document signed with your private key you have to prove it�s not signed by you.
Concerning the much easier topic of designing security boundaries for smartcard CPUs, our more immediate problem in muscle, the doctrine went like this. If you use machine-only readable coding (like DER), and the coding is based on strong type theory, you know from the abstract syntax what you are signing. Put another way, if the device cannot decode the stream according to the X.509 ASN1. types, it should not sign it. This used to be one of the distinguishing criteria defining high vs medium assurance CAs.
Ok so you could build a special function on the card edge to sign certificate requests. But there are so many other documents that you can�t identify them all. And even if you do how can the cryptodevice tell you, the user, that it has detected the right or the wrong type of document. If you have a trojan on your system it can manipulate any output of your applications.
So if you want a general signing method and your cryptodevice has no way to display you what you are signing it doesn�t really matter if it�s a hash or a document. A hash is then just a small document that is just as obscure to the device as everything else it gets.
This is why I said in the original spec: dont even bother decoding it (the DER-encoded cert)....so as to save some time. One ought to do such decoding, but in a v1 code base one need not - a concession to doctrine so cleartext keys get addressed. That latter goal was more critical AND more urgent than any engineering doctrine.
Even if you would decode the cert what would you win? The cryptodevice can not show the user in a safe way what it has learned from decoding it.
best regards,
Christian
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
