[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on SPKI draft of 25 March 1997
At 01:08 PM 3/29/97 EST, Ron Rivest wrote:
>
>I think it would be helpful to include a section that describes how
>the certificate types of SDSI 1.0 can be handled in the new proposal.
>
>Here is how I think that this can be done. This eliminates the "member-of-
>issuer", "member", and "name" auth fields proposed in the SPKI proposal, and
>replaces this by allowing the issuer to be a simply-qualified name (i.e.
>a key and a single byte-string name).
the Moi: <auth> covers your first examples here. As I interpret what you
have written, you have a certificate with no <auth> field -- therefore with
one implied. I am in favor of making the <auth> field mandatory, so there
is no assumption involved.
>Name-Value certificate:
> Binding a name to a key
> Issuer: <key-or-key-hash> name
> Subject: <key-or-key-hash>
> Binding a name to another name
> Issuer: <key-or-key-hash> name
> Subject: <fully-qualified-name>
>
>Membership certificate:
> Issuer: <key-or-key-hash> group-name
> Subject: <key-or-key-hash> or <fully-qualified-name>
How does this differ from binding a name to a name? Or, stated another way,
what do you mean by binding a name to a name?
>Group definition:
> This is gone, as the SPKI proposal only covers groups defined by
> OR, which is the main case.
>
> But I think it would be good to have MULTIPLE SUBJECTS allowed in
> a certificate, with the understanding that the delegation applies
> to each of them as if there were one certificate for each subject.
How is this different from having a group for a subject?
There is a general issue of multiple Subject and multiple Auth fields. If
we allow them, are we saying that each is to be treated individually? (the
one cert stands for the product set over all subjects and all auths?)
>Auto-Cert:
> Having a way to handle this sort of information seems to be
> missing from the SPKI proposal, and I think it should be added.
I'll have to re-read the SDSI paper. I thought this was taken care of since
the Issuer could be the same as the Subject. Are you speaking only of the
kind of <auth> information defined for such certs?
>Delegation Certs:
> These are the standard SPKI certs.
>
>ACL's:
> These are not explicitly described in the SPKI proposal, and
> should be.
Yup .. I believe an ACL is a certificate body which you don't have to
bother signing because you keep it in tamper-proof storage. Do you
see some problem with that explicit definition?
- 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 |
+------------------------------------------------------------------+
References: