Encryption keys in Transaction PKI

["Anders Rundgren" <anders.rundgren@telia.com>]

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