Re: Proposal for a new PKI model (At least I hope it's new)
From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 09/07/03
- Next message: Mok-Kong Shen: "Re: Proposal for a new PKI model (At least I hope it's new)"
- Previous message: M.S. Bob: "Re: cryptology graduate school advice"
- In reply to: Bryan Olson: "Re: Proposal for a new PKI model (At least I hope it's new)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 07 Sep 2003 00:29:14 GMT
Bryan Olson <fakeaddress@nowhere.org> writes:
> Whoever registers a domain name is the authority for the
> subdomain rooted at the name. In any case, I tend to be
> sceptical of various proposals to do twice over what we haven't
> yet succeeded in getting done once.
part of the problem is typically that the need is to authenticate the
entity that supposedly owns the domain. The real "problem" in the
CA/PKI scenario for SSL domain name certificates ... is that the
original registration of the domain name failed to provided an
adequate authentication mechanism.
SSL domain name certificates attempt to do an after the fact fixup of
the authentication difficiency (the fixup itself then results in a
number of shortcomings). The domain name infrastructure has some
information that can be used to establish a real world
identification. Somebody comes to the CA and requests a SSL domain
name certificate that can be an aid in (SSL) authentication processes
(as opposed to identification processes). The CA has to check that the
requester is the same as the entity that owns the domain name. Since
there is no authentication information, the CA needs to map the
information from the domain name infrastructure to some external
identification ... and then establish that the certificate requesting
entity also can map to the same external identification.
To improve/simplify the CA's job for SSL domain name certificates, the
CA industry wants the domain name infrastructure to register a public
key as part of the domain name registration. Then when somebody is
asking for a certificate (actually any domain related activity)
... the CA can retrieve the public key from the domain name
infrastructure ... and perform an authentication operation ... w/o
going thru all the difficult identification gorp. However, if a CA
can retrieve the public key from the domain name infrastructure for
authentication ... then presumably anybody can retrieve the same
public key for authentication .... significantly negating the need for
a CA signed certificate in order to perform authentication operations.
Now comes the issue of delegation. The current infrastructure has
CA "root" public keys preloaded into browsers and a convention that
SSL domain name certificates can be authenticated by any preloaded
root key.
So it is possible to go one of two ways:
1) all SSL servers can also have domain name infrastructure entries
with their corresponding public keys. There is no trust delegation
and/or trust hierarchy (in the client process), every server that
wants to do SSL has their public key registered in the domain name
infrastructure. The purpose of the domain name ownership public key is
to authenticate all transactions with the domain name owner. One such
transaction, is a digital signed transaction (by the domain name
owner) for the registration of public keys for each SSL server. There
is a trust hierarchy involved with the registration of the additional
public keys ... but it doesn't need to be visible in the client SSL
operation (no stale, static certificates).
2) for those that want a domain-related trust hierarchy with
certificates ... rather than requiring that domain-related hierarchy
certificates be signed by CA root that has been preloaded into some
software ... just require that all domain-related hierarchy certicates
be signed by a private key corresponding to a public key registered in
the domain name infrastructure (for that domain). NOTE: from an
information theory standpoint, if a CA is willing to accept a domain
name public key as the authoritative authentication reference for
generating standpoint, then that key is the "root" in the real trust
hierarchy (even if it doesn't show up in PKI trust hierarchy visible
to clients). If it is logically the "real" trust root, then the claim
can be made that the CA "intermediate" root key can be eliminated w/o
impacting the trust hierarchy.
For offline operation, some set of such keys can be
precashed/preloaded locally. Trivial in the DNS implementation to even
tag domain ownership public keys as to signatures only, encryption
only, signatures+encryption, certificate signatures (as opposed to
transaction/message signatures).
#1 has the advantage that it can be timely and dynamically updated
without needing to worry about old, stale, static mappings floating
around all over the world.
dns web site, including drafts in progress for DNSEXT (subsumes DNSSET
and DNSIND)
http://www.dns.net/dnsrd/docs/id.html
including significant update to RFC2535.
somewhat related is IETF authorization, authentication and accounting
http://www.aaaarch.org/index.html
-- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
- Next message: Mok-Kong Shen: "Re: Proposal for a new PKI model (At least I hope it's new)"
- Previous message: M.S. Bob: "Re: cryptology graduate school advice"
- In reply to: Bryan Olson: "Re: Proposal for a new PKI model (At least I hope it's new)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
