From the experimental shttp spec published by EIT:
Secure HTTP has been designed to enable incorporation of various
cryptographic message format standards into Web clients and servers,
including, but not limited to, PKCS-7, PEM, and PGP. S-HTTP supports
interoperation among a variety of implementations, and is backward
compatible with HTTP.
Yep I know, I have been implementing/developing S-HTTP. The PEM encapsulation
is only really suitable for cases where the message was originally in PEM
form - I email fred and then fred wants to read his mail via an untrusted
Web server using a key local to the client.
Yes there should be interoperability but that does not mean that the protocol
is going to mandate BASE-64 encoded lossage. The protocol will not work unless
the line is 8-bit clean period. The PEM encapsulation mandates restriction to
7 bit. Thus when using S-HTTP the prefered mode is PKCS-7. PEM and PGP are
optional.
One of the reasons the Web works is that we don't have kludges in the spec to
support the 3 remaining CBS-6000 computers that had an EBSIDIC character set
and
a 27 bit word length. [We do support the Pentium however which has a
63.999999924 bit word length]
I disagree that the certificate and trust model relate to e-mail only. They
apply to any use of digital signatures. Certainly different applications will
have different trust levels but that doesn't rule out any given trust model.
It means the trust assumptions must be well-defined and clearly understood.
Unless there are attributes in the certificate that ca be used to limit its
validity they are inappropriate for use on the Web. In addition in the Web a
certificate need not be a key certificate, a certificate might be a reciept or
product activation key.
I assume the EIT work has been done in the U.S. and will continue.
Yes, but Alan and Co are producing modifications of a library of code that
originated here. In combining Shen and S-HTTP I amd creating a non US
implementation. The entry points for the secure library are identical to those
for the insecure one. It is not an "application with a hole" though, simply
highly modular software that provides a ubiquitous communications interface.
An export license is required for any type of export. That includes
personal use while travelling.
So Web users will need two copies, an insecure one and a secure one. As soon as
they touchdown in a country they suck up the secure version off the Web :-)
Maybe we can add a special command to dump the crypto libs as the machine
leaves
US airspace:-)
If the reseller ships from the U.S., he needs an export license. I
^^ Political correctness error.
assume you would want to encourage such a use of your product.
I was thinking it would be fun to wait until the Whitehouse people realise that
US companies are going to be at a huge disadvantage wrt selling their product
and wait to see the effects. If the US wants to give European developers a head
start thats fine with me :-)
Whats a mere 250,000 users anyway I'm more worried about the other 95% of the
population. :-) Hold on maybe you are right, maybe the 250,000 are more
worrying. Yes Dan Quaylee is running for President, they are definitely more
worrying.
Phill