[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANNOUNCEMENT: SPKI mailing list and BOF at Los Angeles
At 10:33 2/23/96, peter (p.w.) whittaker wrote:
>Definining two entirely analogous PKIs seems comparable to defining two
>entirely analogous mail transfer protocols, with the only difference in
>the protocols being the format of the headers. Where would we be if SMTP
>had had "competition" from the start? Would the IETF even have approved
>such an effort?
If the only effort were to create something identical in function to X.509
but with slightly different format, I'd see only one justification.
There is reason [among those of us who have had to use is] to avoid ASN.1
at all costs -- but that's a minor issue, to me.
The major issue is that X.509 certificates are designed to be identity-
based. I see a reluctance in the user community about identity-based
certificates and a real need for attribute-based certificates.
We could do that with a modification of X.509 format, but the first step would
be the elimination of the DN from the certificate -- making instead an
arbitrary data packet describing the attribute being associated with the
signed key. That attribute might be the name of a person, but it could
be seomething far more interesting and important -- like permission to
spend money from a given bank account -- a permission which does not need
to ddivulge any personal information about the user.
I have written much on this subject. Rather than forward the log of
past writings, let me try to write this up succinctly and forward that
to the list.
From ???@??? Fri Feb 23 12:47:42 1996
Received: from callandor.cybercash.com (callandor1.cybercash.com) by cybercash.com.cybercash.com (4.1/SMI-4.1)
id AA10103; Fri, 23 Feb 96 08:17:21 EST
Received: by callandor.cybercash.com; id IAA02037; Fri, 23 Feb 1996 08:26:51 -0500
Received: from infinity.c2.org(184.108.40.206) by callandor.cybercash.com via smap (g3.0.3)
id xma002014; Fri, 23 Feb 96 08:26:21 -0500
Received: (from daemon@localhost) by infinity.c2.org (8.7.4/8.6.9)
id FAA02380 for spki-outgoing; Fri, 23 Feb 1996 05:12:18 -0800 (PST)
Community ConneXion: Privacy & Community: <URL:http://www.c2.org>
From: "Kenneth E. Rowe" <firstname.lastname@example.org>
Date: Fri, 23 Feb 1996 07:17:51 -0600
Reply-To: "Kenneth E. Rowe" <email@example.com>
X-Mailer: Z-Mail (3.2.0 06sep94)
Subject: SPKI Charter
Content-Type: text/plain; charset=us-ascii
** Cross posted this since group was just announced, I will just use spki for
its separate topics starting Monday **
Thank you for starting this new group.
I agree that the work the pkix group is doing is VERY important.
Unfortunately, I am facing the exact problem that SPKI's charter is focusing
While X.509 certificates are important, we have to deal with PGP keyrings and
DNS Security Extension keys are coming soon.
As we look at these issues for the WWW community, we are also very concerned
about getting interoperability amongst the Web browser/server community and
having an International standard to help deal with the export issues.
We need well defined, easily implemented standards for providing key management
As I've been thinking about this, it seems that we need to define Quality of
Service parameters for an SPKI interface.
What I'm thinking about is akin to buying network services from a carrier ... I
can get a much cheaper rate for bandwidth if my guaranteed service is Zero
I envision a program calling an SPKI service (e.g. Validate_Certificate) which
has a minimal service guarantee (e.g. Within 5 minutes). That way I could pay
a minimal amount for key management services and pay additional on a per-call
basis for QoS requests above my normal level.
Another QoS, that I don't know how to state, could be a request to validate
that a public key is from someone that has a legitimate application. Example
would be that I only wanted to accept a PGP key from someone that is using a
legally obtained PGP capability -- they aren't using an illegally exported
implementation that was posted on the internet.
This seems consistent with the proposed purpose of spki. Am I reading it
Kenneth E. Rowe firstname.lastname@example.org
Senior Security Engineer / (217) 244 5270 (office)
Security Coordinator (217) 244 0710 (IRST)
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
*** email email@example.com for computer incident response ***