Minimize server state maintenance

[Philip Hallam-Baker <pbaker@verisign.com>]

Don't know whether it is a requirement or constraint (probably requirement]

[R-ServerState] Minimize requirement for server state maintenance.

The original design of HTTP required that requests be "idempotent". As a
result many Web server architectures do not support efficient means of
exchanging state between separate request handling processes. In the UNIX
world these are frequently handled as separate processes rather than as
threads. UNIX does not provide a standardized abstraction for efficient
interprocess communication. On a multiprocessor platform (e.g. web server on
ANYcast port) the processes may be on separate processors making
interprocess communication very costly, possibly leading to two tier
architecture need.

[R-ClientLogoff] Client should have means of disposing of auth credentials

[A-EncryptedSessionKey] Key identifier URI is encrypted key

A frequently used architectural hack is to construct a label for a symetric
key by encrypting the key and additional bound data under a previously
established exchange key.. For example if the key is 23ad fe93 and the
validity period is 2001-01-01 to 2001-02-01 the label might be prefix :
issuer data + base64( E( 23ad fe93 + Pack (2001-01-01 to 2001-02-01) , k))

This would make a very handy general purpose URN, we could register the NID
without too much hassle (it is now an IANA procedure). 

This would mean that we ended up with URNs of a form something like

URN:crypto-dns:saml.abcd.com:saml.xyz.com:12:239fzs9uawn3725a89y59a8w5h98wa5
h9==


The server can recover the session key at the other end without difficulty -
assuming that there is a pre-established shared secret. This is pretty easy
to establish out of band with a public key exchange or people can do it the
really hard way and hardwire keys.


I think this is a chunk that we should submit to the IETF as a general
purpose URN mechanism and refer to it in ??ML as an implementation option.


Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

Philip Hallam-Baker.vcf