[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on SPKI draft of 25 March 1997
At 01:51 PM 3/29/97 EST, Ron Rivest wrote:
>The proposal allows a subject to be the hash of an object. I think
>the goals this mechanism is trying to achieve should be handled some
I understand your POV here.
>I see certificates as working primarily with keys and names, and
>trasferring authority between them. Keys and names are able to
>"speak" (i.e. sign things), and so can receive authority to speak
>certain things (so they'll be listened to). Documents can't speak,
>and so can't receive authority. Certificates are not the right
>vehicle for making other kinds of assertions about general documents.
>We do have a need for making statements about
> -- keyholders of keys (e.g. the SDSI autocert, where the keyholder's
> attributes (phone, email-address, encryption keys, server
> addresses, etc.) can be given
> -- documents
>The W3C digital signature initiative is making fast progress on means for
>doing the second one, and we should probably attempt to coordinate with them.
>(Although what they are doing is not particularly "simple", I fear.) It is
>modelled after the PICS labelling scheme.
It was from my involvement in the W3C DSig initiative that it occurred to me
that the construct W3C was working on (using SPKI certs for trust management
delegation, signed PICS labels for statements about objects and a simple
language for executing trust management reductions (similar to the 5-tuple
reductions I describe in the I-D)), was subject to reduction. In
particular, the first thing we observed was that in specifying the trust
management code, the PICS label was reduced to a 5-tuple as was the SPKI
certificate -- only the subject was a document rather than a key. Given
that, it made sense for me to put the two into the same form. For example,
once you have reduced the tuples into a single one of the form <self, x, ...>
making a statement about some object, x, you have the option of signing that
tuple and giving it back out. If the same form is used for both delegation
to keys and authorization of objects, then you don't have to put that
reduced tuple into one of two different forms before signing it. You have
only one form for it.
As for what W3C DSig is doing, their adherence to PICS label format (with
numeric ratings) [as of the time I got too tied up in CyberCash stuff to be
able to attend meetings], strikes me as not covering all the things we want
to say about documents (e.g., purchase orders, electronic checks, maybe even
programs). I'm not putting down the W3C effort. I applaud it and want to
resume my involvement when my schedule permits. However, I don't think it
covers all that we need.
Extending the subject to hash of object does cover what we need and,
as far as the cert reduction machinery is concerned, is the
natural thing to do. This doesn't rule out use of SPKI certs to communicate
the authority needed by W3C DSig trust management engines as they try to
deal with the signed PICS labels. It just means that we don't need to wait
for them to cover our additional (non ratings label) needs.
Meanwhile, the fact that a document can't speak doesn't mean that an issuer
can't grant it some authority. It only means that the document can't
delegate it. That is, it would be semantically nonsense to have (D true) in
a cert which has a subject pointing to an object.
>A simple scheme would be a new kind of object, such as
> ( assert
> ( predicate )
> ( function-name value-of-function-applied-to-object )
> ( general-relation param1 param2 ... )
>where the last three types might be arbitrarily repeated and intermingled.
I would like to hear more about the (assert ...). As described above, it
feels like it's written for a theoretician. In particular, how does this
structure differ from the general <auth> structure of SPKI certs?
>A slightly more complex scheme (following the PICS model) would add a
>URI indicating where to find out more about the predicates etc (PICS labels)
>I think these kinds of things ARE important, and are NOT THE SAME kind of
>thing that certificates do, and SHOULD be handled by SPKI. In particular,
>some of this sort of information is essential to making it all work well,
>such as finding out encryption keys and/or locations of servers.
I agree that this is important and should be handled by SPKI. I'm not sure
that it's different from what certificates do. That's why I added hash of
object to the Subject definition.
>[Footnote: I feel that the public keys of the principals should be
>used ONLY for signatures, even if the algorithm type (e.g. RSA) may allow
>for encryption as well. The principal (public-key) should give a signed
>statement as to how he wants messages encrypted that are to be sent to him
>privately. There are a number of good reasons for this, which we don't need
>to get into here.]
I don't see why this is worth bringing up. The only use we're making of
PK crypto in this I-D is for signatures. Do you think I need to mention that
in the I-D?
|Carl M. Ellison email@example.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 |