i'm missing something here. with certificates, one can,
at least in theory, attempt to do path discovery/validation,
which seems to be able to do much better than "database
lookups" in trying to deal with "realm multiplicity." one can
also attempt to specify and apply policies as part of the
path validation exercise. one can't do this with older
PGP keys, but one can get an X.509 certificate for at
least some PGP keys (i haven't tried it with all the
different flavors of keys).
granted, this could chew up lots of cycles and network
time. also, there may be reasons to not want to accept
certificates from third parties, such as verisign class
one certificates, as they don't really give much authentication,
but that seems like something that could be handled by
policy in the verification path.
as to authorization issues, one could look into attribute
certificates, but that seems orthogonal to authentication
(and can't be done in a pure PGP or S/MIME context
anyway, as far as i know).
-paul
--On Friday, 25 August, 2000 12:34 -0700 Michael Thomas <[EMAIL PROTECTED]>
wrote:
> Henning Schulzrinne writes:
> > Michael Thomas wrote:
> > > Not true. You are still guessing that the UAS will
> > > trust that certificate hierarchy. That may not be
> > > a valid assumption. It's the exact same problem
> > > as guessing which basic/digest realm might be needed
> > > along the way. I can just as easily posit a global
> > > symmetric key realm as a global PKI realm. Both
> > > are fantasies.
> >
> > Given the practical success of having CA's embedded in millions of web
> > clients, this seems at least feasible and works millions of times each
> > day, even though it's less than ideal if you're a new CA and want to
> be > recognized as such.
>
> Just because I trust your certificate to name
> you as Henning doesn't relieve me of knowing
> what you're authorized for. That means that I
> keep it in some sort of database or it needs
> to be transfered in the authentication token
> (cert, ticket). Keeping a symmetric key in that
> database as well doesn't seem to much of a
> stretch.
>
> So, I still don't see what you've bought
> yourself with PKI, other than lots of CPU
> cycles to do private key operations. If you
> encode the authorization into the cert you
> fall back into the same problem of realm
> multiplicity, if you don't you've consigned
> yourself to database lookups.
>
> > This does not mean that you couldn't use a ticket-based system
> (Kerberos > and kin), but we're here talking about the existing SIP
> authentication > mechanisms Basic, Digest and PGP (or, in the case of
> S/MIME, trivially > added), not something that doesn't exist yet in our
> context.
>
> There are two possiblities:
>
> 1) Carry the authentication in SIP itself which runs
> into the MTU problems, naively.
> 2) Carry the authentication in a separate protocol
> (such as the results of the KINK to-be-WG) and
> reuse digest authentication as the means of
> generating the keyed hash.
>
> I generally don't like reliance on third party
> protocols/questionable layering, but it is a
> possiblity and is somewhat inherent in both
> IPsec and TLS schemes (less so with TLS, but
> still).
