>From: sandy(_at_)magellan(_dot_)TIS(_dot_)COM
>Subject: Re: limitations of mime-pem transformation
>Date: Fri, 30 Dec 94 12:31:26 EST
>>There is a (no-so-) subtle difference between one originator signing
>>twice, and two originators signing in some groupware application.
>
>I can see the difference. I maintain that two signatures by the same
>entity introduce the possibility of semantic confusion; one need not
>consider the more complicated case of multiple signers.
PEM is a one to many, and an injective function, with some variable
trust parameters. That this is not understood and upheld is
remarkable. but we can live with this. Lets see how.
Now Sandy, lets get practical in our WG.
I thought about all this hard last night, most of my sleep time
infact. I came up with something practical. Tell me if this is an
intellectual and practical compromise for the whole debate, including
the messaging, message content architecture, and security semantics of
these two latter concepts. This is after all what we are really
considering. if its bullshit, then feel free to so label. I can
join the rest of the crew in the field.
I see a simple coexistance of PEM and MIME/PEM, in which each offers a
distinct quality of service, and fits seamlessly into MIME multipart
constructs. MIME/PGP fits there aswell offering service layer 3. By
keeping the architecture and semantic models separate, the cause for
debate goes away. IT is recognised that just as a non-MIME IPM service
cannot interwork much with a MIME-capable UA, then so the secure mail
service will not interwork very much. However each have their uses, and
communities of users. i suspect though that a low-assurnace PEM
community, a MIME/PEM certificate community, and a PGP community would
accept the others' privacy as equally valid.
I have yet to hear anything major comment against MIME multipart
constructs. Only when applied to the pem-signature protocol
do we have debate, concerning the messaging, and messaging architecture,
and related security semantics introduced by MIME/PEM deltas to
the PEM services.
Let us use the protocol field in multipart/signed and multipart/encrypted
to differentiate the services.
(1) PGP-protocol, Ned will create, and will tell us about, no doubt forcefully.
(2) pem-protocol, is already specified, and introduces the notions of
non STD 11 messaging models, MIME (STD XX) message content
architecture, MIME messaging model, alternatives to RFC 934 digesting,
and a whole suite of wonderful new security+messaging+bodypart
semantics to play with. Arguably, the Classic PEM semantics are also
provided (Though We disagree fundamentally here, owing to the groups'
different interpretations of the gravity of the fundamental differences
between MIME and RFC 822 message object models, and the
impact of single security framework on these two.)
(3) PEM-MIC-CLEAR-<Content-Domain>, PEM-MIC-ONLY-<Content-Domain>,
PEM-ENCRYPTED-<Content-Domain> suite of protocols, in which the first
two are bound to multipart/signed, and the latter multipart/encrypted.
There is no interplay between multipart/signed, and multipart/encrypted
in the PEM-ENCRYPTED application/protocol. For the <content-Domain> of
RFC822, the messaging semantics, message content architecture of RFC
822, and RFC 1421 security semantic for RFC 822 messages are preserved.
MIME multipart type headers are not protected, therefore. When
<content-Domain> is MIME/PEM, then a PEM de/enhancement is provided for
a secure message object of type 2. Note, in de-enhancing such messages,
the relevant Classic PEM protocol is invoked. In the optional 1421
de-enhancement of the message *content*, the application/pem-X would of
course be indirectly used in the case of <Content-Domain>=MIME/PEM,
allowing the wonderful world of your digital signature service on MIME
bodyparts and all that this entails. Conformant UA must ensure that an
outer PEM Content-Domain value of MIME/PEM, protects a
multipart/signed|encrypted message whose protocol is application/pem-X
Similarly for MIME/PGP.
(Preferably, a new option field (Content-Domain) would be added to
multipart/signed, and multipart/encrypted rather than have to interpret
a value for sub-syntax)
Its not too hard to see how the output of all the existing Classic PEM
filters in MIC-CLEAr and MIC-ONLY can map directly onto the first and
control body parts of multipart/signed ([CRLF <pemtext>], and
<pemhdr>), and ENCRYPTED map directly onto the control and second
bodypart of multiple/encrypted (<pemhdr>, and [CRLF <pemtext>]). in
this way type (3) messages interwork completely with Classic PEM, and
are automatically gatewayable.
PEM can define a Content-Type field of value MIME/PEM, which, should
the UA support the pem-protocol, allows the correct secure-mail
protocol engine to be invoked when (sub-)processing the MIME/PEM or
MIME/PGP (security and message-object architcture) labelled content. Of
course, the relevant PEM de/enhancement is used to secure the message
(containing one of a number of content architecutures). For PEm,
the content is opaque at the security service level. At the messaging
level, the RFC 822 or MIME/PEM message content architecture models
are followed according to the specified content-domain requirement.
Summary.
Everyone wins in this scenario. The various secure mail service re
identified, and all integrate with MIME. Their security properties are
preserved individually, and some interworking and coexitance at the
messaging and security level will be possible between secure mail
service flavours, especially when a multi-featured UA and fully MIME-capable
UA is available.
The goals of both groups will then have been satisfied.
The MIME/PEM service breathes life, as does MIME/PGP. PEM classic
becomes MIME capable. PEM Classic gateways to PEM-with-MIME. And the
various messaging models, content architectures, and privacy or
authentication services are kept separate though use of Content-Domain
in PEM, and an content-domain option in the multipart/x. A heterogenous
service environment is maintained, in which MIME is an option, most
people will choose.
No new work is required. Only that the MIME multipart I-D provides for
the registration of the PEM-MIC-CLEAR, PEM-MIC-ONLY, PEM-ENCRYPTED
protocols.
Hows this for a real compromise.
All the docs go through almost unchanged. Distinct PGP, PEM and MIME/PEM
services are denoted. and the MIME base get lots of toys
to buy, satisfying the Internet mission. PEM gets another chance to
shine in an operational world by following Einar's advice...
Now is there enough in the schema to go forward jointly? we will
need to extend the first RFC of MIME/PEM and MIME security multiparts
accordingly, once they have so advanced.
MIME/PEM has to be identified distinctly from PEM, as a separate
service, though. By otherwise, nothing changes; and standoff there
will be.
All the months debate suggest this would be a wise course.