----- Unsent message follows -----
Received: by us3rmc.bb.dec.com; id AA22375; Tue, 21 Sep 93 07:58:50 -0700
Received: by inet-gw-1.pa.dec.com; id AA16987; Tue, 21 Sep 93 06:44:46 -0700
Received: from magellan.tis.com by magellan.TIS.COM id aa12753;
21 Sep 93 8:55 EDT
Received: from tis.com by magellan.TIS.COM id aa12749; 21 Sep 93 8:53 EDT
Received: from azalea.tis.com by TIS.COM (4.1/SUN-5.64)
id AA11260; Tue, 21 Sep 93 08:52:54 EDT
Received: by azalea.tis.com; id AA01451; Tue, 21 Sep 93 08:51:25 EDT
Received: from bunny.gte.com/132.197.8.1 via smap
Received: from wotan by bunny.gte.com (5.61/GTEL2.19)
id AA26960; Tue, 21 Sep 93 08:51:14 -0400
Message-Id: <9309211251(_dot_)AA26960(_at_)bunny(_dot_)gte(_dot_)com>
Date: Tue, 21 Sep 93 08:51:05 EDT
From: jueneman
<jueneman%gte.com:jueneman(_at_)wotan(_dot_)bb(_dot_)dec(_dot_)com>
Subject: Re: Snakepits, CRL's and certificates
To: John Lowry <jlowry(_at_)dave(_dot_)bbn(_dot_)com>
Cc: pem-dev(_at_)tis(_dot_)com
Reply-To: Jueneman(_at_)gte(_dot_)com
I can't tell whether we are in violent agreement or not. I think we are?
Lowry>A certificate is an assertion of a binding between an identity (in the fo
rm of a DN) and a
public key. The purpose of PCAs and their policies is to help establish how mu
ch faith to place
in the veracity of the stated identity.
Agree, although I suspect we have some differences of opinion as to what consti
tutes a "reasonable"
DN.
A CRL is a revocation of the assertion instantiated in the certificate.
Agree. I assume you include the case of revocation because of a key compromise
within this
definition. We could argue as to whether it would have been desirable to differ
entiate the
various reasons why the certificate was revoked.
(Shouting now...)
THAT IS ALL IT IS !
Those of you who have different needs, for authorizations, for complete repres
entation of
cause for revocation, for carrying a digitized image of the certificate subject
will just have
to figure out another means of doing what you want.
I, at least, have never argued for anything more. However, I assume that you ag
ree that since
the 1993 version of X.509 is coming up for vote, pointing out various areas for
possible improvement
is not too far out of line.
The certificate based key management in PEM must not be overloaded. Be creati
ve. USE
this mechanism as a component of whatever value added system you wish to offer
but
don't seek to break it by making it the solution itself.
Agree. But understand that the use of X.509 certificates and an OSI-registered
digital signature
algorithm identifier is a two-edged sword.
[Mild increase in volume and pitch...]
PEM DOESN'T HAVE EXCLUSIVE RIGHTS TO X.509, NOR DIGITAL SIGNATURES, NOR CRL'S,
REGARDLESS OF THE CONTENTS OF THE PEM RFC'S.
A OSI digital signature is a digital signature, regardless of the context or fr
ame of mind of some
subset of all possible application developers. That's what standards are all ab
out.
We took a certificate structure out of X.500, a system intended to provide stro
ng authentication
for users accessing a directory service (c.f. X.509 para 1.2), and have adopted
it for other purposes.
X.500 is only concerned with authenticating a user's access to his own informat
ion (presumably),
but we appropriated that certificate format and are using it to sign DOCUMENTS,
a purpose for
which it was not orignally intended. Since signing documents (including mail) h
as an entirely different
set of legal implications than an authenticated request to access or change a d
irectory entry, we
should not be surprised if a few awkward constructs are required. After all, WE
(the PEM community)
are the ones who adopted this new and perhaps unintended use.
I am not arguing that we shouldn't have "borrowed" X.509. In fact, I think that
it was probably a
brilliant decision that will bring a lot of different aplications to a common m
eeting ground. But we
should understand that PKCS and other non-PEM applications have rights in this
arena too.
I am supportive of the EDI and ANSI X9F1 community's efforts to define addition
al authorization
certificates to meet their particular needs for structured transactions with fi
ne-grained control,
but for more-or-less human-readable documents written in English (or German, Sw
edish, etc.),
I think they are overkill. I believe that if we add an attribute or two, specif
ically roleName and
agentName, to the OIW agreements; and support the use of multivalued RDNs we wi
ll be
in fine shape with respect to both PEM and other more document-oriented applica
tions.
Maybe you weren't disagreeing with me in the first place, but are we together o
n this now?
Bob
------- End of Forwarded Message