Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: [Muscle] XCard documentation?
From: Christian Schneider (c.schneiderscram.de)
Date: Fri May 07 2004 - 03:17:26 CDT
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.
Muscle mailing list