CAT list members have already seen the attached, excerpted from an ongoing
discussion we've been having in response to a informal liaison request
from Dave Gomberg on behalf of ISO/IEC JTC 1/SC21 WG8, who are looking
to incorporate or define store-and-forward messaging API primitives
for use in conjunction with GSS-API. Several people have commented
with interest and belief that such a definition would be a Good and
Reasonable Thing. I'm sending this to pem-dev as well in the interest
of informing potentially-interested participants who haven't previously
been involved with GSS-API, and of surveying the likely pool of
volunteers who might be interested in drafting a spec.
I'd envision the appropriate spec as being a standalone document
referencing GSS-API, probably accepting GSS-API credentials (rather
than security contexts) as input to the protect/unprotect
primitives for store-and forward messaging. For mechanisms capable
of supporting both on-line, association-oriented and store-and-forward
services, this would facilitate access to both with a single login.
Comments? Interest?
--jl
------- Forwarded Message
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <IAA17602(_at_)pad-thai(_dot_)aktis(_dot_)com>; Wed, 3 Aug 1994
08:16:54 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA09176; Wed, 3 Aug 94 08:16:51 EDT
Message-Id: <9408031216(_dot_)AA09176(_at_)winkl(_dot_)aktis(_dot_)com>
To: tytso(_at_)MIT(_dot_)EDU (Theodore Ts'o)
Cc:
p(_dot_)v(_dot_)mcmahon(_dot_)rea0803(_at_)oasis(_dot_)icl(_dot_)co(_dot_)uk,
vipin(_dot_)samar(_at_)eng(_dot_)sun(_dot_)com,
cat-ietf(_at_)MIT(_dot_)EDU, linn(_at_)cam(_dot_)ov(_dot_)com
Subject: Re: Query re work on GSS-API extensions for store-and-fwd support
In-Reply-To: Your message of "Tue, 02 Aug 1994 22:52:31 EDT."
<9408030252(_dot_)AA03428(_at_)tsx-11(_dot_)MIT(_dot_)EDU>
Date: Wed, 03 Aug 1994 08:16:50 -0400
From: John Linn <linn(_at_)cam(_dot_)ov(_dot_)com>
Piers and Ted write:
From:
p(_dot_)v(_dot_)mcmahon(_dot_)rea0803(_at_)oasis(_dot_)icl(_dot_)co(_dot_)uk
Date: Tue, 2 Aug 94 23:10:08 BST
Reply-To:
p(_dot_)v(_dot_)mcmahon(_dot_)rea0803(_at_)oasis(_dot_)icl(_dot_)co(_dot_)uk
I too think that such an interface would be a good thing. But, being
devil's advocate, what Internet applications would be potential
consumers of such APIs? While EDI and email are two obvious candidates,
doesn't the existence of existing specifications and/or implementations of
store-and-forward security embedded within such applications (PEM, PGP,
X.402, EDIFACT, Pedi etc) limit the motivation for introduction of a
new generic, and possibly non-interoperable, paradigm for implementing
the same services?
Well, a generic API that defined how to take a blob of data and creating
a PEM or PGP encrypted (and possibly ASCII armored) message would be
quite useful. I don't think this would necessarily be a new,
non-interoperable paradigm, since there generally isn't a commonly used
API in use now for these services that's callable from other programs.
(Right now, there's just a command-line interface for PEM and PGP.)
I'm assuming here that the packet formats of PEM, PGP, etc. would not
change under this new API.
Clearly, introducing non-interoperability is a non-useful thing.
This implies to me that messaging support primitives would
want to accept input selector parameters to prescribe which of
a set of already-defined encapsulation formats (e.g., PEM, PGP,
PEM-MIME, ...) they're to output or process as input. Each of
these formats would correspond (loosely) to a GSS-API mechanism,
and this seems to me like a useful means to construct
messaging toolkits allowing applications to use multiple protection
formats.
We appear to have consensus that S&F GSS-API extensions would be
a useful idea; now, we need to decide if and how to progress this
as a work item. Ted, Piers: would it be OK with you if I forwarded
this message to the pem-dev list, as a vehicle to involve interested
members of the PEM development community who may not previously have
been concerned with GSS-API?
- --jl
------- End of Forwarded Message