comments on <draft-ietf-spki-cert-theory-02.txt>

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Dear All -

In light of the work on security re authentication, access controls and
TLS and SASL, etc I thought I would comment on this doc on this list -
as it could affect the work - Badly

<draft-ietf-spki-cert-theory-02.txt> - note its theory....

.

Item 1 the text of the document

"2.2 The X.500 dream and its failure"

 It was approximately ten years after Kohnfelder that the X.500
 proposal took form in the ISO.  X.500 was to be a global, distributed
database of named entities: people, computers, printers, etc.  In other
words, it was to be a global, on-line telephone book.  The organizations
owning some portion of the name space would maintain that portion and
possibly even provide the computers on which it was stored.  To record
the permission to modify nodes in this global name space X.509
certificates were defined.  An X.509 certificate bound a so-called
distinguished name to a public key.  The distinguished name was a path
in the X.500 database, identifying a node in that database. 
It is now obvious that the X.500 dream can not succeed.

((Alan: One cannot see what one does not recognise - De Bono - the art
of lateral thinking" ))
  
The designers had overlooked the fact that organizations consider their
name spaces (e.g., their employee lists) to be confidential.  For
example, does anyone really believe that the CIA will put its employee
list up on the web, in the form of a globally accessibleX.500 database?
Will IBM?

Alan - Comment:
On this section may I suggest the Authors revisit the role of X.500 and
assume X.500 is about distributed, object oriented name based
transaction systems. I will be happy to provide documents, workshop
material and presentations if required. 

It seems totally illogical to make a statement eg.  that because the CIA
don't publish all its employee list that X.500 wont work and has failed.

This is like saying that because some Defence organisations write down
Top Secret orders with pen and paper - on some pieces of paper and keep
them private - within the whole world that runs on paper - that the
worlds Books and News papers don't work, should not be written, be
published or read....

Logic - wherefore art thou ?




NEXT
Item 2 the text of the document

"4.1.2 SPKI global identifiers"
One of the fundamental realizations behind SPKI is that every user of a
public key has a global name: the public key itself.  The name may not
be pronounceable and certainly not easily typed, but it is globally
unique.  It also has the advantage of not needing a certificate to tie
it to the user's public key.
 If a given cryptographic hash function is collision-free, then the hash
of the public key is also a globally unique identifier for the
keyholder.  The base64 representation of that hash is a text string that
is a globally unique identifier for the keyholder.  Neither of these
needs a certificate to tie it to the corresponding public key.


Alan Comment:
This section promotes the situation that my public key can be held by a
funny self defined number in some funny defined space. This obviously
helps the globally dispersed recipients of my transactions to find the
key material - and in fact verify the trust of the issuer. :-)))

For EC- authenticated signatures systems need to scale - Key material
has to be tied commercially recognised names within a vertical market
(banks, telecoms, car rental, etc -) and held in a directory so people
who do not understand ASN.1, UTF 8 and hexadecimal notation can buy pots
and pans with a "certficate/plastic card" from a store that also does
not understand ASN.1, UTF8, etc.. I don't understand why this basic
issue is still in doubt. Perhaps the mis understanding re X.500 is to
blame.






NEXT
Item 3 the text of the document
"7.1 Key and certificate storage"
 The term PKI is generally assumed to refer to an X.500 style global
directory of certificates.  We have rejected global directories of
extended common names on security grounds, even though SPKI includes the
substring PKI.  Instead, we take the term PKI to refer to a general,
distributed use of public keys empowered by certificates rather than
assume some structure for certificate storage or official Certificate
Authorities.


Alan Comment:
This statement presents an opinion on the definition of PKI which is
wrong and then pollutes it to make it meaningless.
PKI = Public - in the context of Asymmetric Key systems - Public means
the PUBLIC KEY - not the world or the public at large or a government
institution.

PKI - Key is as before - concatenated with PUBLIC
 
Infrastructure - means the systems (functions, protocols, information
sets), the procedures, the algorithms, etc (ie the machines) and the
people-procedure collective) that form the distribution and management
of the public keys. 

The polluted term is saying its only key USE - therefore the
Infrastructure issues and design is lost and therefore we are all left
wondering how these things are built, institutionalised and managed with
people and machines in the global EC market place.

I see no value in representing a common, widely used term wrong -  and
then depreciating it to end up with something which does not cover the
scope or intent what the original term set out to do... and at the same
time, leave uninformed readers confused and lacking the very system
design perspectives we need for and embraced by the term PKI.



Alan - Common Threads
Yet again the debate seems to be be - globally applied distributed
systems are too complex and cannot be be built, that simpler things are
are better (But as we all know they only solve simple problems). And in
addition making keys have local identities for a local environment is
promoted as the answer. Ie. It is simpler as a mechanism to protect my
data in my environment for me to access.. This is not very valuable.
But that is the LDAP approach isnt it. My data in my server for me.

May I beg the question - I seem to be commenting from the position that
we  should develop scaleable technology and system designs to evolve the
Internet. Whereas many of the arguments presented in draft document cite
big is bad (when its not that big), X... has failed ... and simple -
unscaleable, proprietary  is better. So is the task of this group purely
to invent a concoction of single interface and proprietary data
mechanisms that have inbuilt technical and operational scaling issues.
Or can the work embrace debate on distributed system design, scaling and
operational overhead matters. 
When it comes to PKI - and the scaleability of key management - if that
is not right one can put all the things like TSL, SASL and any other
security mechanism proposed in the bin.

as for spki without an infrastructure design, a directory system and
hexadecimally named certificates - good luck to all those who deploy.

regards alan