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

Re: Thoughts on the draft

At 03:42 PM 8/27/96 EDT, Angelos D. Keromytis wrote:
>The only reason for multiple signatures i can think of (other than a
>policy that requires them) is simplicity; when someone asks for your
>email certificate, you don't just go through a (potentially large)
>database, but just hand them your certificate about email
>(s/email/whatever) and he'll figure out if it's ok. You can do the
>same by sending all your email certificates, but it's not as elegant IMO.

Are you thinking of "certificate" as "bundle of information, some of which
includes the specific authorization requested"?

>Well, my idea of an SPKI implementation is a library of functions
>which offers some basic services and you then let the program(mer) do
>the rest; so, an example program in pseudo-C could be:

[...]

Your approach is interesting.  Can you send more, to help me understand it?

>I won't argue about using the binary format to create the signatures.
>However, it's not clear in the draft how two applications which
>use these two lines in their certs respectively
>
>AUTH: "NEXTVACATIONS", 69, a, b, c
>AUTH: "POTENTIALCUSTOMER", 69, a, b, c
>
>will be able to distinguish between certs they or the other application
>created.

First of all, the parameter count wouldn't be 69 without having 69 different
parameters.

The approach we've taken with SPKI is that the verifier defines what <auth>
it needs, what parameters it has, what those mean, ....

The possibility that two different verifiers will use the same <auth> tag
(maybe with different parameter counts, maybe the same) with different
meanings is resolved by having a given verifier accept certs from only a
limited number of issuers.

This *does* leave the developer world open to the problem that those two
different verifiers might co-exist for a while so that each has a user base
and then some certificate issuer decides to support both -- but can't.  Auth
tags can be made unique without going to OIDs or anything as cumbersome.
They can include the domain name of the verifier -- or a large random number
expressed as text.  Alternatively, we can create a web page for allocation
of new <auth> tag names -- giving those already allocated, the name of the
verifier and the meaning (and format) that verifier is using.

>But why not take this (or a similar) approach, so that even
>applications that create vastly different certificates can partly
>understand a "foreign" certificate;

This doesn't make sense to me, from a security POV.  If I'm checking for
<auth> A and I haven't given the issuer of the foreign certificate any
permission to delegate A, then that certificate doesn't mean anything to me.

I'm especially concerned that we not try to use certificates the way grocery
stores used to use driver's licenses -- as an ID for cashing checks.  The
DMV has no idea if I own a bank account, much less whether it has a positive
average balance.  The only advantage of writing a DL number on my check is
to note that some large organization (the DMV) has bound my picture (which
the clerk checks against me) to a name and address which is also on the
check.  This is an input which PolicyMaker might accept -- for some
(relatively loose) security policy -- but it's not the tight security which
we're aiming for in SPKI.  [That said, PolicyMaker can generate SPKI certs
to fit into a tight chain, so that the user isn't forced to use the tight
security model.]

>BEGIN
>ISSUER: You friendly police department
>NAME: Foo
>SUBJECT: 1, abcdef
>ADDRESS: there
>SIGNATURE: somevalue
>END
>
>BEGIN
>ISSUER: SomeBank
>REQUIRED: 1, abcdef
>ACCOUNT: 123
>SIGNATURE: someothervalue
>END

The syntax is off, here.  The SIGNATURE needs to be outside the BEGIN/END
cert body -- so that a given cert can have multiple signatures.

The more I read this, the more it looks like PolicyMaker (or Brian's
equivalent).

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |
+------------------------------------------------------------------+
Follow-Ups: