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
