[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Thinkin' about identifiers...
On Mon, 6 Jan 1997, Edward A. Russell wrote:
> to services and machines incorporated with a public key infrastructure.
> I should be able to walk up to any PC and authenticate myself (via smart
> card or secure key/cert package downloaded from my server) and then gain
> access to all things I am allowed access to. But fundamental to this is
> WHO AM I? What is my name.
I agree 100%. The notion of having to carry around multiple IDs is
getting stale my the minute. Have you read about IBM's little "personal
area networks"? Forget smart cards -- we're talking about smart shoes now
;)
>
> I would also like to see user-based IPSEC where machines authenticate a
> session based on a user certificate, not a DNS machine certificate.
> Again, what is the namespace here.
>
> I disagree with the need for hiding information about where I work or
> the country I live in however - that is too paranoid for my own taste -
> the concept of "anonymous authentication" makes no sense to me. However
Personally, yeah. I don't see knowledge of my identity interfering with
me getting my work done on a daily basis... "anonymous authentication" is
very normal though, you just need to use non-binding identifiers. You
can use the pub-key to "authenticate" that I am who I claim to be. Who
do I claim to be? Rudolph the red-nosed raindeer. Who cares? If you trust
the person you use to verify the identifier, you don't need to know who
the person you talk to is. it would be nice to have the option, keep it
available, like say if I use one smartcard to buy illegal merchandise
(using the first virtual bank of the underworld ;), I don't want ANY
personal data that the first secret service database may also know about
me available when the criminal database is eventually compromised.
Simpler context: if I want 1 company to know my phone number (cause they
provide a useful service through the phone) but I do not want the
direct-marketing department of my grocery store to get my phone number
cause they'll call me at 2:33am and ask if my lettuce is crispy enough,
how do I realistically prevent them from doing a merge on my name once
they sell each other their databases? if my name is not bound by reality,
I can keep multiple identifiers and they can't be easily connected to one
another. I keep one for people I want to have my phone number, and one for
people I do not want to have it. ta da. Multiple-identity management
should be the responsibility of an individual, not of viacrypt.
>
> You talk about an implementation, but what are your ideas for a
> namespace? Doesn't it have to be hierarchial and to that extent don't
> you eventually wind up with X.500 Distinguished names anyway?
>
I've been thinking about a fixed-length binary string around 18-24 bytes.
Maybe so big as 30, cause there's no point having to come up with a whole
new distributed naming database for software agents, consumer electronics,
and whatnot. Still, playing with a calculator for a minute it's not hard
to see that you are fine within 24 bytes.
It would definitely have to be hierarchical, but the nice thing is that
there need not be any organizational tie to the outside world as far as
Authority of Service. Therefore, if you introduce a new server into the
system and it advertizes to its nearest peer, it should be reasonable for
the peers to begin loading any old data they feel like into the new peer's
allocated storage. There are no trademarks to worry about in 24-byte
binary jumbles (god I hope there aren't ;) so why should you care whose
names you're serving?
Part of the intended reliability is the fact that anyone with a
reasonably reliable machine can download the software, get some sort of
trusted key out of band from another peer, and then add their
collective resources to the pool immediately. I sorta prefer the trust-web
to the CA model, but probably a healthy mixture of the two will evolve.
I don't _dislike_ X.500... I bet it will help me find my friends' email
addresses. The problem is that if I write down their DN, and they move,
their DN doesn't yield their certificate anymore. If they signed one of my
certificates, like in a trust web, then the authority they bestowed on me
is broken until I figure out where they moved to. It's an incomplete
solution.
Particularly if you start dealing with comsumer electronics which need to
authenticate. Is the Hitachi X.500 server supposed to handle the load for
all of them? What if you compromise that server? Every VCR in the world is
under your control <g>.. worse, if you make a business keep track of its
own hardware, you only need to do a denial-of-service attack on their key
server to shut down all business operations. ugly!
I just think the identifier <-> certificate table should be spread far and
wide all over the net, and the IDs need to be rock-solid.
-graydon <graydon@pobox.com>