[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: make things as simple as possible
email@example.com (Carl Ellison) wrote:
At 21:15 3/20/96, Greg Rose wrote:
[proposal for having each element of a cert be represented by a fixed
length hash -- so that the cert is just a signed array of fixed length
Let's say the Meaning of a particular cert is to allow FTP into cybercash.com.
I imagine the application designer [the one modifying the FTP server or the
firewall to allow such access] defining a Meaning field he will recognize:
In any of these three cases, that application could build the acceptable
string and hash it -- and from then on, just look for that hash in the
certificate body. That might speed up checking quite a bit.
However, if the application has to go fetch the meaning from someplace and
then compute the hash of it to add it to a hash table and then compare
hashes and then parse the fetched statement, prior to giving access
permission, it's a loser IMHO.
What I was envisaging, but had failed to express
very well, was that a communication would
generally be a "bunch" of things. In the same way
that PGP will scan a file and read multiple keys
from it, the ftp authentication stuff in Carl's
example might consist of two "packets":
1. A certificate, including a hash of the "FTP Access" thing
2. The "FTP-access: cybercash.com" thing itself,
somehow labelled as being a "thing", so that the
application code would know to hash it and look
for that hash in appropriate places.
When something comes in, I would envisage a
"preprocessing" phase where all of the "things" in
the message were read, hashed and added to a local
Stepping back, though, I'd have to ask who granted
the FTP access permission in the first place?
Presumably cybercash.com. In which case they would
probably have the "FTP-access: cybercash.com"
locally cached anyway.
So it becomes a probabalistic mechanism; If the
probability of the "thing" being locally cached is
high (eg. it was originally granted by the
recipient) don't bother sending it. If they've
probably never seen it before (eg. a CA's
certificate of identity for a newborn infant) send
it anyway. It can't hurt.
The representation makes for fast lookup, and the
properties of the hash would make distributed
servers conceivable -- although I haven't yet
thought about that in detail. It becomes a
tradeoff between how much you cache or
pessimistically send, and how long you are
prepared to wait for the answer to come back if
the information wasn't where you wanted it.
I wonder about other real applications of certificates. Ideas?
I might begin working on a representation along
these lines, so I can better attack examples
people come up with.
One of the problems I see is that the tag of the field is lost until you do
the hash lookup, in Greg's proposal, so the app code interpreting the cert
is probably complicated in any case. You might find people requesting that
certain tags always be at certain locations in the array..... Hmmmm....
I can't parse the first sentence. The second one
seems to make sense. There is an alternative to
fixed position, though, and that is having the tag
in the certificate -- but I think that is a lose.
The information wouldn't be in the certificate
unless it was "desirable", so it seems
reasonable to me that all the things referenced in
the certificate should be available before the
application code gets to see it.
Ahh, now I understand the first sentence. One
would presume an API which allowed you to say
"give me the FTP-Access part of this certificate".
A mere matter of programming :-)
Greg Rose INTERNET: firstname.lastname@example.org
Sterling Software VOICE: +61-2-9975 4777 FAX: +61-2-9975 2921
28 Rodborough Rd. http://www.sydney.sterling.com:8080/~ggr/
French's Forest 35 0A 79 7D 5E 21 8D 47 E3 53 75 66 AC FB D9 45
NSW 2086 Australia. co-mod sci.crypt.research, USENIX Director.