[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (attribute,key) bindings
Hi Bob.
At 11:11 3/27/96, Jueneman@gte.com wrote:
>>In my previous message, I suggested that the X.509 folks have gone to
>>(attribute,key) certificates in addition to the (name,key) certificates,
>>since (name,key) means nothing in cyberspace.
>>
>>This is effectively true but not quite.
>>
>>The X.509 gang in fact suggests (attribute,name) certificates -- thus
>>creating an artificial demand for (name,key) certificates.
>
>I sincerely believe that you are making too much of a big deal of the "name"
>issue in X.509. In a number of significant cases, the "name" that is
>present is
>totally arbitrary, and merely represents a way of tracking a succession of
>certificates that might be issued to a given entity over time. Yes, the old
>traditional geopolitical semantics can and will be used, especially to
>represents companies, services, and the like, but the MasterCard/Visa spec
>is a
>good example of combining {name=index,attribute(s),key} into one certificate.
I may have been talking to the wrong X.509 folks.
All certificates need to have an index of some form so that they can be
identified. If you want to call that a "name", then all certificates have
a name.
The ones I'm proposing use the hash of the key as that name -- and
therefore the name need not be present. This has a distinct advantage: it
removes the need for a trusted third party whose job is to certify the
binding between the index and the key. Everyone in the world can compute
the index from the key.
I am trying to eliminate CAs from the landscape, unless they provide some
useful, economically justifiable service -- like the singles' club example
I gave much earlier [weeks ago?]. To me, every entity which uses
certificates will issue its own. It has to anyway.
>Although ANSI X9 may still be palnning to stand-alone attribute certificates,
>as may the military, those two applications are quite unusual. In most
>cases, I
>believe that the standard form of certificate will be
>{name/index,attributes,key}.
I'm inclined to think the X9 and military examples are the usual ones. Not
only are finance and military-like security major application areas, but
other more casual uses of attribute-only certificates are easy to come up
with. I made a list just last night of several certificate uses which
needed to be anonymous -- starting with a certificate which proves
membership in an anonymous organization [Alcoholics Anonymous, Narcotics
Anonymous, Pedophiles Anonymous, ...]. Granted, in the flesh such
certificates aren't needed -- but on-line they may well be.
There are many others, and I'll be keeping a list for later posting, in
case people want to send me further suggestions.
My current list is:
1. *A group membership
2. Corporate employees acting outside a corporation which treats employee
lists as company confidential and therefore would never allow a
directory of certificates with names inside
3. Covert CIA agent ID
4. voter ID
5. outpatient ID for anything confidential/anonymous {psych, drug, cancer,
AIDS}
6. cypherpunk anonymous personnae
------
There's another problem with {name/index,attributes,key}, as opposed to
separate attribute certs: and that's that the collection of attributes
will probably represent a privacy violation. The fact that those
attributes are bound together as applying to one person may make it
possible to locate the physical human attached to the attributes.
>But I believe you are consistently overlooking some of the other problems,
>such
>as how to look up the certificate, and how to correlate that information with
>something/anything else. If you don't assign (even a content free) name or
>index for this purpose, you are eventually going to have to extract it from
>some other field or attribute, and that is just going to be harder. Why can't
>you just live with the concept of a name that may be a simple index, or may be
>missing entirely, or on the other hand could be a full geopolitical name with
>lots of semantic content.
>
>That way everyone in the community would be able to have a common format and
>approach.
>>It should also be noted that formally, one needs to use
>>(attribute,key)(key), where the second cert, (key), is self-signed and can
>>be revoked in case the key is compromised. Similarly, the X.509 crowd
>>should use:
>> (attribute,name)(name,key)(key)
>>
>> - Carl
>>
>I don't understand the need for the self-signed certificate, nor why you are
>suggesting that X.509 bind an attribute to a name, and a name to a key.
The self-signed cert (key) is there to be revoked in case the key is
compromised. I suggest that X.509 needs one as well because the standard
assumption is that the (name,key) cert will be revoked in case of
compromise but the (name,key) gets revoked by a CA and the person whose key
was stolen needs to contact the CA to get the revocation done. As long as
the (key) can be revoked by itself, that revocation could happen by anyone
with network access to provide the (key) cert -- maybe a CA but, more and
more as time goes on and people get wired, probably the person himself.
+--------------------------------------------------------------------------+
|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 |
+--------------------------------------------------------------------------+