Bob,
In a message last month you stated "PEM DOESN'T HAVE EXCLUSIVE
RIGHTS TO X.509, NOR DIGITAL SIGNATURES, NOR CRL'S, REGARDLESS OF THE
CONTENTS OF THE PEM RFC'S." I agree completely, but PEM does get to
establish a profile for certificate and CRL semantics and use.
You go on to state "A OSI digital signature is a digital
signature, regardless of the context or frame of mind of some subset
of all possible application developers. That's what standards are all
about." Well, as a simple syntax standard I agree, but digital
signatures independent of semantic context are not very useful and the
establishment of such context seems to be much of what you have been
arguing for.
You further said "We took a certificate structure out of
X.500, a system intended to provide strong 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 information (presumably), but we appropriated
that certificate format and are using it to sign DOCUMENTS, a purpose
for which it was not originally intended. Since signing documents
(including mail) has an entirely different set of legal implications
than an authenticated request to access or change a directory 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." Well, this is not quite right. Although
certificates and CRLs are defined in X.509 in the directory context,
they are intended for use in authentication and non-repudiation in a
much larger context. I think a close reading of X.500 makes this
clear. X.400 (88) makes use of certificates for the same services we
do in PEM. I think ODA standards (still under development?) make use
of the same infrastructure for just the sort of document signature
applications that are the focus of your concerns. So, it is not quite
accurate to state that X.509 defined certificates primarily for
directory authentication purposes and that PEM is somehow expanding
upon this pristine initial scope.
Where we may disagree, Bob, is whether it is appropriate to
modify X.509 certificates to include attributes that conflict with
directory model in which this common infrastructure lives. I am in
favor of defining other certificate types that bind different sorts of
attributes to a user's key, or to the user's X.509 certificate, on an
application-specific basis. What I don't want to see is the basic
X.509 certificate modified in a fashion that conflicts with its role
as an authentication tool or that skews it to favor some particular
application context, e.g, document signatures.
Steve
================= and another response ==========================
To: jueneman <jueneman(_at_)gte(_dot_)com>
Subject: Re: Certificate revocation
Cc: pem-dev(_at_)tis(_dot_)com
-----------------
Bob,
In your message exchange with Charlie Kaufman you the
statement is made "Users should be able to use but not know their
private keys." While I appreciate the principle underlying this
statement, it is incompatible with widespread use in the Internet.
We cannot require hardware (or highly trusted) implementations as
a condition of PEM implementation in the Internet. A given PCA
may establish such a policy for use within its domain, but this is
simply an untenable concept as a base requirement for PEM.
As for the issue of "turning in" one's key when leaving an
employer, I think this is an example of where the difference
between a key employed by an individual for personal purposes vs.
one employed for organizational role purposes is critical. In
situations where hardware is employed, and a user can invoke a key
(e.g., for signature purposes) without knowing the value of the
key, an employee can be entrusted with a token containing the key
for the role he is fulfilling and he can return the token when he
no longer fills that role. Internal procedures can be used to
maintain the binding between employees and roles (avoiding the
problem of disclosing the complete organization structure through
certificates). I realize that you have been opposed to this sort
of arrangement, believing that the individual's name must be bound
to a signature on a company document, but I still believe that
this approach, or some compromise involving both an individual and
a role signature, may be the best bet.
We agree on the utility of saving messages in encrypted form,
transitioning to an archive key by replacing a token. However,
note another variant of this approach: a company could require
procedurally, that business messages be cc'd to a destination that
represents the corporate message archive, thus providing encrypted
storage and corporate access at the same time. (This suggestion
relies on the observation that storage which is not frequently
accessed continues to become very cheap.)
Bob, I'm disappointed that you keep citing "once a month" CRLs as
an indictment of the CRL approach, You know well that a PCA can
require more frequent issuance in its policy statement. As you
noted, making sure that the global CRL database is highly
available is the critical requirement here, but I agree with
Charlie that a real-time CRL-like service does imply an online CA
that is able to respond in real-time to good-guy/bad-guy queries.
Steve