Re: Comments on [MANDATORY cert discovery capabiity]

[Dwight Arthur <dwightarthur@xxxxxxxxxxxxxx>]

Peter Williams wrote:
> George Capehart wrote:
>> Personally, I couldn't imagine the circumstances under which I'd
>> accept an ActiveX control that wanted to help me do *anything* with
>> a cert.  Boy, talking about opening one's kimono . . . wanna make a
>> copy of my private key(s) while your here? PKIs are all about trust
>> and the ActiveX security model is essentially: "Trust me on this."
>>  Sorry, I'm not quite there yet.  8-)
> <snip> I would agree that its important for any user/buyer of crypto
> to know and trust the source of his/her virtual machine, as much as
> the operating system. In some implementations, the viritual machine
> and OS are one and the same. The assurances, due to evaluation, of
> the OS kernel and reference monitor (e.g. NT) and reliance on
> CPU-based  privilege  mode enforcement can carry over to assure the
> VM to the same level as the OS,  to all intents and purposes. ...
> A site's firewall can scan the activeX control's java opcodes and
> ensure they meet "security requirements" beyond mere well-
> formedness, before the control enters the enclosure for execution.

This may be outside the domain of PKIX. I am concerned about the idea of
an applet or control that would (a) display some transaction on a
browser, (b) solicit the subject's consent to the transaction, and (c)
create a signed message confirming the transaction. Even if this were a
teansaction confined to a JAVA sandbox or equivalent
security-constrained environment, how would the subject be able to
verify that the transaction's terms and conditions as described onscreen
match those in the signed message? If a rogue applet adds on usurious
interest, outrageous handling fees, etc, how would the consumer
repudiate this message in light of the consumer's signed, dated, and
perhaps notarized signature? I believe that the degree of trust based on
the privacy of a private key is potentially eroded if externally
provided applets are able to create signatures without the subject's
knowledge of the content of the signed message.

It's an attractive idea, having a firewall scan for bad applets. But how
would you code a filter that would allow ePayment modules that fully
disclose the transaction's terms & conditions and deny those that add
undisclosed terms to a message?