From: Carl Ellison <cme@TIS.COM>
Date: Tue, 3 Oct 95 12:44:41 PDT
To: stewarts@ix.netcom.com
Subject: Re: Certificate proposal
In-Reply-To: <199510031838.LAA27571@ix2.ix.netcom.com>
Message-ID: <9510031923.AA14118@tis.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

>Date: Tue, 03 Oct 1995 11:37:26 -0700
>From: Bill Stewart <stewarts@ix.netcom.com>

>However, it's _very_ tough to spoof a credit-card verification system, 
>because the checkout device uses phones or private networks to reach the 
>authorization company, so the response that comes back saying yes/no/stolen
>can be real dumb.  On the internet, the response needs to be signed,
>though I suppose it could say "Key sssss at xxx@yyy.zzz authorized
>key uuuuu today yyyy/mm/dd/hh:mm:ss, valid for up to $500", and you'd then have
>to validate the key that signed it, etc....  On the other hand, you could
>have the cert require multiple confirmations, e.g. both the bank and the
>user have to authorize this use.

The response does *not* need to be signed.  If you want rock solid
authentication which you can save for later use in court (e.g., buying an
airplane?), you might insist on a digital signature.  However, all you need
is for the path from the person who knows (AmEx's computer) to your cash
register to be trusted.  There are lots of ways to establish trust.

E.g., you could encrypt the path with a session key (triple-DES) chosen by
the cash register and sent at the beginning of the day to AmEx using AmEx's
public key.  Now anything coming back under that symmetric key is
effectively authenticated.

>>>3) Neither PGP nor X.509 (as documented in the RFC1422 and PKCS#6) have any
>>>	   mechanism for additional information other than cramming it into
>>>	   the username, but supposedly X.509 Version 3 includes something?
>>Yup -- and it's ugly.  It counts on a defined OBJECT ID to define the
>
>OBJECT IDs solve two problems - one is that you need some kind of format (yuk),
>but the other is that fields to have mutually agreed on values to be meaningful,
>and central registration is an easy way to implement it, as long as there's
>a simple way to register things.  I hope it at least supports an OBJECTID
>with parameters, e.g. "CreditLimitUSDollarsBankFoo integer"  rather than needing
>excessively many OBJECTIDs "CreditLimit3700USDollarsBankFoo"?  As you say below,
>there's certainly no need to use ASN.1 formats instead of readable ones...

OBJECT IDs are by no means even a sensible way to achieve this end.  SMTP's
tags work very nicely, thank you, and they allow people to define their own
for private-joke extensions to the protocol.  (I did just that for e-mail
access to the TIS DRC.)

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison      cme@tis.com    http://www.clark.net/pub/cme	   |
|Trusted Information Systems, Inc.   http://www.tis.com/                   |
|3060 Washington Road          PGP 2.6.2:  61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD  21738         Tel:(301)854-6889      FAX:(301)854-5363       |
+--------------------------------------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMHGNYlQXJENzYr45AQH8AgQArY71q84bEuPsVRa4Po5ZcHLMoV7yFszX
tZBqokbZ0F9ZFh7USHyynlx/J82yzBRdks680p5j6lXbQ4wbr5xSZQNDEzS+FVNq
+IObzc+c1qv1nSvb6gcJP6wRNfEMk64bSqprG8sYcN2edD5ksDHFECOGCdxnN4Iy
TWT/rpwOYr0=
=UsEv
-----END PGP SIGNATURE-----