http://info.cern.ch/hypertext/WWW/Shen/ref/shen.html
Shen will be distributed as part of libwww. There will be
multiple distributions though since some of the encryption algs
are restricted.
Going through proxies should work, however it needs testing out, I
still having problems with big/little endian machines at the moment.
I will be adding the proxy tests to the regression library as soon
as I get the DecStation (little endian)code to work.
On the key distribution front. I think we need a portable standalone
certificate in a readable form. PEM certificates are not very user
friendly. I want something of the form:-
Originator-ID: w30/security/hallam
Uncertified-Key: RSA,ASWEGQ$W#TYqweuhrgqjh3g47524dsfghf2345c765===
MIC-Head: RSA,RSA-MD5,qw4uyt@AC#%Y*bcwagaw3jk23cb5iuyejhgcwaety ===
Ie keep it transparent and simple. This allows a few more games to be
played. Lets consider adding a second format for POSTing a form based
on the RFC-822 format headers. The result is an ascii `certificate' which
is readable. It can be signed as a separate operation to produce an object
that can be stored conveniently, sent to a third party for authentication
etc.
[yes the tags all need lots of work to make them sensible...]
I don't like the way that PEM tries to make everything opaque by sealing it in
ASN.1 UUencoded forms. Even the originator Id which is an ascii object gets
this treatment. If we want to use ASN.1 I would prefer to develop a variant
HTTP-A that was all ASN.1. Its not a big job actually since we can retarget
the synth for the MIME parser once we get the new parser integrated.
-- Phillip M. Hallam-BakerNot Speaking for anyone else.