Subject: Attribute certificates and extranets

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 26 Oct 2000 15:35:24 -0600

Dale,

Thanks for your courteous and thoughtful reply.  

I understand that people are getting tired of this issue and want to vote it up or down, but when someone is suggesting that a draft standard that a number of people have worked on is either premature or a less than optimal solution to some problem, as I and a few others have suggested, "a decent respect for the opinions of mankind" requires some justification for that position, I believe.

I certainly do agree with the need for a "tamper-resistant data object containing application or user group specific data," and I think there is a clear consensus on that point (although even that need is developing rather slowly).  The question on the table is how best way to implement this requirement, and whether the time is ripe.

The real issue, which I think is appropriate at a Final Call stage, is whether the complexity and cost of implementing the Attribute Certificate solution is justified by the benefits, or whether we should go back to the drawing board and look for alternative solutions to whatever problem we think we are solving.  Although I have no doubt that Attribute Certificates as presently defined could be made to work, the overall complexity and the amount of additional code that would be required in both certificate issuing software, and in particular the changes to existing relying party software, is completely out of proportion to the benefits that would be derived, IMO, and particularly when compared to the option of including those same kinds of attributes as an extension within an X.509 v3 certificate.

In a sense, an attribute certificate without a public key is similar to a directory attribute that is bound to a user's object, e.g., by reference or association with the user's directory name.  The attribute certificate at least contains the signature of the authority who issued it, but it isn't organized in directory form.  That is a good news/bad news situation.

The good news, I suppose, is that the user wouldn't have to have a PKI certificate or a private key at all  They could use whatever authentication mechanism the authorization function supports, and have their additional attributes or rights conveyed by the attribute certs.  This would be essentially the equivalent of a user logging on to a directory or some other authorization service, using user name and password or whatever, except for the fact that the user's attributes are not viewable or manageable (from the Relying Party's standpoint) at any kind of a centralized location. 

The bad news is that those "attributes" (rights) may end up being granted to someone based on a very weak identification and authentication function that is not necessarily tied to a public key, and that the only coupling between the user's identification and the rights being granted is a not necessarily distinguished name, i.e., not necessarily globally unambiguous, for all the reason Polar has described.  Worse yet, the organization that is granting those rights does not necessarily know the strength of the authentication mechanism that will be used to make use of them.

If the rights were only being granted to employees and associates within an single Enterprise, as they might be by referring to a locally trusted directory, then this problem wouldn't be too bad, because the local directory can almost surely be trusted to disambiguate names.  The major problem, however, comes when people want to do what is really hard, but presumably very valuable, and that is to control access to users on an extranet basis, i.e., to semi-strangers that are outside of the local Enterprise.  I may not know the individual in question, but I do know the organization he belongs to, and I will trust what they say about him, at least to a reasonable level.

The original model of attribute certificates, as I understand it, was that an authoritative agency would issue identity certificates as though they were the equivalent of passports or at least driver's licenses.  Then other "attribute authorities", whether the Provo Board of Realtors, or the California Medical Association, or Ford Motor Co. would issue attribute certificate that tied back to that well-established identity certificate in order to grant specific rights for use within their community of interest.

Although that is still a possible model, and especially within Europe with their Qualified Certificates initiative; based on the various discussions we have had with our customers, that model really doesn't seem to be going anywhere from a business perspective, especially within the US.

What I envision as happening instead is that commercial enterprises are increasingly going to issue their own certificate to their employees, either using  CA toolkits to create certificates themselves, or by using RA software to request that a certificate be issued by an outsourced CA function such as VeriSign or Digital Signature Trust.

Within those enterprises, the names CAN be unambiguous, either because they are qualified by OUs down to a level where no name collisions occur, or by the use of a unique identifier such as employee number to qualify the name.

Now, here comes the really important question.  How are people outside of that organization or enterprise going to be authorized to gain access to resources within that enterprise, and what mechanisms can be used to assure that the right person, and only that individual, is granted the appropriate rights?

One solution, whether you use a directory type of authorization server or a collection of attribute certificates, is to require Enterprise A to know the name of every individual within Enterprise B that will be likely to require access to Enterprise A's resources, and for Enterprise A to explicitly preauthorize each such user.  This is of course technically feasible, but it is highly unlikely that this will scale well from a management perspective. In most organizations Enterprise A has no way of knowing all of the employees of Enterprise B, much less know which of them are entitled to certain rights, or when those rights should be revoked because someone leaves Enterprise B.  So that approach doesn't work very well, whether the solution is a local directory or attribute certs issued by Enterprise A.

An approach that would seem to be workable would be to have Enterprise B grant certain rights or role to their employees, and then have Enterprise A recognize and honor those roles within their own organization.

From a purely technical access control perspective, this type of role-based access control doesn't even require a name at all, just the role-based privilege.  In the case of a hospital, for example, it wouldn't matter what the doctor's name was, only the fact that he was a doctor.  But realistically, we know that this is almost never the case.  The requirement that events be audited normally means that the individual causing some action to be taken has to be identified by name, or at the very least identifiable by some unique identifier that can be traced back to a specific individual in case something goes wrong.  And in that case, I contend that the Attribute Authority probably knows that individual's name/identity at least as well, and perhaps better than, the PKI certificate issuer.  So there is no really good reason not to include the name. And if we did, and if the attribute cert also contained a public key, we'd be done.  We'd have an X.509 cert with a rights label in i!
t, which is what I would like to see.

In addition to the issue of unique naming, there is the issue of whether a given Attribute Authority is considered acceptable by a given Relying Party, and in particular for what rights.  IMO, it is absolutely unacceptable for this process to be managed by controlling the root certificate of each Attribute Authority.   Not only does that make the already too-difficult issue of out of band trusted root management that much more onerous, but it tends to require a root per individual privilege. Now the number of "trusted" roots will really balloon.

If I am the Relying Party (access control mediator) within Enterprise A, I may choose to allow someone with role or rights X as granted by Enterprise B to access some resource, but NOT allow someone with role X in Enterprise C.  Vice versa, someone with role Y in Enterprise C may be allowed access to that same resource or some other, but not someone with that same role from Enterprise B.

For example, let's take something as simple as order processing.  If Enterprise B is a legitimate customer, I will allow Parts Department personnel within Enterprise B to order parts.  But if Enterprise C is my supplier for those same parts, I will NOT allow their Parts Department to cause orders to be placed though me back to their own company, for obvious reasons.  Likewise, I may allow the Account manager that handles my account within Enterprise C to look at my inventory status and run-rate information, in order to give them a heads up on demand  to facilitate just-in-time shipments. But I would not allow some Accounts Manager in my customer, Enterprise B, to access the same data.  If the data were to show that I had an excess of inventory, he might demand a lower price, and if it showed that I was very low on stock, he might order more out of fear, leading to boom and bust demand cycle.

So if I am allowing Enterprise B and C to issue rights to their employees, whether in the form of an attribute certificate or some other method, then I absolutely must have some highly granular way of controlling precisely which individuals within those enterprises are allowed to have such rights, and which are not.

In particular, since Enterprise A is not issuing the certificates to those individuals, I believe it is absolutely necessary to have a way of DENYING someone a particular right, and even more importantly the ability to deny a particular right to an entire class of users based on their Enterprise or particular Attribute Authority.  Just controlling the roots is NOT sufficient, because one Attribute Authority may be acceptable for some right and not others.

At a minimum, I believe that this requires an entire chain of Attribute Authorities, and the ability to either grant OR DENY particular rights to a given AA and any of their subordinate AAs or end users.

But as currently defined, since the rights being granted are not contained within the certificate that contains the public key, nor are they deposited in a centralized directory the relying party can manage, then all rights must be granted positively -- granting a root AA all rights and then denying those rights to lower level AAs is not an option.  And because Attribute Certs don't contain a public key, I can't create a chain of attribute certs in the normal PKI fashion. Instead, I would have to have both an attribute cert and a normal PKI cert for each Attribute Authority, as well as for the end-entity.

It therefore appears that the Relying Party must somehow apply or grant a set of rights to the EACH root AA, and then each AA must explicitly grant or withhold those rights from subordinate AAs and end-entities.

Unless I have missed something, this requires a total of THREE completely independent sets or chains of certificate: One for the end-entity's PKI certificate, one for each of the AA's public key certificate (since the AA can't be a CA, according to the spec), and a set (nor really a chain) of attribute certs tied back to the public key of each AA to manage the rights that are delegated to those AA's.

Now all three of those sets/chains are going to have to be managed, each certificate is going to have to be checked for validity, expiration, and most importantly revocation, using either CRLs or some kind of online check such as OCSP.

The total signature validation processing time has now increased by a factor of three, as has the bandwidth required to retrieve all of those certificate chains and CRLs/OCSP responses.  And nearly all of this processing is on the server side of the system, where the resources are the scarcest.  

And for the privilege of spending three times as much in the way of resources to do something that could easily be accommodate within a basic PKI certificate, we get to write a lot more software, modify a lot of existing applications, and introduce a LOT more incompatibilities and instability into an industry that is still struggling to implement some meaningful basic PKI capabilities.

Such a deal! :-)

Sorry, but I think the answer has to be NO.  There has to be a better way.  (There is, I believe, but modesty suggests ...)

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software

>Hi Bob,
>
>A couple of comments:
>
>1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute 
>Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form 
>described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted 
>draft document on the table.
>
>2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.
>
>3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that 
>includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here 
>as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right 
>now.
>
>4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the 
>draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to 
>become fully developed.
>
>5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for 
>individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more 
>important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your 
>proposal and "how long it takes" for that to happen.  Good Luck.
>
>Best Regards,
>
>--dg