[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Stateless security

• To: Rich Salz <rsalz@d...>
• Subject: Stateless security
• From: Mark Baker <distobj@a...>
• Date: Thu, 14 Apr 2005 10:25:25 -0400
• Cc: "xml-dev@l..." <xml-dev@l...>
• In-reply-to: <Pine.LNX.4.44L0.0504140834300.24680-100000@s...>
• References: <20050414040017.GI9251@m...> <Pine.LNX.4.44L0.0504140834300.24680-100000@s...>
• User-agent: Mutt/1.5.6+20040907i

Rich,

On Thu, Apr 14, 2005 at 08:41:54AM -0400, Rich Salz wrote:
> >  The
> > issue will be whether the larger message size in the stateless
> > solution will be acceptable or not.  How much state are you're talking
> > about?
> 
> Let's assume RSA with a key size of 2K bits, maybe sometimes 4K.  A
> signature is the same as the key size, so you're talking 256 or 512 bytes,
> plus the data being signed, of coruse.
> 
> At least one certificate will have to flow in each direction.  A
> certificate is signed and has a couple-K of data, so call it 2-4Kbytes
> per cert.

Ok, thanks.  I don't know enough about the use cases you have in mind,
nor the security mechanisms themselves to know how genereal an approach
this might be.  But assuming 2-4K as a worst-case for the general case,
is it such a big deal?  I expect many B2B messages to be an order of
magnitude (or two or three) larger than that in practice.

I can well imagine contexts in which the increase in message size is not
appropriate; "TCWA", The Canonical Web App (i.e. get an HTML page,
display it), comes to mind.  But this cost also comes with advantages
too, in particular, for this discussion, security advantages; that
messages whose semantics are functions of information only in the
message, are immune from certain kinds of man-in-the-middle and
subversion attacks.  The ability to recover from partial failure -
reliability - is improved too, for the same reason.  Plus, as the
message is more self-descriptive, its ability to be archived, used in
long-running asynchronous transactions, etc.., is also improved.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

• References:
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Mark Baker <distobj@a...>
  • Re: What Does SOAP/WS Do that A REST System Can't?
    • From: Rich Salz <rsalz@d...>

• Prev by Date: Anti-Evil
• Next by Date: Re: Is the XML Schema Test Collection still alive
• Previous by thread: Re: What Does SOAP/WS Do that A REST System Can't?
• Next by thread: Re: What Does SOAP/WS Do that A REST System Can't?
• Index(es):
  • Date
  • Thread