[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: keydist@cafax.se
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Date: Fri, 04 Jan 2002 15:21:16 -0500
Delivery-Date: Fri Jan 4 21:23:04 2002
In-reply-to: Your message of "04 Jan 2002 10:48:32 EST." <1010159312.12260.0.camel@error-messages.mit.edu>
Sender: owner-keydist@cafax.se
Subject: Re: From whence we came...

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


>>>>> "Greg" == Greg Hudson <ghudson@MIT.EDU> writes:
    Greg> I see statements like this from some subset of security people all the
    Greg> time, and I can't help but find them hopelessly naive (or at the least,
    Greg> not interested in solving the same problem I am).  This kind of attitude
    Greg> leads to security systems like PGP: very useful for those of us who want
    Greg> to actually devote time to worrying about trust, but with essentially
    Greg> zero chance of developing widespread use.

    Greg> The position is attractive to a certain mindset.  It goes something like
    Greg> this: security is about trust, so we (developers of software and
    Greg> protocols) must go to some effort to find out who the user trusts before
    Greg> we should trust anybody.  Since trust is a personal thing, everybody
    Greg> should have their own preferences.  No single entity should have a
    Greg> distinguished position which they could abuse.

...

    Greg> The solution, then, is not to ask each user, "who do you trust?" but to
    Greg> create one or more high-profile organizations with accountability, who
    Greg> we expect pretty much everyone to trust.  No one should force you to
    Greg> believe them, of course, just like no one forces you to go believe in
    Greg> ICANN's DNS information; but, as with DNS, you probably wouldn't find
    Greg> the Internet very useful if you don't.

  These positions are not contradictory.
  We (as developers of software and protocols) must make it possible for end
users to decide who to trust.

  We (as citizens for the world) must work to create this high profile
trusted organization which people who want to can trust. 

    Greg>   * You can't get a certificate from a well-recognized authority without
    Greg> spending too much money and (as I understand it) putting yourself at
    Greg> significant risk.

    Greg>   * As I understand it, the combination of standards and policies
    Greg> currently in place do not allow an organization to get a single
    Greg> certificate (say, for mit.edu) from a well-recognized authority which in
    Greg> turn can be used to sign certificates for users (e.g. an email

  You used to to be able to get these types of things from some of the CAs,
but I think a combination of politics, financial concerns and software
screwed that up. 
	Politics: who from mit.edu is authorized to do this?
	Finance: oops, there goes a significant chunk of money from MIT 
		 certs we were going to sell, so CA-org has to charge an
		 ammount that now definitely requires some thought from
		 finance.mit.edu about whether this is useful.
	Software: I think that many browser based SSL crap and other
		  commerical libraries had too many bugs in the cert chain
		  walking portions.

    Greg>   * Pursuant to the last point, certificates take too long to expire,
    Greg> because certificates are essentially an off-line system and we assume
    Greg> that certificate renewal is cumbersome.  Revocation would help, but the
    Greg> revocation features I know about in X.509 don't seem very scalable and
    Greg> aren't generally used.  Since DNS is an on-line system, signatures can
    Greg> expire more quickly and domain turnovers can be more quickly reflected
    Greg> in the security system.

  Agreed. I'd rather get rid of CRLs and just resign things more often.
  This works for everyone but .com, and Verisign can solve that problem with
other means for awhile.

  (My only operational problem that I have with DNSSEC right now is that I
don't think that I have software that is smart enough to resign my zone based 
upon propogation delays and caching. I do it manually right now. Resigning
every night in cron seems too much to me)

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPDYOt4qHRg3pndX9AQFn8QQAjnvNGgWzRZVhYqw4gLmHKFR9cpyy1oxi
auNR20ZEUvzWTrJT0rynmY7nHTtEeaUWTPQB+T4Zs03CAnFVNUyDzmLXJqGjh4UQ
CuYomCO6AAWEqYjLSUfThPEjsVqKXmsE/c0AHEa1svvVYkw4RicBGa6edPx03W1j
eCL6Zkw/HAA=
=ztpM
-----END PGP SIGNATURE-----

Home | Date list | Subject list