RE: NEW Data type for certificate selection ?

[Ed Gerck <egerck@xxxxxxxxxxxxxxxxxxx>]

On Thu, 1 Oct 1998, Anders Rundgren wrote:

>Ed,
>You failed to comment on the *technical* part of my suggestion and went
>immediately to politics!  Please spend some time on that part in spite
>of the fact that you think Swedes are morons (we must be as we have used PPITs
>extensively the last 30 years or so).  And even morons want solutions to their
>stupid little problems. :-)

Anders:

I liked very much my visits to Sweden and Stockholm is specially
pretty, though I missed its Spring and Summer. It is also the leading
place in the world for ultra-short high-power Ti:Saphire lasers --
also selling to other Instituts in Europe including the Max-Planck in
Germany. One of the most hilarious things that happened to me in
Sweden was when I read a political comment in one of your neswpapers,
with an excellent drawing to go with it, that depicted two
politicians in a washbasin throwing words to one another -- and it
read "like ducks in a washbasin, happiliy throwing water at each
other and thinking that they are doing something great!"

I remember this now as I expect a better fate for this discussion.

>
>Note that unlike some certificates, certificates with PPITs
>are never published on a directory server. You may though check its status with
>OCSP or similar in case you (as a trusted party) received such a certificate. 

I wish to copy one of my earlier remarks on this, as I think it shows
that I had no qualms with what you say above:

 However, if we accept that there may be valid uses for "public-key
 certs" which are not public, with all the security and privacy risks
 that may ensue from such usage (such as when Bill trusts Monica that
 trusts Linda; or, when Bill cannot revoke a token that was given to
 Monica and which unfortunately Monica had to surrender) -- then we
 must consider that each "non-public" public-key cert and private-key
 will be handled either by a special application or by an interactive
 and possibly customized procedure in a general application (eg, a
 web browser). Which then answers subproblems (1) and (2) also for
 "non-public" public-key certs.


>
>>> 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. 
>
>Not at all. challenge-response verifies that you really are in the possession of the certificate.
>In the physical world you compare the ID-card picture with the face of the card-holder.
>

No, I think you overshoot the target. The point being that after a
sucessful challenge-response with client/server authentication in
SSL, you have a secure channel that you and your party can trust at
most as you both currently trust the CA cert used to authenticate the
server/client certs (I say at most because, of course, that trust
also depends on your certs, your applications, etc.  and not only on
the CA cert). Through that secure channel now you transit with
whatever information you may need and the other party be willing to
provide, be it PPITs, or YAPITs, or credit card numbers of course.

The first usual misconception here is when people confuse trust in a
certificate to trust in a certificate's contents -- too quite
different animals. In fact, the first is directly defined under X.509
or PKIX but the second depends on the CPS, which depends on each CA,
which systematically negate it.

The second usual misconception (derived from the first) is when
people confuse reliance on a cert with reliance on a cert's contents.
In legal reliance terms, one may trust the confirmation procedures of
the CA during certificate reliance, but one cannot rely upon them for
other than their value as a representation of the CA's authentication
management act expressed in the CA's own terms and rules --
therefore, a X.509 certificate is neither necessarily meaningful nor
valid in a user's reference frame or for the user's purposes. [Cf.
http://www.mcg.org.br/certover.pdf or cert.htm]


>>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 ? ;-)
>
>Security has many faces.  That you really are communicating with
>the right person is one example :-)

Which is not warranted by X.509/PKIX, neither by commercial CAs' CPS,
nor by commercial CAs' quarantees, nor by law (eg, the US UCC).

Unfortunately, it is also a common misconception (number three) to
think otherwise.


Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                     egerck@novaware.cps.softex.br
http://novaware.cps.softex.br