>From: James M Galvin <galvin(_at_)tis(_dot_)com>
>Subject: Re: keyid, and privacy, and interworking
>Date: Mon, 02 Jan 1995 17:33:02 -0500
>Peter,
>
>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.
In fact they are completely incompatible, both in messaging
assumptions, and their technqiues, for securing messages in an
*assured* manner.
That is, the design goals of an assured privacy service, and a
enhancement service for the heterogenous mail enviornment constituting
the Interent, are not the same.
Which is what I said to Perry.
We agree that both 14221 and MIME/PEM protocols are distinct, and
require therefore complete separate documentation and specification.
Should MIME/PEm do something different or in addition to 1421 at the
messaging and security goal level, what this is will will be specified
in the first section of the revised document. MIME/PEM Deltas to 1421
at the additional or changed facility and mechanism level are not
sufficient. The impact on services might be fully described, as must
the assumptions on interworking, and scalability between keying
domains.
This is the point I made to the MIME/PEM 4 months ago. Russ Housely
made it also, then. So did Paul Lambert recently.
> (1) UA PEM procedure functionality will be required to handle key
> management, rather than certificate management.
>
>Then choose to ride only 1421. On this train, you get the same services
>as 1421 in addition to the flexibility to help yourself.
Ive suggested a framework whereby both 1421 and MIME/PEM, as distinct
protocols, integrate into multipart/signed and encrypted messages.
this would remove the clash of designs, and designers!
MIME/PEm asserts that it is 1421 + a bit + MIME.
1421 people state that the "a bit" means MIME/PEm cannot achieve 1421
goals.
So lets use the multiple protocol facility of multiparts to do both,
and others later on: additional specific groupware messaging protocols,
for example; of complex message architectures like multi-structured,
secured ODA :-). These may or may not be based upon multipart/PEM or
multipart/MIME-PEM, depending on goals.
If we reintroduce the content-domain notion to multipart/signed, then
even a degree of mixed (though not interoperable) worlds will be
possible. But this we can wait out for a revision to the multiparts
RFC.
>
> (2) UA PEM procedures will be required to track on a
> per-recipient basis the state of and procedures used in previous
> key distribution interactions.
>
>Excuse me?! Have you forgotten about the PCAs required in RFC 1422,
>which by the way is required in a compliant 1421 implementation? Every
>implementation is required to track the existence of every PCA and to be
>able to report to a user the implications of a public key found to be
>issued under that PCA.
The difrerent is there is only one procedure in 1422 for all
recipients, not several as in MIME/PEM, and it is bascially stateless.
Furthermore, such a connectionless key distribution is a
requirement for assured confidentiality, in the case of
a type II-like RSA Key Exchange.
>
>Further, you're discussing database issues which, while they are
>relevant to PEM in general, they are outside the scope of this
>specification. This specification explicitly (BY DESIGN) divorces what
>1421 and 1422 married. If you want that train, then you're on the wrong
>track.
No, I'm discussing protocol and service assurnace and scalability
issues. The only issue of storate concerns the need to (at
authenication and encryption time) obtain certificates from a source
(cached, inband, or otherwise).
The divorce of 1421 and 1422 is a fundamental assurance change, which
should not have followed from the need to PEM-enhance MIME messages, or
carry PEM messages over MIME channels.
It may be legit, however, as a separate protocol. I support such a new
MIME/PEM-enhanced mail protocol development, as I have stated before.
I think there are applications in the Web for its general framework of
relating authentication and encryption. The bilateral key procedures,
and the support for authenicated channels assured through transitive
trust procedures also may well support the existing EDI industry for a
while.
So coexistance is a win-win for all. All but the users, though, in
the longer term.
>
> (3) no facility has been specified which facilitiates the
> revocation of keying material distributed using authenicated or
> unauthenicated channnels. A fundamentally incomplete identity
> protocol is therefore introduced.
>
>This topic is independent of the PEM/MIME specification and therefore
>irrelevant to its status. Let me point out that even "classic" PEM
>separated the topics into two documents: 1421 and 1422. This
>specification explicitly (BY DESIGN) leaves the choice of key management
>an independent event, instead of marrying them as required by 1421 and
>1422.
An identity protocol which does not specify how revocation is handled
is incomplete. Completion can be achieved by reference, inclusion, or
handwaving. The assurnace *relations* and the mechanisms which lead one
to evaluate a correct binding between the messaging and key
distribution protocol MUST however be specified.
>
> (4) a recipient of a forwarded signed message may be in a
> position of being required to establish out-of-band contact with
> the originator in order to establish an authenticatyed channel
> over which which to receive keying material necessary to
> validate message origin. Name form cases exist in which no
> communciation details are ever available, preventing third-party
> reauthenication of the originator's cliamed identity. This
> introduces ramifications for the anonymous origination usage
> mode of PEM, in which it is not always the case that a given
> message stream can always be proven to originate from a given
> party.
>
>Quoting Forrest Gump: "Stupid is as stupid does." :-)
>
>In any case, if I've got a name form, then I've got as much information
>as I would have with a certificate. If that's insufficient for locating
>the user, then I would assert the user doesn't want to be found. Either
>that or RFC 1422 is fundamentally flawed and we should kill it
>immediately. Of course, why a user would sign a message, give me their
>name, and then not want to be found escapes me.
1422 does not require locating the user. Thats the difference.
Anonymous services are possible, with complete authentication
semantics.
For RSA Key Exchange of a type II DEK, trying name, keying, and comms
forms together inevitably leads to unscalable bilateral and manual
keying distribution, else transitive trust as the basis for determing
the assurnace level of the authenticated channels over which keying
material is received.
Neither is an exciting proposect for a "standard", ubquitous, IETF
privacy protocol.
We agree to disagree.
So as Dave says, put both on parallel tracks.