Subject: Re: QC DN "qualities". Was: I-D ACTION:draft-ietf-pkix-qc-04.txt

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 23 Jul 2000 16:17:44 +0200

Ed,
I know that you can go on and on forever (me too!) so I think we can conclude
that we differ in opinions and thats about it.  But of course I will answer...

>Anders,
>what you ask cannot be done in X.509/PKIX and will fail if tried.

The idea to make QC a PKIX-item was probably not that great given the wide scope of such a thing.
But technically I don't see any unsolvable problems.

>There are three main reasons for failure:
>
>1. technical:  The old Bob Jones example.

Information about the old, the dead, and the young Bob Jones etc. is stored
in variuos registers that the QC RA/CA has access to.

>2. commercial: CAs make mistakes and may issue the same DN for
>two different people. They do not want to be liable for it.

Exactly how much it will cost a CA to make a mistake (which has happened
and will happen) will vary quite a bit.   It will not be a part of the QC-draft.
Actually a *minor* error rate does not at all make the system useless.  Compare
it to anyhting else we have today and it should be a vast improvement!

Then there is something that the CAs in Sweden don't understand,
but which I believe is very important: To "absolutely identify" (whatever that
really means) an individual is NOT as important as guaranteeing that two different individuals
do not get the same ID (DN).  The former is getting pretty impossible given the society we
live in with a lot of brief contacts and high mobility, while the latter can be done with
high precision using fairly simple technical procdures such a biometrics, register data, 
various credentials like old ID-cards etc.  Cheap and quick DNA-fingerprinting may be in
reach within 5-10 years.  There are other smarter ways of differentiating which I unfortunately
(for commercial reasons) can't go into here...

Maybe the term "relative identity" is applicable :-)

The reason that the differentiator mechanism is much more important is that you
usually don't get access to huge values without being known as an individual in
the first place. 

>3. revocation: if a cert is revoked with DN "X" for entity A then that DN
>may be reused for entity B. However, revocation of certificates does
>not revoke certs -- it merely puts them in a black list. There may be
>any number of certs with "X" for A in the world which have not yet
>been revoked by a client app, and may thus clash with  a cert that also
>has  "X" but for B.

We will see what the *final* QC draft will ends up with!  I would say I will be *very*
surpriced if it allows DN reuse as it is technically a no-brainer given that
the CA knows its subjects.  And if it does not, why bother with QCs?

>There are also other reasons. It is thus much better security-wise to avoid
>a false sense of security and leave matters as they are now.  A certificate
>is a hint, QC or not QC, no more, no less.

If QC is just a hint it is REDUNDANT.  I can we *great* ease produce QC-like
certificates on my W2K-server and distribute them out-of-band to RPs.  Does it make me a
QC-CA?  I hope not.

>Cheers,

U 2!
Anders

---

From: Ed Gerck <[email-masked]>
Date: Sun, 23 Jul 2000 07:51:22 -0700

Anders Rundgren wrote:

> Ed Gerck wrote:

In the Internet no one can control both sides of the communication
channel, neither sending nor receiving.   This is the major problem in
trying to define unique DNs based on X.500 -- you think you have all your
bases covered, that DN "X" uniquely identifies A and yet, it may also
identify B, C and so on.  You have an example right in my phrase!

I wrote "The old Bob Jones example" and meant the old example
of "Bob Jones."   You understood the example of  "old Bob Jones"!

The same happens when you try to identify Bob Jones, and I will cite
from the "old example" of Bob Jones (with yet another use of "old"
because Bob Jones is an "old friend" -- which does not mean that Bob
Jones is old, either):

 The second [problem] is that even if some large corporation were to deploy
 X.500 internally and generate X.509 certificates using those DNs [X509], it
 would make those DNs unique by addition of information of relevance to the
corporation, such as operational unit, building name or mail stop. Such a
 unique name is not adequate to disambiguate a common name from the point
 of view of all possible users of the certificate. That is, Alice may have an old
 friend, Bob Jones, at IBM but have no idea of his mail stop, building name or
 operational unit. Although she has a fully trusted identity certificate from IBM
 for each employed Bob Jones, she can not trust any of them to be her friend.
 Therefore, the certificate has failed in its task of binding identity to a public key.

This old example is from my old friend Carl Ellison and is given in the old URL
of 1996:
http://usenix.org/publications/library/proceedings/sec96/full_papers/ellison/index.html

> >been revoked by a client app, and may thus clash with  a cert that also

there are still more problems as we follow the logic in second-order, third-order,
etc.

> certificates on my W2K-server and distribute them out-of-band to RPs.  Does it make me a

You already accept that you can produce QC-like certificates. You just need to
ask ... why not?  If you have clients, you are already trusted by them and you may
as well issue their QC-certificates.  You know them much better than another
company that never even heard of them, no?

Besides, note that creating national IDs in order to uniquely identify people is
forbidden by the constittution of ALL EC countries.  What would a certificate
that purports to uniquely identify people within a country be but ... a national ID?
Where is Sweden, BTW?

Cheers,

Ed Gerck