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
form of a DN) and a
public key. The purpose of PCAs and their policies is to help establish how
much faith to place
in the veracity of the stated identity.
Agree, although I suspect we have some differences of opinion as to what
constitutes 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
differentiate 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
representation 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
agree 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
creative. 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
frame of mind of some
subset of all possible application developers. That's what standards are all
about.
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 orignally 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.
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
meeting 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
additional authorization
certificates to meet their particular needs for structured transactions with
fine-grained control,
but for more-or-less human-readable documents written in English (or German,
Swedish, etc.),
I think they are overkill. I believe that if we add an attribute or two,
specifically roleName and
agentName, to the OIW agreements; and support the use of multivalued RDNs we
will be
in fine shape with respect to both PEM and other more document-oriented
applications.
Maybe you weren't disagreeing with me in the first place, but are we together
on this now?
Bob