[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is meaning important?
At 05:56 3/22/96, Ben Laurie wrote:
>There has been a lot of discussion on this list about the "meaning" of
>certificates. It seems to me that this may be beyond the scope of the
>specification we are supposed to be working towards (namely, a means to
>interchange public keys simply and interoperably).
>
>Of course, there are certain aspects of the meaning which must be established,
>in particular the data telling us where and how supporting data for the
>certificate may be obtained (for example, the cerificate of the CA).
>
>Could we not make useful progress by ignoring the question of CRLs, trust
>models and so on, and concentrating on the interchange aspects of the system?
>
>I'm not saying that these issues do not need to be addressed, just that there
>are many uses for certificates, and many different models for verifying them,
>all of which could be built on a single interchange methodology (maybe).
>
>Thoughts?
Ben,
I'm not trying to minimize the issues of distribution, database
structure, etc. However, IMHO, if we don't allow the certificate to say
what it means, we have fallen into the same trap of meaninglessness which
we find with X.509.
I have used X.509 certificates for an FTP gateway and ran headlong
into the problem that the certificate carries no meaning of interest to
that gateway [or any other application you can think of]. The X.509 folks
ran into the same problem. That's why they created "attribute
certificates" and V3 extensions. The underlying fact is that a raw
(name,key) certificate means nothing in cyberspace and almost nothing in
SNailspace [see my example at the end for a Meaning which really means
something in SNailspace :) ].
The contribution I hoped to make to this discussion is the
observation that a (key) certificate [nameless, self-signed key] carries
almost all the meaning of a (name,key) certificate [that it can be revoked
in case of compromise] -- but that the real meaning of interest is in the
(attribute,key) certificate which even X.509 folks need in order to do
anything useful. Therefore, I proposed that we construct the latter brand
of certificate. I offered one already and have a couple of refinements to
suggest to make it fully useful. The CRL problem is important, in
particular.
I also observe that if you have an (attribute,key) certificate, one
attribute could be the specification of a name -- therefore, the
(attribute,key) certificate is a more general beast than the X.509-style
(name,key) certificate, including it bodily as a subset.
However, a certificate with no meaning is meaningless in the normal
sense of the word and, IMHO, not worth the electrons to discuss.
I am not suggesting that we try to specify all possible meanings --
e.g., make a catalog of them. There are too many -- a potentially infinite
number. I proposed letting natural language speak the meaning to a person
who then has to validate any certificate chain, to verify that each link is
qualified to make its statement and that the terminal statement is the one
needed for the action the application is contemplating. Matt Blaze & Co.
suggested a small, safe program for the same purpose. I'd advocate going
to their little programs, but allowing a natural language [human mediated]
fallback for cases which are too difficult to express in the chosen
programming languages -- and for cases in which it really is a human
interpreting the certificate.
e.g.
Meaning: I met the woman who can sign challenges verified with this key and
she is gorgeous!
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430 http://www.cybercash.com/ |
|2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091 Tel: (703) 620-4200 |
+--------------------------------------------------------------------------+