[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (attribute,key) bindings


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 

(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 
>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.


Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254

"The opinions expressed are my own, and may not 
reflect the official position of GTE, if any, on this subject."