Before I "sod off", I would offer the following comments:
By WEB, do you mean MOSAIC, FTP, telnet, or all the above? Certainly, e-mail
is only a small part of the internet. One point I was trying to make is that
there is a degree of commonality in the security requirements of e-mail, MIME,
http, ftp, and other applications. We should be able to define a common
security encapsulation usable by these applications. I listed the reasons
for
this in my earlier message.
We should have interoperability at the key certificate level certainly, and
there should be no glaring incompatibilities. But the idea that there should
be
a common encapsulation is simply wrong. HTTP is moving towards being an
interactive protocol, it is in any case BY NON-NEGOTIABLE DEFINITION 8-bit
clean. The Web attitude to 7bitters is simple "sod off - we don't need you".
I
don't think that the eMail community can afford that attitude. Putting text
into > Base64 or cannonicalising it is simply irrelevant in the Web area.
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.
There are a number of applications that may be classified as "store and
forward"
that share security requirements. I see no reason why there should not be a
common encapsulation of these features and believe the benefits I stated are
still valid.
Agreed. I think successful, consistent implementation of the secure versions
of these products is critical to their success. I also agree this is a
cumbersome problem. That's why we shouldn't solve the problem more times
than
we have to.
But where is the evidence that we have "solved problems"? A problem is not
solved until the product is in ubiquitous use. PGP is the only mail privacy
product that can claim anything like that and even then the usage is
miniscule.
I didn't claim that the problem was already solved. I said that we shouldn't
solve the same problem repeatedly for similar applications. Otherwise, we'll
never see "ubiquitous use".
The real PEM/WWW concern is that browsers be able to reuse the maximum amount
of > code between the Mail privacy and HTTP privacy modules. Taking out a few
calls
to do base 64 or canonicalisation lossage is not difficult.
Yet in your first paragraph, you say "the idea that there should be a common
encapsulation is simply wrong". Or does the level of encapsulation vary
across appliation types?
I think there are (or were) reference implementations of PEM. The thing that
made it difficult was the CA management and export issues. This was the
other
point in my first message.
PEM certificate management and trust model is related only to email. It is
sufficient to know that the person is or is not the who they claim. The Web
will
be used for much more complex operations and the question of CA liability
comes
in. The binary trust model of PEM and PGP is completely unworkable in this
arena. Authenticating parites must have a mechanism that allows them to limit
the extent of their liabilities. In an institutional setting this becomes
even
more complex.
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.
Export issues are practically irrelevant so far as the Web is concerned. Most
of > the work on the common library is currently being done in Geneva.
I assume the EIT work has been done in the U.S. and will continue. Even if all
the encryption work originates in Geneva, there are still countries that limit
import of encryption software. Once inside the U.S., country of origin is not
relevant. An export license is required for any type of export. That includes
personal use while travelling. One final consideration is re-export by
resellers
who may want to include a product that uses encryption. If the reseller ships
from the U.S., he needs an export license. I assume you would want to
encourage such a use of your product.
Phil Smiley