Subject: RE: NEW Data type for certificate selection ?

From: Anders Rundgren <[email-masked]>
Date: Thu, 1 Oct 1998 09:07:20 +0200

Hi Ed,
>Your suggestion:
>
>The solution is to add "salt" -- like it is done in UNIX passwords.
>For example, you can add 50 chars of salt or as many as you want -- a
>passphrase. The point here is that since you know the SSN and the
>salt, no one else can guess the SSN from a dictionary attack on only
>9 digits. Better still, you can change the hash in a new cert and
>keep the SSN constant, by changing the salt, so no one can verify
>your SSN in a new cert without your cooperation.

As my countryman Stefan already pointed out we can argue for centuries about the
use of SSNs or as I would call them: PPIT - Persistent Personal Identity Tag.

Assuming that you *actually* *have* *such* *a* *scheme* you loose all the benefits of
PPITs by applying your "salted" methods to PPITs.  PPITs are not only designed to
make big-brothers job easier :-), but to allow users to authenticate themselves
using a valid certificate (be it electronical or physical) where the certificate
receiver only must know what issuers (and domain) to trust.  This is a major benefit for
all parties as you can have a life-time password/userid replacement with
full security (technically speaking) independent on actual certificate.  It simply
cuts costs and confusion (at the expense of personal integrity).   If this is
good or not is something the market (and in some cases national laws)
will decide. My personal opinion is that if successful PKIs (Stefan!) are
established based on PPITs the disbeliveers *may* change their mind.

The general-purpose browser solution is as follows:

The authenticating server may surely *suggest* a list of possible certificate types
that it may accept because it is always *you* (the user) that should manually
select the proper one.  In case you feel that a cert with PPIT could create a disaster
if you accidentally gave it to a wrong server the solution would be to have a local
(user-defined) set of valid servers (i.e. their public keys).

To insert a new server would require a few more clicks.  I.e. similar to ActiveX
controls or signed Java Applets.  Such servers would typically be
governmental (who gave you the PPIT) and a *few* other parties that
you hopefully trust like your bank or employer.   A similar scheme could be used
for defining a list of valid receivers of mail signed with a cert containing an PPIT
(or other sensitive information). 

Anders Rundgren
Senior Internet E-commerce Architect

---

From: Ed Gerck <[email-masked]>
Date: Thu, 1 Oct 1998 12:09:57 -0300 (EST)

On Thu, 1 Oct 1998, Anders Rundgren wrote:

>make big-brothers job easier :-), 

Anders:

I think you can call YAPITs (Yet Another Personal Information Token)
whatever you like and I will further grant anyone the right to make
his private information public -- IF he so desires. However, NOT by
design, which is what you apparently defend to allow as a legitimate
feature of a "security design". What you imply is similar to the
"rationale" for GAK-ware considerations.

> but to allow users to authenticate themselves
>receiver only must know what issuers (and domain) to trust.  
>

This has nothing to do with YAPITs. It has to do with issuer trust
and key challenge-response. 

I affirm that a certificate may only be its signature in size -- a 20
byte string -- and that suffices to allow anything you can do with
any kilobyte-size X509v3 cert, or even mega-byte size. So, YAPTIs do
not really belong to certs as a functional need. To ignore this is to
ignore what certificates are.

>This is a major benefit for
>full security (technically speaking) independent on actual certificate.

You are unfortunately fully mistaken. What you describe is similar to
Faustus' dilemma: your security now versus your soul forever. Well,
we all know how it ends. You cannot trade your life-long privacy in
exchange for some degree of security now. 

>  It simply
>cuts costs and confusion (at the expense of personal integrity).  

If an expense cannot be paid back (as privacy cannot) then it is not
an expense -- it is called a loss, in any country and possibly also
in yours as you speak about your countryman above.

I'd rather think non-parochially and strive to find and define
methods which assert equal security rights -- irrespective of
computational power, influence or supplier.

 > If this is

Each country/company/person can do as they please, but in a
competitive world market the one with least information exposure has
a large advantadge. BTW, is that not what security is all about ? ;-)

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     [email-masked]
http://novaware.cps.softex.br