Date: Mon, 31 Jul 1995 21:04:20 -0700
From: Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com>
The reality is that most global standards need relatively simple
strings. In the case of global certificates, we need to pay very, very
close attention to what we have learned vis a vis Internet vs. X.400
addresses. A little-known fact is that X.400 addresses were developed
largely by Arpanet folk. We thought the generality would be a good idea.
We were wrong.
Wonderful observation.
I must apologize for coming into this discussion in the middle. I've been
operating off a selective feed from a co-worker rather than the pem-dev
list itself.
For certificates, it seems clear to me that the superior choice is a signed
block holding text and the subject's public key (or a cryptographically
strong hash of that key). The arbitrary text can be used to say whatever
the signer wants to say about the key/person in question -- from security
clearance to color of hair. The public key is a unique identifier and the
binding between the person and that key can actually be proved by the key
holder, on demand (by his signing something with the corresponding private
key). Therefore, this binding is stronger than the hated Distinguished
Name construct and this mechanism is more general than that provided by
X.509 certificates.
When I was writing earlier about a replacement for ASN.1 it was for a
totally different problem: passing structures (structured messages) from
one computer to a dissimilar one. In today's world, that means messages
among UNIX, Mac and PC. Any intercom mechanism which covered those three
machines would essentially cover the entire world to within a negligible
error.
These are not the same problems at all. Neither does ASN.1 answer either.
ASN.1 is a very general tool which can be mis-used to try to achieve the
intercom between machines, but it falls short in that goal (fails in a
number of ways: e.g., lacking forms for C's char, short and long). It's a
proper choice when you want to describe and communicate things which it is
designed to describe. (Arbitrary database entries seem to be the favorite
examples in the text of the standard.) If you want to receive some
construct from someone without knowing anything about the structure they're
sending (cf., Amanda Walker) and make some sense out of it, ASN.1 might be
good. It's not specifically designed to do either of the two specific jobs
described above.
A mechanism which permits binary data structures to be moved between
dissimilar machines might be used to describe a certificate -- since a
certificate might be formed as a data structure -- but that's not the
only or even primary use of a certificate.
A certificate is really a statement by the person doing the signature to
the person receiving and caching the certificate, attesting to some
characteristic about the key being signed (or that key's owner). We don't
know what that characteristic is. Raw text allows one to express it.
For example, if I were a shipping agent at some S/W company and I received
an electronic P.O., signed by Joe Blow, I need to know whether Joe Blow is
authorized to sign that P.O. That's a decision I make, as a human. If I
decide he is, I need evidence to back me up. A signed message from the
bank that XYZ Inc. has account XXXXXXXXXXXXXXX and a signed message from
XYZ Inc. that Joe has authority to sign such P.O.s provides that -- but in
the end it comes down to my human decision and my need to point to evidence
should Joe turn out to have lied.
In some cases, the recipient and user of the certificate is a program.
RFC822-style tagged text is a good way to speak to that program without
losing the ability to have a human attest to another human about some
attribute not anticipated by the certificate designer.
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme(_at_)tis(_dot_)com
http://www.clark.net/pub/cme/home.html|
|Trusted Information Systems, Inc. http://www.tis.com/ |
|3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 |
+--------------------------------------------------------------------------+