[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
Peter Williams <peter@verisign.com> said:
> The requriements for SPKI naming are surely these:
Hold it right there. I won't speak for the group, but I might take
issue with the idea of SPKI having any "naming" requirements at all.
One major proposal here is Carl's, which says that a name is an
application-specific kind of privilege, not a certificate attribute.
My elaborations on all of that have concluded that the interpretation
of the application-specific data in a certificate is the business of
the relying party.
I must agree that a name is a very important privilege, and should be
supported by all of the kinds of things you enumerate, and that all
those things should be the subject of wide industry agreement, and
standards, and enforceable by contract and criminal law. However, from
the point of view of SPKI as we have been discussing it, naming is just
one of many different kinds of privilege conferrable by a certificate.
I have not argued, as many have, that the DN is necessarily a bad thing,
but that it's application data, not a certificate structural element,
because name certificates are only one kind of certificate that can exist.
Perhaps it's that you are equating SDSI to SPKI. In my mind (others should
speak for themselves, particularly if they disagree) SDSI is merely one way
of looking at the problem, and does not necessarily require name-centricity
in implementation. Maybe it does, but SDSI alone is not what SPKI is about,
at least not from what I have read from the founders of the working group,
nor is PolicyMaker, though we are all learning from their ideas, which have
been some of the most eloquent and complete so far put down.
> As naming and keyingn are tied in this system of ideas through the
> notion of individual posession (a anglo-saxon imperialist notion, but
> lts ignore this class of criticism, for now) there are unstated
> assumptions as to the properties of the keying material.
>
I'll try to get through that one. I don't believe that this is necessarily
so.
> There seem to be assumptions that are satisfied magically:
>
> (1) no principal shall ever share a keyset
Magic it is, in this scheme and all others... it depends solely on the
security precautions of the keyholders. But perhaps I gloss over your
meaning. You appear to assume that the real identity is that of the name. But
if a name is only a privilege, conferred by one who ultimately decides
whether and how to honor that privilege, it really doesn't matter how
many names you have. I'm Brian to my friends, Daddy to my children,
and I won't tell you the cute names my parents gave me, nor my wife.
If I work for the CIA, I may be known by other names in other countries.
But all of those names represent me, and if I choose to use the same
keying material for all of them, I may be foolish, but it's my business
and no one else's, because the key is me.
> (2) the compromise of a key shall be immediately signalled and
> resolved throughout the entire principal network
Likewise. Naming has nothing to do with that.
> (3) verification of the uniqueness of keying material shall be guaranteed
> during each naming attestation by each and every principal in the domain
Perhaps you could explain why this should be so.
> (4) legal trust guarantees are indicated
If the people who agree to use public-key certificates to grant legally
binding names want to do this (and of course they will; I will anyway),
they will set up the legal and technical framework for doing this. As
indeed the x.509 community are now doing. My use of SPKI-type concepts
has to do with expanding certification beyond the concept of names.
I'm in over my head, and perhaps I shouldn't be speaking, but as an early
implementor and user of the ideas I do have a feeling about how these things
should go. I'm waiting for others who are up to understanding your specific
arguments to agree or counter.
Anybody?
Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@cdmnet.com(or primary.net)
One Bell Center, Room 23Q1 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 331 2755