Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt

Michael Richardson <mcr@sandelman.ottawa.on.ca> Thu, 05 August 1999 17:31 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id KAA28561; Thu, 5 Aug 1999 10:31:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA06377 Thu, 5 Aug 1999 10:36:56 -0400 (EDT)
Message-Id: <199908051434.KAA19538@pzero.sandelman.ottawa.on.ca>
To: ipsec@lists.tislabs.com
Subject: Re: PKIX vs draft-ietf-ipsec-pki-req-02.txt
In-reply-to: Your message of "Wed, 04 Aug 1999 09:14:33 +0200." <37A7E859.DF16767D@thawte.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset="US-ASCII"
Date: Thu, 05 Aug 1999 10:34:08 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

>>>>> "Mark" == Mark Shuttleworth <marks@thawte.com> writes:
    Mark> I'm certainly in agreement with you about overloading. But I think
    Mark> that organizations will want to build SIMPLE rules to differentiate
    Mark> between routers, gateways and end-users. They should be able to do
    Mark> this JUST by looking at the cert, and not by referring to a
    Mark> directory or other source (otherwise you add another fragile link
    Mark> in the chain).

  So, sign these three things with different CAs.
  Better yet, attach attribute authority or SPKI certs to the plain
certificate. 

    Mark> For example, in many of the current implementations I've seen you
    Mark> have to explicitly manually trust the certificates of each of the
    Mark> devices you want to talk to. This is a configuration nightmare in
    Mark> larger-scale deployments. Each device needs to be manually told

  That is why you want AA or SPKI certificates.

]      Out and about in Ottawa.    hmmm... beer.                |  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");  [