[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (attribute,key) bindings
Carl,
perry chastised me for appearing to argue on behalf of X.509 in this forum,
although that wasnt' my intent. just want to make sure that when we draw
comparisons, we do so accurately. After all, some of the thinking that is going
on here might be adopted/folded in to the X.509 certificates as well.
>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.
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}.
(FYI, the financial industry has a requirement that key personnel take two
consecutive weeks of vacation, so as to make it more difficult for someone to
cook the books without detection. This issue cam up in regard to a proposal to
have a hold or suspend feature instead of having to revoke a certificate.
Likewise, the military needs to be able to assign command authority to the
office of the day, and to have that authority expire gracefully at the end of
this shift, without having to revoke the certificate. But in almost all other
circumstances I am aware of, attributes will be sassigned semi-permanently, and
so they combined with whatever level of "identity" certificate may (or may not)
be required.)
>
>You can think of the (attribute,key) certificates I've been advocating as
>the reduction of (attribute,name)(name,key) to what I care about as a
>programmer, omitting the thing I don't care about [the name]. {There are
>other reasons to omit the name but that's a topic for a different message.}
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.
>
>Attribute in this case ["meaning" in previous messages] is something like
>"permission to get FTP access to cybercash.com" or "permission to spend up
>to $5000 per check from checking account xxx-xxxxx-xx" or whatever....
>
>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.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Jueneman@gte.com
1-617/466-2820
"The opinions expressed are my own, and may not
reflect the official position of GTE, if any, on this subject."