RE: NEW Data type for certificate selection ?

[Stefan Santesson <stefan@xxxxxxxxxxx>]

Ed,

I just want to clearify that I don't want to see any YAPITs (or any other
speciffic attribute) hardcoded by design into any certificate slection
mechanism. 
But I don't want to stop anyone from using it as selective criteria either.

To me the YAPIT (Yet Another Personal Information Token) discussion belongs
in completely different dimension independent of the certificate select
problem space. (even if it is an interesting subject).

/Stefan 

At 12:09 PM 10/1/98 -0300, Ed Gerck wrote:
>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
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------