Subject: Re: X.509 ACs vs. SPKI?

From: "Aram Perez" <[email-masked]>
Date: Thu, 27 May 1999 11:25:45 -0700

Carl Ellison wrote:

[snip]
> 
> In SPKI, we distinguish between the terms "attribute cert" and "authorization
> cert".
>
> When I give talks on this subject, I draw a triangle whose vertices
> are labeled Name, Permission and Key.  (I draw it with name on top and
> key on the right.)
>
> The goal for us application developers is to map a Permission to a Key,
> but we can go from left to right in two different ways.
>
> We can take an authorization cert directly from Permission to Key or
> we can take a pair of certs:  attrubute cert from Permission to Name and
> id cert from Name to Key.

Does either path offer the ability to grant a permission without revealing
the identity of who is being granted the permission? I was talking with some
folks yesterday who want to implement a very large PKI system used to access
control but they have legal requirements in certain cases to keep the
identity of the user private.

Thanks,
Aram Perez

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 May 1999 11:21:23 +0100

Aram,

> identity of the user private.

Can't recall for spki, but the ACs I-D does have support
for encrypted attributes, but this is more a case
of concealing the permissions, rather than the identity
which is presumably visible in a public key cert anyway.

Regards,
Stephen.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 28 May 1999 12:40:13 +0200

Stephen,

I don't want to get into deep discussion here but ...

> for encrypted attributes,

I would not recommend to support encrypted attributes even if the ISO document and
the current draft allow for it. It is an extra level of complexity and we can live
without it for the moment (and maybe for ever).

> but this is more a case

Pseudonyms can be used in a public key certificate and thus the name of the signer
maybe be reasonably cancelled.

Regards,

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 May 1999 12:05:29 +0100

Denis,

> I don't want to get into deep discussion here but ...

On this one, I'm happy to:-)

> without it for the moment (and maybe for ever).

I guess you know that we have a kind of Pre-AC based product
(based on a thing called SESAME:-). One of the most useful
features we've deployed (as opposed to implemented) is support 
for passing application username/password pairs as encrypted 
attributes (this is the service authentication info in the I-D).

There may also be many situations where the fact that I
possess a privilege is sensitive and attribute encryption
is a nice way to handle this rather than having to 
produce and manage many ACs and carefully control access
to the ACs themselves. 

Finally, when proxying an AC, (aka delegation in SESAME terms),
there are cases where I don't want each AC verifier in the
chain to know all of the privileges; again encrypted 
attributes help here.

In terms of complexity, its pretty easy as long as you have
a CMS/PKCS#7 EnvelopedData handler already, we've implemented
it, and I also know of one other implementation supporting
this. It didn't take long in either case.

Regards,
Stephen.