>From: James M Galvin <galvin(_at_)tis(_dot_)com>
>Subject: Re: keyid, and privacy, and interworking
>Date: Thu, 05 Jan 1995 11:55:23 -0500
> >You're on the wrong train. You want train 1421. On this
> >train, you get the same services as 1421, if you want them,
> >plus a few other services not previously available, BY
> >DESIGN. In other words, 1421 is what it is BY DESIGN, and
> >PEM/MIME is what it is BY DESIGN.
>
> Then we are agreed. By design, 1421 security and MIME/PEM
> security are different, as they relate to the forwarding and
> stored message models, and the message content architecture
> models. The are vitally different in the security services they
> specify and support, particularly in relation to storage of
> non-repudiable messages.
>
>No, we're not in agreement. In light of what John Linn said in his
>message, let me revise what I said and be more specific.
John Linn spoke of the option of symmetric key management, for which no
concept of nonrepudiation of origin services ever existed in PEM. This
no longer exists in MIME/PEM, though represented the same quality of
assurnace and procedural ease (with a fraction of the cost) as your
additional key exchange mechanism based exclusively on the reversible
properties of RSA (versus assymemtric ciphers in general contrary to
PEM goals) and trusted keying databases or, perhaps, even a trusted
DNS/Directory!
(vision forming of:- trusted DNS, based on IGng identifier and security
options to form a trusted/authenicated DNS keying-enabled server domain, over
which keys are distributed by replication and caching...)
RFC 1421 certainly does support manual key distribution, though Id
appreciate Johns input whether 1421 implied the use of manually
distributed asymmetric IKs. Such a concept undermines the identity and
non-disclosure protocol I thought PEM was about - which wouldn't be the
first time I totally misinterpreted something!
If this is the case, then Im in full support of MIME/PEM, and
as with all other protocols of the same class.
PEM stated:-
If an originator elects to perform PEM processing on an outbound
message, all PEM-provided security services are applied to the PEM
message's body in its entirety; selective application to portions of
a PEM message is not supported. Authentication, integrity, and (when
asymmetric key management is employed) non-repudiation of origin
services are applied to all PEM messages; confidentiality services
are optionally selectable.
It is no longer the case that with PEM and asymmetric key management,
"non-repudiation of origin services are applied to all PEM messages".
This is change of effect (see below). Note the universal quantifier
in the proposition.
Furthermore "selective application to portions of a PEM message is not
supported" Whilst it is in MIME/PEM. This is change of effect (see
below). This is backed up by Ned Freed's mailing list arguments.
>The definition of PEM in 1421 and the PEM/MIME specification are
>compatible. In fact, the PEM/MIME specification, in its current form,
>depends on the existence of 1421. Where they differ is in the public
>key validation model.
MIME/PEM:-
This document specifies a number of changes to the message encryption
and signature procedures of PEM and broadens the name forms that may be
used to identify public keys. Many of the changes represent a departure
in mechanism, not in effect.
PW: the very notion of asymmetric key management has changed in 1421,
both
in the use - identity protocol - and distribution and assurnace
relations (1422).
PW: Further suggesting the loss of the identity protocol, name forms
apparently now associate with keys, not real world entities.
...
Since a user may have more than one key pair, a name form is
insufficient for uniquely identifying a key pair.
PW: and so it goes on. Though the "identifier" concept is fine
within the discussion of key rollover as discussed by
Warwick, assuming there eixsts authenticated channels at
some point. Unforutantely, in MIME/PEM those channels are
not individually accountable so there is little assurnace
for the confidentiality-based access control decision,
producing privacy.
...
With a key pair for one's self and software that is both MIME and PEM
aware, an originating user may digitally sign arbitrary data and send it
to one or more recipients.
PW: the software must have a "key pair"? What for, pray tell? Is
there a specific assurance mechanism being introduced here?
My MIME engine and PEM engine are not the same program; they
dont run on thesame machine even. If there is something I
need to do in this area of the prposed std's track document, I need
it specifying! Have you introduced trusted software, and trusted
systems design here as a consequence of repealing 1421's
asymmetric keying management requirements? or What?
Peter.