[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: My comments on the X/Open PKI requirements document
I think that there is a deeper problem here. What appears to me
to be going on is research by committee. Just because people may
be screaming for a public key infrastructure does not mean that
people currently have a model of how to build one.
I fee
I fear that the various standards being proposed may in some cases be
hinderances rather than helps. If X.509v3 had been designed from
scracth rather than being based on X.509v1 I believe that the result
would have been better. X.509v1 was based arround a missconception that
identity was the central issue.
I beliebve that the central issue is not the certificate format
at all. We could solve the problem of certificate syntax in a few days
using RFC822 if we put our minds to it. The real difficulty is the
definition of the set of asttributes of trust to be used.
The question I belive we should ebe asking is not how to standardize
a public key infrastructure, instead we should ask what parts of
a public key infrastructure need to be standardized.
A key point to consider is the difference between email and online
(Web type) trust establishment. In email there is unfortunately an
assupmtion built in that the reader is not connected to the Internet.
The reader must thius be sent the entire trust context (i.e. certificate
chain) if the message is to be verifiable), If we consider the question
odf a user connected to the Internet directly with full ftp http etc
avaliable the flexibility is dramatically increased. We do not need to send
the entire certificate chain over with a message. We do not need to
restrict ourselves to a single chain even.
The power of the Web is that it moves beyond the traditional objective
approch to system design. In the objective approch we attempt to define
terms in a universal mode. These definitions are entirely self contained
and do not require interpretation which is dependent on the context.
In the subjective approach we explicity permit subjective terms, a subjective
term in this case being simply a referent for a term outside the context
of the Universal. These external referents are expressed in an objective
form on the Web using URLs.
This distinction between subjective and objective lies behing PICs. The
system allows anuyone to become a censor provided they have ownership
of a part of URI space. PICS labels consist of a URI and a rating. In this
case the rating does not need to be absolute, it does not need to be
universaly accepted across the entire Internet community. It only needs
to be commonly accepted amongst the user base. Note also that there is no
technica l requirement for a PICS label to be relovable. Its meaning comes
from the concurrence of use. This binding of semantics through the common
use of a referent is what Shakespear meant in his phrase "Would a rose
by any other name smell a s sewwt?".
[NB sorry for the typing, this dialup does not have delete or edit capability]
My suggestion for a certificate hierarchy would begin from acc a set of
definitions:
1) An assertion is a binding of a name to a name which is given apriori
a semantic interpretation.
2) A certificate is an authenticated assertion.
The task which we should solve is the task of establishing a commonly
held truth beteween the principals in a transaction. This is a difficult task,
one which is inherently subjective. Calling ist it trust in the hope that
trust miught prove to be easier to reach common agreement on than truth
is not a useful move. Trust and truth are tightly bound. I believe that
men visited the moon because b I trust the history books which assert
this. ?Trust and trusth are thus closely bound. If we take a hermeneutic
view on the issue we would attempt to make statements within the belief
system of the observer to arrive a t a common truth.
Since syntax is the least important consideration and I am s addressing
the issue of structure of a certificate/public key infrastructure I will
express my more concrete ideas in RFC822. The following might be and
assertion:
Va
Not-Valid-Before: 1996-04-01 12:00:00
Not-Valid-After: 1996-05-01 12:00:00
Assert: http://www.whitehouse.gov/%* signed=KEY:RSA:whitehoudse.org
BIND: KEY:RSA:whitehouse.org RSA:grwehgfrqwkqwjhegrqw24r32hg4r12uy...
This assertion states that the whitehouse web pages are signed under a
named key which is subsequently bound to an RSA public key. Note the
use of URIs for Keys, whether names for keys or keys themselves.
We could further embelish the definition of the KEY: form. I put the
keytype into the name because then we may negotiate over keys and algorithms
simultanteously. [Which I consider necessary].
We turn the assertion into a certificate simply by signing it. A signature
might be bound to the sassertion directly or indirecty. By direct binding I
mean simply taking RSA(PKCS1(MD5(assertion))). The problem with this form
is that it is not possible to attach an intention tho the act of binding.
What is meant by a digital signature anyway? Does it mean that the signatory authored the document, read it, asserts to its validity or what?
I would like to introduce a new form of certificate signature in order to
avoid the semantic problems involved in reusing PKCS1 forms. The recent
Belair-Rogaway work provides us with an opportunity to do this. Essentially
I want to create a two valued function being Sig(message, intention) where
intention standes for the intention behind signing the dociument.
Intentions might invclude:-
Authored - Teh e The signatoryt authored the document.
Notorized - The signatory notorizes the document
Wanrrants - The signatory warrants that the assertion is true.
Here it is almost certain that we need to include some
additional terms for limiting liability.
Summary
Essentially I am proposing that we divide the key infrastructure problem
into a series of tasks. The first of these is to provide a URI for the
various terms we wish to deal with (keys, names for keys, propositions
etc). Next we divide up the issue of creating an assertion from va
authenticating it to produce a certificate. [NB all systems have as their
base an assertion, or axiom, not a authenticated assertion]. Finaly we need
to consider the relationship of the term assertions being authenticated
and the intention of the signatory.
Phill
PS sorry again for the poor formatting, my typing is not good on a reduced
size keyboard and I do not have deleter facilities :-(
References: