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.
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
security officer's keys would
require an additional (but presumably transparent) filing as
well.
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.
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" <>
To: "Anders Rundgren" <>
Cc: "Stephen Wilson" <>; "Steve
Hanna" <>; "Sabo, John T"
<>; "PKI
Application Guidelines" <>
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"
<
>
<mailto:>>
> To: "Anders Rundgren" <
>
<mailto:>>
> Cc: "Stephen Wilson" <
>
<mailto:>>; "Steve Hanna" <
>
<mailto:>>; "Sabo,
John T" <
>
<mailto:>>
> 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" <
>
<mailto:>>
> > To: "Anders Rundgren" <
>
<mailto:>>
> > Cc: "Stephen Wilson" <
>
<mailto:>>; "Steve Hanna" <
>
<mailto:>>; "Sabo,
John T" <
>
<mailto:>>
> > 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 <
>
<mailto:>>
> > 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"
<
>
<mailto:>>
> >>To: <
<mailto:>>
> >>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:
<mailto:>
> >>
> >>-----Original
Message-----
> >>From: <mailto:>
>
[mailto:]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
> >>
> >>
>
>>
> >>
> >
> >
