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

From: Russ Housley <[email-masked]>
Date: Tue, 01 Jun 1999 13:22:22 -0400

Denis:

I disagree.  There are a few real needs for encrypted attributes.  When a
user is granted certain authorizations, even briefly, they may become a
prime target.  I would hate for plaintext authorizations to flag these
particular users.

Encryption of these attributes is not the whole solution, but it is an
important aspect of the solution.  If one AA issues all of these highly
valuable authorizations, then the AA must also issue other less valuable
(and encrypted) authorizations.  Otherwise, any recipient of an AC from
that AA becomes a target.

In summary:  encryption is necessary but not sufficient.

Russ

At 12:40 PM 5/28/99 +0200, Denis Pinkas wrote:
>Stephen,
>
>I don't want to get into deep discussion here but ...
>
>> Aram,
>>
>> > 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.
>>
>> Can't recall for spki, but the ACs I-D does have support
>> 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
>> of concealing the permissions, rather than the identity
>> which is presumably visible in a public key cert anyway.
>
>Pseudonyms can be used in a public key certificate and thus the name of the 
>signer
>maybe be reasonably cancelled.
>
>Regards,
>
>Denis
>
>>
>> Regards,
>> Stephen.
>

---

From: Christopher Stacy <[email-masked]>
Date: Tue, 1 Jun 1999 23:28:37 -0400

>>>>> On Tue, 01 Jun 1999 13:22:22 -0400, Russ Housley ("Russ") writes:
 Russ> There are a few real needs for encrypted attributes.

Certainly in a military security context, there is a need for such secret
authorizations: classification compartment identifiers are themselves classified. 
(I don't know if anyone is actually planning to use certificate attributes in
such a direct mapping, but it would be very natural in a multi-mode environment.)

---

From: Russ Housley <[email-masked]>
Date: Thu, 03 Jun 1999 12:43:24 -0400

I know of at least one Governemnt agency that is looking into this
technology for this exact use.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 14 Jun 1999 14:08:49 +0200

Russ,

I receive more messages than I can read, hence the reason why I reply late to this
one sent two weeks ago.

> prime target.

This is not still an argument that demonstrates the need for encryption.

> I would hate for plaintext authorizations to flag these
> particular users.

I do not understand.

> (and encrypted) authorizations.

You are making a categorization of the value of the attributes on the basis that
high value attributes are encrypted and low value are not. I do not think that this
view is correct. The basic question is the way(s) that are used to prevent the
stealing of the attributes. They can be a clear text, with a good way to protect
them against stealing using only integrity mechanism techniques.

> Otherwise, any recipient of an AC from

On the contrary, I think that the above explanations do not demonstrate that
encryption is necessary..

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Jun 1999 13:22:34 +0100

Denis,

> The basic question is the way(s) that are used to prevent the
> stealing of the attributes. They can be a clear text, with a good way to 
> protect them against stealing using only integrity mechanism techniques.

I guess this is where the difference arises. If I have a clearance
of SECRET then (it can be the case that) I'm not just concerned that 
someone else could steal that attribute, but I'm also concerned that
no-one (except certain people/servers) should find out that I've got
SECRET clearance.

So, prevention of attribute stealing is not the only basic question.

Regards,
Stephen.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 14 Jun 1999 15:17:58 +0200

Stephen,

You took advantage of the time difference to answer before Russ could reply.
:-)

> no-one (except certain people/servers) should find out that I've got

This can be provided using a confidentiality channel, e.g. a VPN or TLS or
whatever. This does not mean that the attribute itself, i.e. inside the AC
must be encrypted.

When an AC contains attributes in clear text then it not targeted for a
specific target when requested from an AA (Attribute Authority). It may be
re-used several times at any targeting place. If attributes are/were
encrypted, it is first needed to define a target for every encrypted attribute
and that AC can only be understandable by the nominated targets. A further
disadvantage is that the AA will know the targets of the client and may infer
from that information what the client is doing. This goes against some privacy
considerations ... but may be very good, from an AA point of view,  for
marketing or other reasons.

Regards,

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Jun 1999 14:45:05 +0100

Denis,
 
> whatever. This does not mean that the attribute itself, i.e. inside the AC

Of course. The I-D never says "must be encrypted", its a mechanism which
is sometimes suitable to use, sometimes not. I'd say that confidentiality
protection of an entire AC is out of scope of this work, but would be
in scope for say TLS or the S/MIME message I-D.
 
> re-used several times at any targeting place. 

Fine.

> If attributes are/were
> and that AC can only be understandable by the nominated targets. 

Not fine:-) The I-D doesn't say that encryption applies to all or nothing.
An AA can decide however it likes which attributes are to be encrypted
for which recipients and bundle the (sets of) EnvelopedData in at least
a few different ways.

Sice the EnvelopedData blobs are sent as the values of an encryptedAttribtues
attribute, any verifier that isn't a recipient can still see all the
remaining cleartext attributes.

This means that so long as your AA (implementation and operation) is 
competent, there's no necessary loss of reusability.

In fact, I'd argue that the use of encryption increases the reusabillity
of an AC. This is because without attribute encryption the AA may
have to partition the attributes of a EE into many ACs. If encryption
is available and usable, then the AA can stuff more into a single
AC without loss of security.

> A further

That's right, and it may be a (slight) disadvantage for some environments.
However, I'd imagine that mechanisms that remove this constraint would
be quite hard to handle, but I'd be interested in any ideas...

Regards,
Stephen.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Jun 1999 13:50:42 -0400

Denis,

I tend to agree with Russ and Stephen on this one.  It seems reasonable to
be able to encrypt some parameters in an AC, for any of the application
examples cited.  If we want to be able to store ACs in directories without
having to rely exclusively on directory access controls for
confidentiality, then encryption of the attributes seems like a good
mechanism. Yes, this may mean that the encrypted fields in the AC will be
accessable by a limited set of entities, who may often be known at the time
of AC creation. (Thye don't have to be know at this time, since it may be
feasible to dynamically distributed the necessary decryption material
later, e.g., incrementally.) I don't see this as a problem; often an AC may
be quite constrained in the set of entities that will accept it anyway, if
one views ACs as capabilities.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 18 Jun 1999 14:37:01 +0200

Steve,

> examples cited.

I have not seen a good argumentation for them, up to now. But the problem is
much deeper, as indicated after.

> If we want to be able to store ACs in directories without
> mechanism.

Hum ! You are implictly supporting there a push model whereas I am a supportive
of a pull model where that functionality is not needed. With a push model you
not have have these kind of problems: no encryption and no access control. :-)

> Yes, this may mean that the encrypted fields in the AC will be

Once again a push model is much simpler ! I do know that anyway some people
will go or have to go for a pull model, ... at their own risk. For the sake of
simplicity, I am advocating a basic document covering the basic needs of a push
model, which does not need the support of encrypted attributes. If some other
people want to go further, then I would have no problem to let them draft
another document. But this is a problem to be discussed both in the corridors
and the next PKIX meeting  at Oslo.   :-)

Denis

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Jun 1999 15:17:53 -0400

Denis:

Some people see a need for posting encrypted information in a Directory.
As long as it is not a mandatory requirement, but an option, what is the
problem.

I want all of the folks that post encrypted information to the Directory to
do so in the same manner.  This way, the ability to decrypt fall to the
ablity to obtain the correct key, not the ability to understand a
particular syntax.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 21 Jun 1999 09:10:32 +0200

Russ,

> As long as it is not a mandatory requirement, but an option, what is the

So let us *not* include it in the base document.

> ablity to obtain the correct key, not the ability to understand a

The requirement you describe can be met using a global encryption of the
information placed in the Directory, not a selective field encryption of some
signed attributes. This topic is thus more relevant to the WG taking care of LDAP
rather than ours.

Regards,

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 Jun 1999 10:16:08 +0100

Denis,

> So let us *not* include it in the base document.

Seems like this is what it boils down to. You don't mind that the
mechanism is defined by the WG, but do object to its being a 
non-mandatory part of the base document. I don't understand this. 

Can you say why?

(BTW: Since you don't mind the mechanism being specified, then I
guess your answer can't be based on technical reasons. Of course,
maybe you see a technical difference between "attribute encryptrion
as an option in rfcNNN" and "rfcMMM, an attribute encryption
extension to rfcNNN"? I don't.)

Regards,
Stephen.

---

From: Russ Housley <[email-masked]>
Date: Mon, 21 Jun 1999 10:37:31 -0400

>So let us *not* include it in the base document.

No.  That is exactly the point.  We want it in the base document as an
option.  This way, if an encrypted attribute is needed, everyone will know
how to do one.

>signed attributes. This topic is thus more relevant to the WG taking care of 
>LDAP rather than ours.

I thought we were discussig how to encrypt some or all of the attributes
placed in an attribute certificate.  What does this have to do with LDAP?

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 21 Jun 1999 17:08:12 +0200

Russ,

As I originally proposed, I suggest that we stop discussing this topic on the
mailing list for the time being and continue with corridor discussions at the Oslo
meeting.

To put in practice this proposal immediatly, I will not argue anymore on this
topic on the list before the Oslo meeting.

Denis