[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
I did not want to upset you - Its just that when one has designed and
built CAs and been involved with large scale security and directory
systems for many years ie. real experience - I thought that would be
useful to the list.
Engineering is about reality you know.
regards and bye.. alan
From: Perry E. Metzger
To: Alan Lloyd
Sent: 7/27/98 9:06:32 AM
Subject: Re: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Alan Lloyd writes:
> Let me explain something to this list which seems to be totally
No, it hasn't been missed.
As I've stated several times now, this argument has occurred before,
and there is no wish to have it again.
For the last time, please stop now.
From ???@??? Wed Aug 12 19:19:04 1998
Received: from mail.acm.org (mail.acm.org [126.96.36.199])
by ice.clark.net (8.8.8/8.8.8) with ESMTP id VAA28511
for <firstname.lastname@example.org>; Sun, 26 Jul 1998 21:01:58 -0400 (EDT)
Received: from blacklodge.c2.net (blacklodge.c2.net [188.8.131.52]) by mail.acm.org (8.8.5/8.7.5) with ESMTP id UAA17608; Sun, 26 Jul 1998 20:52:57 -0400
Received: (from majordom@localhost) by blacklodge.c2.net (8.8.8/8.7.3) id RAA19981 for spki-outgoing; Sun, 26 Jul 1998 17:49:01 -0700 (PDT)
X-Authentication-Warning: blacklodge.c2.net: majordom set sender to email@example.com using -f
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Michael C. Richardson '" <firstname.lastname@example.org>
Cc: "'email@example.com '" <firstname.lastname@example.org>
Subject: RE: FW: comments on <draft-ietf-spki-cert-theory-02.txt>
Date: Mon, 27 Jul 1998 10:47:44 +1000
X-Mailer: Internet Mail Service (5.0.1458.49)
Micheal - thanks for the response - I will MOO a bit more
The text provided is sniped, because being involved with 509 for about
12 years - I have a rough idea how and why they are used...
The text below - is amazing - its security oriented which is good, but
it what is proposed is operationally undeployable and scaleable.
The SPKI team directly addressed the issue of <name,key> bindings and
realized that such certificates are of extremely limited use for
trust management. A keyholder's name is one attribute of the
keyholder, but as can be seen in the list of needs in this document,
a person's name is rarely of security interest. A user of a
certificate needs to know whether a given keyholder has been granted
some specific authorization.
Can you tell me where you put these no-named key identifiers, how do i
find them, how do they relate to real life issues and EC, what are their
privileges and the roles of the people that use them, how are these
entities and the job they do and the authoriasations they have
I work on security systems including allied military infrastructure and
realise and it pontless designing doorlocks and mechanisms that have no
doors, or doors without numbers or names on the front of them that one
can associate the door locks with.
PS how is the CA govenment PKI going - have they got that wrong in your
If you don't accept this point, then SPKI isn't for you, end of
A simple PKI without the KI and user names is not for me or anyone I
know around this planet. Any way it is THEORY document anyway.
PS At least Bovines see the Udder side of life - reality :-)