Re: [pki-guidelines] Encryption keys in Transaction PKI

[Arshad Noor <arshad.noor@strongauth.com>]

See below, Anders.

Arshad Noor
StrongAuth, Inc.

Anders Rundgren wrote:
> 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.
>  
	You've misunderstood the goal for E2E encryption, Anders;
	its not because the server is untrusted, but its because
	there is a business need to encrypt data from the moment
	of its capture and keep it encrypted forever (except when
	authorized applications decrypt it for use).

	The design pre-supposes that the user is connected to a
	server that he/she trusts.  How that trust is established
	is not a concern of this project.

> 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".
>  
	We are getting too deep into design details when we have
	not yet established the goals of this project.  However,
	if we assume that the client has connected with their
	signing certificate (using client-auth), the server can
	easily map the appropriate encryption certs into the web
	form at run-time, based on the signing-cert's DN.

> 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.
>  
	This architecture uses a plug-in.  Our goal is to avoid the
	use of a plug-in.  (Note: I implemented the worldwide PKI for
	the world's largest pharma company last year for SAFE, and am
	very familiar with this architecture).

> 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 goal of Transaction-PKI is to encrypt only the final
	message, where the transaction data needs to be persisted
	after submission.  Until the final message submission, the
	browser and application can continue to converse without
	using encrypted messages (if desired).

> 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
>  
>