Re: [pki-guidelines] Re: WebSign encryption considerations

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

Arshad et al.

Secure e-mail supports the stuff you want today.  Message encryption
is mainly used in peer-to-peer relations where it actually works quite well.

Regarding standards I guess it is fairly related to product development,
you have to carefully select features and make sure that they fit the
mainstream.  And you must also be sure that features are implementable
in such away that interoperability is achived.

Since you have apparently settled for the untrusted web server scheme,
you must also realize that this is pretty far from current uses of web signing
which is about "accepting" (or rejecting) a signature request from a more or
less trusted service provider like when:
- Signing an on-line bank transaction
- Signing an appointment with a doctor, lawyer, garage etc.
- Signing an EUA
- Signing a tax declaration
- Signing up for a membership

In all of these cases the actual document to sign is created in an interactive
process with the service provider.  If there is no interactive process, there
is little point in using the web.  But you cannot have a meaningful interactive
session with an untrusted service provider IMHO.

Due to this, I see that the specification logically falls into two pieces, one
simple and existing, and one which I currently don't see how it could be done.

thanks
Anders


----- Original Message ----- 
From: "Arshad Noor" <arshad.noor@strongauth.com>
To: "PKI Application Guidelines" <pki-guidelines@lists.oasis-open.org>
Sent: Wednesday, September 07, 2005 02:56
Subject: Re: [pki-guidelines] Re: WebSign encryption considerations


Thanks for your response, Anders.  See responses below.

Arshad

Anders Rundgren wrote:
> Hi Arshad,
> Thanx for the write-up.
>  
> I believe though you have left out an important issue in your write-up 
> and that is the function and trust, your model puts in the /web server/ 
> application.
>  
> Variant #1:
> That is, /if the server is trusted there is no need for bringing down an 
> elaborate encryption scheme as this part can be handled very easy //by 
> the server before doing the eventual filing/.  A further advantage, is 
> that the exact method for locating and selecting encryption keys can be 
> defined by each web app as required by the local environment and 
> policy.  And still only relying on existing web technology.
>  
While I agree that in the current model (using TLS, the
server is trusted by default), there are business reasons
where this may not always be true:

1) If the application is being hosted by an ASP, but the
   data is confidential enough that the owner of the data
      does not want it to be in the clear for even a second
   at the ASP site.  I'll give you an example: even though
   the pricing and model is compelling, I still do not use
   Salesforce.com to maintain my CRM information - simply
   because I do not trust Salesforce.com or its people to
   protect my data.  However, if the ASP allowed me to
   use my company's encryption key(s) to protect the data,
   so it could be accessible only to myself, then I might
   be persuaded to use it.  It is possible that even within
   a company that is operating applications for its own use,
   such business requirements will become standard one day,
   where one department is disallowed from seeing another's
   data; in which case, a server may not always be trusted
   and there will be a need to encrypt the transaction the
   moment it leaves the browser;

2) As more companies start encrypting data, regulatory
   requirements will become more sophisticated as marginal
   companies, inadvertently or deliberately, flout the law
   and implement weak encryption solutions (I'm seeing some
   vendors do this right now).  The law might now establish
   standards that the data must be encrypted from the moment
   it leaves the client browser and may even specify the
   sets of keys that should be used.  While this may appear
   far-fetched today, its conceivable that this could be
   reality in 5 years as we witness more companies disclose
   breaches despite encrypting data.


> Vaiant #2:
> If OTOH the server is not trusted for "seeing" user data, but is simply 
> a passive proxy, we are not really talking about an interactive web 
> application but rather a dedicated "secure data filing system" using 
> HTTP as delivery mechanism.  Such a scheme would only use WET 
> signatures.  Theoretically such a scheme could be combined with to a Web 
> Sign standard intended (my goal at least) for "signing off" static 
> (DRY) data.
> However, I would not do that as there would be hardly any common 
> pieces.  Not even signature invocation would be shared as in Web Sign it 
> is the *server* that requests you to sign, while in a filing system, it 
> is likely to be the opposite, it is rather *you* who hit the 
> I_want_2_file_button.  /Also note that the s//ecurity officer's keys 
> would require an additional (but presumably transparent) filing as well./
>  

I'm not sure I follow your definitions of a WET/DRY signature
in the electronic world.  Perhaps you can explain it, although
I'm not sure the terms are meaningful in an electronic world
since it can cause so much confusion.

> Summary: I believe that XML encryption can be supported and may indeed 
> have some utility as well, but you should try deciding which way to go.
>  
While not necessarily immediate, I see business reasons why
transaction encryption is a good idea - but I'm willing to
be persuaded otherwise.

Are there others on the forum who would like to share their
opinion on whether this is worthwhile pursuing?

Arshad Noor
StrongAuth, Inc.


> Decryption
> ========
> The things you say about decryption give me cold feats.  Either you 
> receive data like in e-mail and decrypt using your own key.  Strong 
> authentication is not really required but is does require a matched 
> key-pair, something which is pretty incompatible between filing systems 
> and user key renewals.  BTW, form decryption would then be another new 
> and complex function required by your scheme.
>  
> OTOH, If we rather talk web and trusted servers, it should IMHO be fully 
> sufficient with StrongAuth :-)
>  
> If people want to build systems that are unmanageable by filing data 
> using volatile employee keys, please be my guest, as long as you don't 
> ask me to recreate any forever lost encrypted data!
>  
> If in spite of this, encryption scheme #2 really is your cup of tea, you 
> have a truly major specification job in the pipe-line.  I suggest that 
> you let your clients do some of it.  The comparatively "trivial" Web 
> Sign spec took in fact six whole months to figure out and it is still 
> far from perfect.  A requirement to build on formats not yet being 
> standard (in I.E.) like XForms, or adding tags to HTML is something I 
> personally don't want to engage in as it will likely be obviated by 
> /Microsoft's Avalon that in fact can do all of the things you require 
> right now/.
>  
> The WASP proposal may appear "conservative", as it does no attempt to 
> change the way the web currently works.  It rather does the opposite by 
> trying to smoothly align itself to the existing web by effectively 
> challenging the venerably OK button with a digital signature mechanism 
> that in one take offers:
> - a "user procedure"
> - a strongly authenticated user
> - a cryptographic binding to a view
>  
> There are thousands and thousands of applications that can benefit from 
> upgrading from OK to signatures.
>  
> regards
> 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>>; "PKI Application Guidelines" 
> <pki-guidelines@lists.oasis-open.org 
> <mailto:pki-guidelines@lists.oasis-open.org>>
> Sent: Friday, September 02, 2005 19:39
> Subject: [pki-guidelines] Re: WebSign encryption considerations
> 
> 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>
>  > <mailto:arshad.noor@strongauth.com>>
>  > To: "Anders Rundgren" <anders.rundgren@telia.com 
> <mailto:anders.rundgren@telia.com>
>  > <mailto:anders.rundgren@telia.com>>
>  > Cc: "Stephen Wilson" <swilson@lockstep.com.au 
> <mailto:swilson@lockstep.com.au>
>  > <mailto:swilson@lockstep.com.au>>; "Steve Hanna" <shanna@funk.com 
> <mailto:shanna@funk.com>
>  > <mailto:shanna@funk.com>>; "Sabo, John T" <John.T.Sabo@ca.com 
> <mailto: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>
>  > <mailto:arshad.noor@strongauth.com>>
>  >  > To: "Anders Rundgren" <anders.rundgren@telia.com 
> <mailto:anders.rundgren@telia.com>
>  > <mailto:anders.rundgren@telia.com>>
>  >  > Cc: "Stephen Wilson" <swilson@lockstep.com.au 
> <mailto:swilson@lockstep.com.au>
>  > <mailto:swilson@lockstep.com.au>>; "Steve Hanna" <shanna@funk.com 
> <mailto:shanna@funk.com>
>  > <mailto:shanna@funk.com>>; "Sabo, John T" <John.T.Sabo@ca.com 
> <mailto: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>
>  > <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>
>  > <mailto:donald.hildebrand@navy.mil>>
>  >  >>To: <anders.rundgren@telia.com <mailto: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> <mailto:donald.hildebrand@navy.mil>
>  >  >>
>  >  >>-----Original Message-----
>  >  >>From: pki-twg@nist.gov <mailto: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
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >
>  >  >