Encryption keys in Transaction PKI

From: http://lists.oasis-open.org/archives/pki-guidelines/200509/msg00000.html I extract the following:

 

"I foresee a capability in HTML-forms 
or XMLForms that will allow application developers to embed the required 
encryption keys in the form (or more likely reference them within a publicly 
accessible LDAP server so they can be pulled down as the form is displayed on 
the user's screen), along with the policy guidelines (must be 3DES-CBC-SHA-256, 
etc.) as declarations in the form."

 

Since the whole reason for the end-to-end 
encryption requirement was that the server could not be trusted, I 
believe that a model where the very same server supplies or suggests encryption 
keys, is by definition "broken" security wise.

 

In addition, I wonder how the actual 
recipient is supposed to be assigned and how this is to be mapped to an 
encryption key.  We may indeed end-up having to rely on S/MIME 
certificates and e-mail addresses, further adding to my belief that this is 
really nothing but "Secure e-mail, V2".

 

A recent high-profile BioPharma PKI initiative using Web Sign: 
http://www.arcot.com/docs/SAFE_TPOC_FS.pdf shows a carbon copy of what I have 
suggested as a suitable scheme for Transaction PKI.

 

Message encryption OTOH, kills interactivity as you cannot 
have a conversation with a server if you can't talk with it. If 
somebody else can, would you please be so kind explain how.  Presenting an 
empty form (which is doable), is at least not my definition of an interactive 
(=web) service.

 

The most fundamental question still remains: Why would an 
IT-department setup a web server that is not to be trusted by its 
users?

 
regards

Anders Rundgren

Principal Engineer

RSA Security