Re: WebSign encryption considerations

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

Anders,

After this message, I'm going post responses on this subject to
just the Applications Guidelines SC mailing list.  I have added
you to it, so you should be able to post to it immediately, I
imagine.  I know Steve is already a member of the AGSC, but if
John Sabo and Stephen Wilson are interested in this thread, they
should really join the AGSC.

OK, now for the discussion on the need for XML Encryption within
the context of transactions executed using a web browser:

Businesses are increasingly aware of the vulnerabilities of their
infrastructure.  The breaches disclosed in the US in 2005 alone
have been sufficient to galvanize many organizations to start
doing something about it.

One of the key elements of their risk-management strategy is to,
obviously, encrypt sensitive data content.  Given the constraints
in technology today, most companies are focused on encrypting
content with their own keys.  However, I foresee a period in the
future where increasing risk-management is going to demand more
fine-grained control over who sees sensitive information, as well
as the desire to protect the information right from the source
point (notwithstanding SSL on the wire).

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.

As the browser processes the form, it will perform the appropriate
functions with the appropriate set(s) of encryption keys that are
now part of the form.  I envision the end-user's own encryption
key, an application key, an enterprise Security Officer key, as a
set of keys that might be embedded in the form for encrypting
content.  This allows for an authorization model that allows
user-data to be displayed to the right user (if they have their
decryption key), as well as the company to decrypt the content
using either the application's decryption key or the enterprise
SO's key.

While there will be other business and policy models, I believe
that this capability will be desired by many companies as this
technology capability begins to dawn on them.  As such, I also
believe that if we're embarking on an effort like this today,
we should not ignore XMLEncryption.

Arshad Noor
StrongAuth, Inc.


Anders Rundgren wrote:
> Arshad,
> I hope that you feel better know.  We can BTW talk your time (EST?) as well.
>  
> Regarding the write-up on XML encryption, I'm eager to know what you had 
> in mind.  I do not want to discourage you but I have indeed made a 
> write-up myself (enclosed), where I dismiss this particular feature.  
> /But I do not have all scenarios at hand/.  I though would like to 
> emphasize that at least my goal is not to compete with PureEdge, Adobe 
> etc. but rather providing a light-weight scheme for "the masses".  It is 
> important to understand that although XML Security supports any weird 
> scheme you can think of, a WebSign standard is really an application, 
> and is therefore subject to /major constraints/ if interoperability is 
> to be achieved.  I have though not yet identified any limitations in the 
> WASP proposal that cannot equally well (and actually often /much/ 
> better), be handled on the server side.  That a PureEdge executable is 
> 50 times bigger than the WASP portal emulator 
> (http://sid.the-demo-bank.com/eGovernment) gives some indications of the 
> differences between a fat and a thin client approach
>  
> *WebSign encryption considerations*
>  
> A potential WebSign standards effort should IMHO not deal with explicit 
> message encryption, as I believe this is a less generally 
> useful "feature". It is rather the /provider/ (your employer, your bank, 
> your government), /that sets the policies, including encryption,/ for a 
> specific web application and acts accordingly.   In an off-line e-mail 
> scenario you don't have this option and due to this, policies 
> effectively becomes a client issue.  /However, finding the proper 
> encryption key to use is a major problem that clients should not have to 
> deal with in a properly designed web application/.  To protect contents 
> against the web application provider's eyes seems like an odd measure, 
> unless we are actually talking about WebMail.
>  
> Secure WebMail is though an entirely separate issue as it must conform 
> to S/MIME rather than using XML security.  In addition, if 
> Secure WebMail is to be used with untrusted mail providers, it requires 
> the use of Wet Signatures (open forms), and "semi-fat" clients, as the 
> providers MUST NOT (if message encryption is to be used), be able to 
> "see" any clear text data, including possible attachments.  The latter 
> means that the standard way to handle attachments today, "upload", 
> simply is not an option.  Secure WebMail is due to those 
> constraints, IMO /another/ [possible] standardization effort.  Even if a 
> Secure WebMail standardization effort indeed were launched, I would not 
> build such a scheme for untrusted providers as the "market" for such a 
> scheme seems limited when standard e-mail clients comes for free and 
> already handles this scenario.  The possible use-case with public 
> computers do not align well with encrypted content as public computers 
> cannot be assumed to be safe for communicating truly classified or very 
> private information, for that you should use your mobile phone or 
> PDA, "model 2007" with built-in TPM (Trusted Platform Module) support.
>  
> Comments?
>  
> Anders Rundgren
> Working for a major US computer security company but here acting as an 
> individual
> ----- Original Message -----
> From: "Arshad Noor" <arshad.noor@strongauth.com 
> <mailto:arshad.noor@strongauth.com>>
> To: "Anders Rundgren" <anders.rundgren@telia.com 
> <mailto:anders.rundgren@telia.com>>
> Cc: "Stephen Wilson" <swilson@lockstep.com.au 
> <mailto:swilson@lockstep.com.au>>; "Steve Hanna" <shanna@funk.com 
> <mailto:shanna@funk.com>>; "Sabo, John T" <John.T.Sabo@ca.com 
> <mailto:John.T.Sabo@ca.com>>
> Sent: Tuesday, August 30, 2005 21:33
> Subject: Re: DoD interest in Web Sign
> 
> Anders,
> 
> I have to apologize for not getting back to you on this, but
> I came down with a terrible flu Wednesday of last week.  It
> took everything I had to just finish my work and head back
> to the US.  I'm still getting over it, but am feeling just a
> little better now to respond.
> 
> I'm sorry we couldn't talk last week, but I will attempt to
> address all your e-mail threads this week on this subject.
> If you are an OASIS member in god standing, I will add you to
> the Applications Guidelines SC mailing list so you can post to
> it directly and involve others on that SC in this discussion.
> Thanks.
> 
> Arshad
> 
> Anders Rundgren wrote:
>  > Absolutely!
>  >
>  >
>  > ----- Original Message -----
>  > From: "Arshad Noor" <arshad.noor@strongauth.com 
> <mailto:arshad.noor@strongauth.com>>
>  > To: "Anders Rundgren" <anders.rundgren@telia.com 
> <mailto:anders.rundgren@telia.com>>
>  > Cc: "Stephen Wilson" <swilson@lockstep.com.au 
> <mailto:swilson@lockstep.com.au>>; "Steve Hanna" <shanna@funk.com 
> <mailto:shanna@funk.com>>; "Sabo, John T" <John.T.Sabo@ca.com 
> <mailto:John.T.Sabo@ca.com>>
>  > Sent: Wednesday, August 24, 2005 21:10
>  > Subject: Re: Fw: DoD interest in Web Sign
>  >
>  >
>  > Anders,
>  >
>  > I will get you a cell phone number tomorrow; perhaps we can talk for 
> 15-20 minutes on Thursday or Friday? 
>  >
>  > Arshad
>  >
>  > ----- Original Message -----
>  > From: Anders Rundgren <anders.rundgren@telia.com 
> <mailto:anders.rundgren@telia.com>>
>  > Date: Wednesday, August 24, 2005 10:31 pm
>  > Subject: Fw: DoD interest in Web Sign
>  >
>  >
>  >>Gentlemen,
>  >>
>  >>For your information, but not for forwarding, see response below.
>  >>
>  >>I hope that you consider a PKI-TC action item.
>  >>As it is pretty complicated I believe a high-profile TC is a
>  >>necessity.
>  >>Microsoft will probably not participate (they claim Windows Vista
>  >>has what
>  >>it takes), but OTOH they did not support SAML 1.0  either but
>  >>later become
>  >>as SAML-compliant as anyone else.
>  >>
>  >>Stephen, I haven't been able to identify any Asian Web Sign
>  >>std.  activities, have you?
>  >>
>  >>thanks,
>  >>Anders
>  >>
>  >>----- Original Message -----
>  >>From: "Hildebrand, Donald H CIV SECNAV" <donald.hildebrand@navy.mil 
> <mailto:donald.hildebrand@navy.mil>>
>  >>To: <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>>
>  >>Sent: Wednesday, August 24, 2005 16:12
>  >>Subject: RE: Possible OASIS WebSign effort
>  >>
>  >>
>  >>Good Morning,
>  >> I work in the Office of the Chief Information Officer for the
>  >>Department of the Navy and currently serve as a Co-Chair of a
>  >>Digital Signature Interoperability Work Group chartered by the
>  >>Identity Protection and Management Senior Coordinators Group within
>  >>the Department of Defense.  I am very interested in the efforts
>  >>described in your email and would be willing to share the findings
>  >>and recommendations of our discussions within the Department of
>  >>Defense.  My contact information is provided below.
>  >>Thank you,
>  >>Don Hildebrand
>  >>voice:  703-602-6961
>  >>email:  donald.hildebrand@navy.mil <mailto:donald.hildebrand@navy.mil>
>  >>
>  >>-----Original Message-----
>  >>From: pki-twg@nist.gov <mailto:pki-twg@nist.gov> 
> [mailto:pki-twg@nist.gov]On Behalf Of Anders
>  >>Rundgren
>  >>Sent: Tuesday, August 23, 2005 11:24
>  >>To: Multiple recipients of list
>  >>Subject: Possible OASIS WebSign effort
>  >>
>  >>
>  >>
>  >>F.Y.I.
>  >>
>  >>There has recently been some discussions within OASIS regarding
>  >>the launch
>  >>of a TC for the purpose of creating a Web Sign standard.
>  >>
>  >>Web Sign: The ability for a user to sign a document or form in a
>  >>web browser
>  >>and having the signature submitted to a web server.  A minimal
>  >>such function
>  >>already exists in Mozilla Firefox in the form of "signText".
>  >>
>  >>Having worked with Web Sign concepts for several years, I am happy
>  >>aboutthe increasing interest in creating a standard, but I also
>  >>know that there are
>  >>huge scope issues to agree on including:
>  >>
>  >>- Document format(s)
>  >>- Signature invocation mechanism to use
>  >>- Wet or dry signature support
>  >>- Local signature validation/multiple signatures
>  >>- Encryption options
>  >>- WYSIWYS
>  >>
>  >>In case you are interested, please drop me a line.
>  >>
>  >>regards
>  >>Anders Rundgren
>  >>Working for a major US computer security company but here acting
>  >>as an individual
>  >>
>  >>
>  >>
>  >>
>  >
>  >