RE: NEW Data type for certificate selection ?

[Ed Gerck <egerck@xxxxxxxxxxxxxxxxxxx>]

On Thu, 1 Oct 1998, Anders Rundgren wrote:

>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 :-), 

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
>using a valid certificate (be it electronical or physical) where the certificate
>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
>all parties as you can have a life-time password/userid replacement with
>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
>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.
>

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                     egerck@novaware.cps.softex.br
http://novaware.cps.softex.br