Subject: Re: attribute encryption (was: Re: X.509 ACs vs. SPKI?)

From: Denis Pinkas <[email-masked]>
Date: Tue, 01 Jun 1999 09:33:38 +0200

Stephen,

I still do not want to get into deep discussion. :-)

> Denis,
>
> > I don't want to get into deep discussion here but ...
>
> On this one, I'm happy to:-)
>
> > 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).
>
> 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).

This is not a standard feature of SESAME and not in the SESAME spirit. So please, do not
refer to SESAME for that case.

> 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.

The complexity lies in the fact that to encrypt a field the public key of the target is
needed. This places an additional constraint in terms of key management: this mandates
targets to possess public encryption keys while ACs may work without the target to have
such keys and certificates. This "doubles" the complexity. I would like AC to be
deployable without the need for targets to possess any private key, which is possible as
long as attributes are in clear text.

To be very precise, I would like a basic document NOT supporting encrypted attributes.
If you think it is very important, then make a *separate* document so that I can refer
to one (simple) RFC and so that I comply with it without any need/requirement for
supporting encrypted attributes and the related infrastructure.

Regards,

Denis

> Regards,
> Stephen.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Jun 1999 15:18:16 +0100

Denis,

The I-D specifies two levels of conformance:

   "Basic conformance for an AC issuer means support for
   production of ACs which:
	...
   7.   MUST NOT contain encrypted attributes"

Does that solve your problems? If not, lets talk in Oslo,
I'm sure I can convince even you that attribute encryption
is desirable.

> refer to SESAME for that case.

It wasn't part of SESAME, we had to add it since our customers
needed it! Whether or not its in the "SESAME spirit" is 
IMHO immaterial to the discussion at hand.

Regards,
Stephen.