Re: CAs, and to a lesser extent, ports

G'day!

On 7/02/97 -0800, dennis.glatting@plaintalk.bellevue.wa.us wrote:
>
>> > TLS requires a CA, unless one of the proposed shared key
>> > mechanisms are adopted. There is not a global CA
>> > infrastructure, more or less a US infrastructure. Worse, in
>> > the US there is the real possibility of escrow. Associated with
>>
>> Begging your pardon, but Thawte's strategy is entirely
>> global. Also, because we are based outside the US, the only way
>> we would consider escrow is if the US government explicitly
>> banned the use of non-escrow keys within the US - an unlikely
>> proposition.
>>
>
>If Thawte can establish a global presence, comply with
>international and domestic law, assure the authenticity of
>every source (implying possible legal liabilities), assure
>the redundancy, reachability, and integrity of each of their
>CAs (implying liabilities again), and interoperate with
>existing CAs (such as AT&T), then they will offer a great
>service. However, if they cannot then the service is of
>marginal value and no different than the patchwork of CAs
>operating today.
>
>
>> > most CAs is a financial transaction. Though traditional use of
>> > security (in particular, cryptography) has often been
>> > labeled as "not for free", requiring investment in a CA or
>> > purchase of a CERT gives the term new meaning.
>>
>> As soon as it's possible to conduct quality checks free, there
>> will be quality free certs. Certification should not be an
>> expensive thing at all. We don't think so.
>>
>
>I haven't read anything on the subject in a while but in the US
>there was a proposal to have the US Postal Service offer CA
>services and issue CERTs based on the presentation of US
>accepted identification.
>
>I do not recall if the proposal included a fee for CERT issuance.
>I also am suspect on the "US accepted identification" part. If I
>remember correctly the identification was a valid US driver
>license. Ha!
>
>
>The issuance of a CERT must be based on strong verification of
>who it is issued against. Without strong verification the
>authenticity of any CERT is suspect. Verification offers
>interesting challenges not only in the US but around the globe.
>
>

and also

>> Sorry, I missed where we got the assertion that TLS requires a
>> CA.
>>
>> As I understand it TLS requires a ROOT CERTIFICATE and
>> CERTIFICATES. [Assuming the identity-based case, not the
>> anonymous case.] Implementations can do whatever they wish to
>> come up with the root certificate.  I might deal with that by
>> configuring my implementation to use Thawte's root
>> certificate and use them as a CA.  Someone else might set up a CA
>> for use inside a corporation or other organization.  Someome
>> might even set things up to self-sign or deliver a signature
>> engine fairly widely.  One can look at PGP as an example of this.
>>
>> I don't see that there is any technical REQUIREMENT in TLS that I
>> pay anyone to act as my certificate authority.  I myself use it
>> that way sometimes but that's an implementation and
>>deployment detail, not a requirement of the protocol.
>>

>Deployment is what it is all about, isn't it? What good is a
>protocol if it can not be deployed?

>Certainly a company can set up its own root certificate, but
>what happens when their services access outside services?
>Does each an every service accessed by the company going to
>require their certificate or root certificate to be signed by
>the company? Perhaps the company may think so but that is
>unrealistic and unmanageable. What is realistic and
>manageable is a trusted CA. However, considering todays
>patchwork of CAs the problem is the same.

>It will be interesting to see the effect when a CA recertifies
>itself. Perhaps the bank vault where Thwate stores its private
>key is robbed or obtained by legal means and the key compromised
>(in the US the result of a discovery is often public). Probable.
>What then?  At least with a CA infrastructure roots can be cross
>certified (as in the case of PGP) and CRLs published.

           **************************************

I carry a photo-ID for my friendly Video Renter, a driver's licence, and
sometimes, a passport.  Given that I have obtained "trial" CAs over the Net,
I put the "I am who I say I am" value of such somewhat below that of my
Rental-ID.  False licences and passports don't seem to be too hard to come
by, either, for those of criminal intent.  If there really _were_ secure
means of  
verifying an individual's identity, then the KGB/MI5/CIA would have had
fewer concerns about "sleepers", and we would all be the poorer for the
loss of some quite entertaining fiction.  Ditto for Corporate Entities,
which are easier to create, then to "send to the bottom of the Harbour",
than are people.

Where I _do_ see value in such CA's is in a "torn-banknote" protocol:
secure exchanges can take place without either party knowing  --  or caring
 --  about the real identity of the other, just that a third party assures
each that the other is the right one in this instance.

As an intended implementor of systems sitting on top of (perhaps) TLS, my
concerns are simply expressed:  that the content be neither monitored nor
modified  --  no industrial espionage, no third-party fraud.  I see the
security of transactions as the business of security-system (TLS?), and the
decision as to whether or not take part in any such transaction as
belonging to the End-user, and therefore, to some lesser or greater degree
the application-implementor's problem.  

Even for FTP and TELNET.  Does going to an initial port other than 23
_really_ buy anything?  I see the same amount of processing to be done
regardless of whether the call's to 23 or 994. Surely the work's actually
done using the port allocated to the session, and the algorithm for _that_
is the designer's choice.

Buying potatoes, hiring a car, and digital inter-bank transfers all need
both parties to feel secure, but the concerns about "who-are-you?" are
somewhat different!   Obviously the (equivalent of the example) greengrocer
wouldn't check CRLs and search for Revocation Certificates over a
metaphorical sack of spuds.  But can you really see Chase Manhattan blindly
doing business with The Mortgage and Loan Bank of Oodnagalarbie on the
basis of a CRL entry alone, and with no idea of its current financial
status?  No way!  Chase would deal with its Agent in this country for any
exchange of dollars, and direct contact with  the Mortgage and Loan would
be limited to "advice".

I also see some value in "one-time" CAs on semi-permanent links, where an
outstation's CAs can be used once only, and CA #n and all its predecessors
are invalidated by receipt of CA #n+1, a la Verisign.  I can't see how a CA
from "outside" would be of any benefit here.

By all means provide "default" processing, but please don't make it
difficult for us Applications people to look at CAs and judge:  what degree
of faith we should put in them;  what liberties the owner of a particular
CA should be allowed.  I have great trouble believing "Don't worry, my boy,
we'll take care of it  --  one size fits all."

Regards,
Jim LW   



From the BBC's "Barchester Chronicles":

    "I know that ultimately we are not supposed to understand.
    But I also know that we must try."

       -- the Reverend Septimus Harding, 
          tax-consultant, crypt-analyst, clog-dancer, C++ programmer

Received on Saturday, 8 February 1997 20:14:58 UTC