[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-spki-cert-theory-00.txt
On Wed, 3 Dec 1997, Xavier Serret wrote:
-> > I think that the document has serious flaws and should be ammended, as
-> > well as the name SPKI no longer reflects the result of the merge with
-> > SDSI. Specifically, my comments are given below for each point.
-> >
-> > -> The SPKI Working Group has developed a standard form of digital
-> > -> certificate that is both more general and simpler than what is
-> > -> traditionally considered to be a certificate. Since the word
-> > -> ''certificate'' was first used by Loren Kohnfelder in 1978 to refer to
-> > -> a signed record holding a name and a public key, it has been assumed
-> > -> that the only purpose of a certificate has been to bind a public key
-> > -> to a globally unique name and therefore to a person. This binding
-> > -> was assumed both necessary and sufficient for security.
-> >
-> > This last phrase is wrong, because X.509 (the standard alluded to, and
-> > mostly used) does not say so or assumes it. Here, there are actually three
-> > entities and respective bindings: key, name, person. The definitions of
-> > key, name and their binding are handled by X.509, whereas the binding of
-> > either with a person (and a person's qualifications) are handled by the
-> > CA's CPS -- which is outside the scope of X.509. The same happens for PGP.
-> >
->
-> Yes the X.509 standard does not assume such a binding. The assumption is
-> in its
-> philosophy of use, and derived from the X.500 directory, which really
-> had the
-> pretension to assign a unique name to each 3D entity involved with the
-> computer
-> networks. CA's are doing now a days what was intended to be done by the
-> directory,
-> with the problem that the directory was assumed to have a unique(s) full
-> trusted root (the
-> government), and all CA's put themselves as roots.
->
OK, you agree that the phrase in the SPKI document is wrong.
As to the CAs doing name assignment, this is actually mandated by X.509.
The problem of connecting different CA's is solved in X.509 by forming a
PKI of CAs -- which is possible in principle because all CAs follow the
*same* naming convention. But, these points are not the issue here. Nor,
any possible X.509 flaw. The issue is a statement that is incorrect.
->
-> > Thus, current certificates do not assume that such bindings (plural, here)
-> > are necessary and sufficient for security -- on the contrary, certificates
-> > such as X.509 and PGP just provide for a security framework to be reached
-> > as a function of the various CPSs and how they are to be interpreted by
-> > each verifier.
-> >
->
-> This is true for PGP, which was thought form the beginning with this
-> assumptions
-> in mind, not for X.509 ( but it can be used too ... denaturalized)
->
PGP does not prohibit pseudonyms to be used, which amounts to a binding
only between name (here, an e-mail) and a key. Further, PGP does not
depend on such binding for security, but on the web-of-trust, which is a
binding of quite a different sort (between a person and respective
acquaintances).
-> > Further, X.509 (and PGP) clearly lay out several purposes besides name
-> > binding for certificates, as given by the extensions in X.509v3, including
-> > authorizations such as the possibility to be used as a root-cert for
-> > signing other certs, etc.
-> >
->
-> The problem of the X.509 is its support with extensions, that means not
-> mandatory to be understand -- Yes the standard says that a non
-> understood
-> extension results in certificate reject, what I mean is people is not
-> forced
-> to create them with this extensions ( I normally do not do merely
-> because their
-> complexity).
->
Extensions in X.509 may be complex but are flexible. The point here is
that using certs for other purposes than just name-key binding has been
around a while with X.509 and is not true that the "only purpose" of a
X.509 cert is to bind a name with a key.
-> > ->
-> > -> The working group has found that the creation of a globally unique
-> > -> name is neither necessary nor sufficient for Internet security or
-> > -> electronic commerce. In fact, use of global names can introduce a
-> > -> security flaw.
-> >
->
-> > This is plain wrong. If globally unique names can be defined then it is a
-> > sufficient condition (together with other suitable conditions for the
-> > public-key, etc.) to uniquely define the agents of actions, globally. This
-> > has nothing to do with the fact that a globally unique name cannot be
-> > defined with current technology, in the general case. In fact,
-> > counter-paraphrasing the last phrase above, use of global names (that
-> > deserve the name) could never introduce security flaws!
-> >
->
-> Not security flaw, privacy flaw. And security is indented to protect
-> privacy.
The SPKI document stresses that global names would mean a "security flaw"
and I understand you agree that this is incorrect because it is not a
"security flaw".
Fine, but it is not a "privacy flaw" either, because an agent may be
uniquely defined by a (true) global name but still keep its full privacy.
Further, one must not mistake knowledge of credit-access data (such as a
bank account number, Social Security Number, etc.) with identity-access
data -- which are, after all, a reason to use a certificate. Further, if
the person does not want his identity to be known and wants all his
actions to be perfectly anonymous then he may still use a cryptographic
hash of his global name and be both anonymous and globally unique, or he
may use whatever name he pleases (and is accepted).
Thus, again, the use of (true) global names could never introduce
security or privacy flaws.
Further, allowing for mechanisms to preserve privacy where it is desired
(and accepted) has nothing to do with the need to control and find the
miscreants that may use false identities or false authorizations, which is
the crying need in the Internet today.
->
-> > -> Therefore, we define certificate forms for binding
-> > -> local names to keys (to retain security while offering the
-> > -> convenience of meaningful names) and for assigning authorizations to
-> > -> keys (to provide adequate information for real applications). These
-> > -> forms can be used alone or together.
-> > ->
-> >
-> > Of course, local names can only be locally meaningful and must be always
-> > isolated from any global context (where they may even collide) -- which
-> > makes them useless in a world PKI.
-> >
-> > To further discuss the issues, I assume that for the SPKI proposal there
-> > is no identity other than the key, so there is no entity authentication,
-> > just key authentication and all actions are performed in cyberspace. For
-> > SDSI, I assume that there is no identity of meaning to anyone other than
-> > to the CA, so all entities's names are only locally valid and all actions
-> > are again performed in cyberspace.
-> >
-> > So, as SPKI was merged with SDSI, SPKI had indeed to consider all names to
-> > be local -- which essentially:
-> >
-> > (i) gives up the hope of any binding between cyberspace entities and
-> > real-world legal or accountable entities, and
-> >
-> > (ii) takes away the "Infrastructure" aspect of the SPKI name.
-> >
-> > (These problems are not to be solved by SPKI, but by a "subpoena
-> > certificate" as Carl Ellison has named it, which is a service to be paid
-> > for by the user and which will be treated in the future. Which has nothing
-> > to do with the SPKI proposal and which certainly brings up problems of its
-> > own.)
-> >
-> > Thus, I fail to see where SPKI/SDSI would offer a better situation than
-> > X.509, regarding any security goal for the worldwide Internet. In fact,
-> > SPKI take away any possible semantics that could be offered by a CA's CPS,
-> > in order to resolve naming conflicts or assignments in a global scale. The
-> > "may delegate" flag in SPKI is another open question, where anyone may
-> > fake a cert with an authorization for the key of another person (a framing
-> > attack). Further, SPKI wrongly considers trust to be fully transitive and
-> > distributive -- for which, X.509 and PGP at least offer a partial way out.
-> >
->
-> But the delegated trust is not full, is just a subset of it.
->
Delegated trust is one of the aspects mentioned above. However, I must
note that delegated trust is always full in its set of authorizations. If
you let Bob authorize matters of X, it is 100% Bob's decision regarding
the full set of X.
-> > Thus, the SPKI proposal should refrain from making misleading statements
-> > on global names and should also delete the words "Public-Key
-> > Infrastructure" from its name because it only deals with local names --
-> > which, of course, will never allow a PKI to be built. The local names of
-> > "SPKI/SDSI" are forever local and have no significance outside their local
-> > trust domain.
-> >
->
-> Ok ,here the problem is in the assumption of globally. Global domains,
-> names ...
-> they do not exist. All the domains are always sub domains of bigger
-> ones. Thinking
-> on having a truly global domain is like when the people from states
-> proclaim that
-> the final of the NBA is the world final Basketball (sorry! ... maybe
-> somebody have a better ex.)
Your example is actually very good, as it also applies to the so-called
world-series (baseball) in the US. So, a locally-defined context (US
baseball competition) which has no regard for a world-context will (except
by happenstance) fail to fit in the world-context -- and local name
domains do not lead to a coherent global scheme (exception, happenstance).
But this is not the point here, but that the SPKI text should not affirm
that globally unique names are a "security flaw" (or, even a "privacy
flaw"), as discussed above.
-> With SPKI is easy to create a trust tree form the bottom, (the easy
-> parts), nothing says that one day
-> we all agree and we will have a local world-sized domain. This is very
-> close to the successful Internet history.
->
Any SPKI trust tree is always independent from other SPKI trees, is always
local and does not reach into the legal or accountable personae behind the
keyholders. Thus, there is no reason to assume that a large number of such
independent trees will provide a coherent and accountable world-sized
security framework, at any time in the future.
-> Finally I don't see why you put PGP and X.509 in the same level, they
-> have totally different philosophy.
->
>From a higher perspective, X.509, PGP and SKPI are all on the same level,
because they:
1. allow a verifier to accept or reject a certificate which contains data
from a subject, based on the declarations of an issuer, and
2. base such decision on pre-defined syntatic and semantic rules.
The differences between PGP, X.509 and SPKI are on their syntatic and
semantic rules -- but the referral mechanism is the same, with the two
parties in the dialogue accepting a third-party as the issuer. Even for
self-signed certs (a self-declared cert), because the issuer assumes a
different role (ie, a third role) than the subject -- where trust is
demanded from the issuer but not from the subject.
To contrast, DH key agreement cannot be seen on the same level as X.509,
PGP and SPKI -- because there is no issuer whatsoever.
Yours,
Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@laser.cps.softex.br
http://novaware.cps.softex.br
Follow-Ups:
References: