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

Re: Mary is Mary

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

At 05:27 PM 6/20/97 -0300, E. Gerck wrote:
>Your answer of course correct but misses the issue. What I meant is
>exactly the phrase I wrote: 
>
>"has no way of knowing that Mary *is* Mary"
>
>and not that "Mary is called Mary". This is not a play on words and that's
>why I chose the name Mary -- it's certainly not singular, not a DN.
>
>The question is not the name. If you want legal responsibilities or, at
>least, accountability, then you must have a way to bind the authorization
>to an accountable entity and not to a key. A key cannot yet be persecuted
>and go to jail.

I think we are in violent agreement.  A key can not be sent to jail.  Neither 
can a name.  Neither can a name and address (if the person moves and/or changes 
names).  What is needed is what I call a "subpoena certificate".  It maps from 
cyberspace to 3D space (not from 3D space to cyberspace, the way X.509 and 
original SDSI do) and the signer (presumably a company which is a process 
server by profession) promises to track down the keyholder indicted and serve 
legal papers on him/her.  The subpoena certificate needs only an index number 
inside, assigned by the process server company (so they can access their files) 
and that company would prefer such an anonymous subpoena certificate (so that 
competing process serving companies can't ride on their certificate).

The subpoena certificate is part of SPKI, not of SDSI or X.509 -- but since 
SDSI and SPKI have merged, it is part of SDSI/SPKI 2.0.

>So, what I was saying is that the verifier has no way of knowing that Mary
>*is* Mary even he trusts Jon 100%. This question is not solved in SPKI --
>and I must say I don't think that invalidates SPKI. It just explains
>exactly what the limits are. The limits are the realm of keys. You cannot
>reach back to the realm of persons -- SPKI certifies keys, not persons.

We do in fact reach back to the realm of persons.  There is a kind of subject:

(subject (keyholder K1)) 

where K1 is really a public key
and the (keyholder K1) stands for the human being who holds the corresponding
private key.

If you are saying something about that person (e.g., name and address) then you 
use the (keyholder ...) construct.  There will be more detail about this in the 
new draft.  So far, it's been in the latest presentations (PowerPoint slides).

>Besides, there was a previous point, in the same e-mail -- also repeated
>in a "summary" e-mail I sent. The question is that SPKI should make it
>mandatory (and not optional as it is today) for Jon to ask Mary to co-sign
>the certificate in which he delegates X to her. The reasons are several
>and were explained in another e-mail I sent on the same line of reasoning. 

This is something I tend to agree with.  However, Ron Rivest and a few others 
disagree.
My argument is that for every right transferred from issuer to subject, there 
is an implied responsibility passing from subject to issuer.  Ron's answer was 
that the former is needed for access control while the latter is the domain 
only of lawyers.

It can be argued that the whole reason for certificates is to satisfy 
lawyers...well, one class of certs at least, so I'm not so sure about Ron's 
line of reasoning.

>So, to sum up:
>
>1. Pls include a MUST co-sign clause.

I would like to hear list discussion on this one point.


>2. Pls remember that a SPKI cert can be 100% wrong regarding the actual
>keyholder. A SPKI cert only affirms that the whoever holds the key K has
>been assigned X by A (including 1 above, K must also co-sign -- showing
>posession of the private-key K' and showing that whoever holds K/K' agrees
>that the assignment is valid as done in that date).

This is semantics.  As long as I define "(keyholder K)" as "whoever holds the 
private key corresponding to K", any reference to (keyholder K) identifies
the correct person by definition.  That doesn't mean you can find the person
to submit legal papers, of course.  That's the added-value of the
process server company -- not just locating the person at the time the cert
is signed, but making sure that person can be found later when the contract
is violated and legal action must commence.  This takes work on the PS's part
and for that work, the PS should collect a fee.

 - Carl

-----BEGIN PGP SIGNATURE-----
Version: 5.0
Charset: noconv

iQCVAwUBM6t/2VQXJENzYr45AQEknQP/WInNG999rpoErT4jkxqVFlgm5jz0MRDj
bDXWhBPSvsVXI5JpWpuAb2QoQvGFONN98l2R2LbqoXZJI5BVW4T+wh6p8roODb7R
BM0ejwvyLfE4lIaugvj3aDgUDMoFMmwzgYiZHPP4/4Tfbre9DSoW6Qu77Tt2oaxk
/IdWq9j0Ztk=
=kFD3
-----END PGP SIGNATURE-----


+------------------------------------------------------------------+
|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: References: