its becoming clear to me that the trend by the ISVs for security handling
is going against communications designs, into info stream designs.
In this cryptic comment (and, apparently, this is a professional, internet
thing to do) I mean that for a for a word/excel/foo document type, that
an (networked) OLE server can perform the privacy-enhancement facilites (using
MSP;PEM;S/MIME;PGP-MIME mechanism, who cares!) and the resulting detached
signature(s) can be placed within the compound file conveying the main
content as
an embedded, though separate, stream. The OLE server is responsible
for re/creating the correct OLE/message format for the enhancement protocol,
where detached signatures processing are not natively supported by
PGP, PEM, MSP etc.
We can pursuade the OLE community to standardise the format, names and
types of the (semi-)detached security streams within the OLE compound
file for the protected file to obtain platform-independence. The formats
definitions would reference PEM, S/MIME, PGP, etc.
Problematic Internet messaging handling of course is then irrelevant, and
we all know a typed document can be conveyed simply by using the simple
mime type registration. In this way we place all the intelligence at the
end-system, something many Internet Savy (and security) people advise.
When nested information object protection is required, one relies not
upon the MIMEness of multiparts, or the Content-Domain of PEM, one
relies alternatively on the industry-standards and platform-indepedence
of OLE (and compatible equivalents on UNIX and MAC) to embed the
security protocol elements into existing information streams.
So, perhaps, my big point is this: lets ignore the secure mailness
and concentrate on secure information handling. The various formats
can compete as OLE servers in the market. We could standardize the
OLE (automation) verbs, so that containers are independent of the
interface of the component server object; this would be sensible.
Alkternatively, we could standardize the format-specific interfaces,
and then allow containers to negotiate with the protection-object
for the compatible capabilities.
If we the vendors solve the document-centric information security problem,
we can get something buyable out there. Then the messaging security problems
(protecting the MTS, recursive message enclosures) can be sorted out in
the well-accepted IETF standardization process over time.
Ive been evangalizing this process for a while now; it has had pretty
good uptake. Your own bias qualifies this direction
as Windows centric, or OLE centric. How platform-independent
and standardized OLE is in practice is debatable. The objects
people might be able to comment on OLE/CORBA compatibility, etc.
Thoughts?
Should pem-dev community perhaps standardize an OLE server interface,
for PEM, S/MIME and PGP-MIME?
We can act as an privacy enhancement implementors group again, now we are
free of formal IETF process for document-oriented standardization
activities.
Peter.