Subject: Objections to advancing the attribute certificate authentication draft

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 13 Oct 2000 16:56:33 -0600

>
>PKCs bind a public key to an identity.
>
>ACs bind attributes to an identity.
>
>Authentication, which includes validating the PKC certification path and 
>having the remote party perform some operation that involves the private 
>key associated with the identity.  Without authentication of the identity, 
>who cares what attributes are associated with it?
>
>Russ

The more I read and think about the issues Polar has brought up the more I am convinced that the very notion of attribute certificates is potentially flawed, and the business case highly suspect.  They may have had some validity back in the X.509 v1 time frame, before more general extensions were allowed, but I am far from convinced that they are necessary, and may not even be workable.

Let me begin with a few paragraphs from the draft RFC:

   First, authorization information often does not have the
   same lifetime as the binding of the identity and the public key.
   When authorization information is placed in a PKC extension, the
   general result is the shortening of the PKC useful lifetime. Second,
   the PKC issuer is not usually authoritative for the authorization
   information. This results in additional steps for the PKC issuer to
   obtain authorization information from the authoritative source.

   For these reasons, it is often better to separate authorization
   information from the PKC. Yet, authorization information also needs
   to be bound to an identity. An AC provides this binding; it is
   simply a digitally signed (or certified) identity and set of
   attributes.

Although it is certainly true that clearances or rights may not have the same lifetime as an identity per se, in general those clearances or rights are quite likely to last LONGER than any reasonable public key/certificate validity period. An exception might be a short-lived right or capability, similar to that granted by a Kerberos ticket, but in that case the right is generally not tied directly to an identity per se, but is better conveyed by demonstrating that the user possesses a private key that is tied to that right via the public key.  In any case, certificates are cheap -- they're just a bag of bits -- and such rights could more easily be conveyed by a standard X.509 cert that does contain a public key.  

Secondly, I tend to disagree with the assertion that the PKC issuer is not usually authoritative for the authorization information.  This assumes a separation of function of identity confirmation vs. authorization which I simply haven't seen demonstrated in practice, except arguably in some European systems where the State is issuing high-grade identity certificates to their citizens.

Within the US, at least, I would claim that 99.9% all of the identity certificates that  have been issued were either created by or vouched for by an organizational RA, or were issued by the organization itself. And inevitably it is that organization that is authoritative for the authorization information.  The exception to this might be e-mail address certificates (the equivalent of the VeriSign class 1 certificates) which are low due-diligence and arguably not identity certificates at all.  It seems unlikely that such certs would ever be used to authenticate an attribute cert.

Finally, I also disagree with the third assumption, i.e., that authorization needs to be bound to an identity.  It often is, of course, but it need not be, and there are plenty of examples such as extranet access control where identity may be relevant to audit, but not to access control.  Knowing the identity in advance might be a management impossibility -- it is just too hard fro one organization to keep up with everything going on in another organization, even if they wanted to.  All that is necessary is to know whether the entity which controls a given private key has the authority to perform certain functions.

In addition, in some cases it is highly desirable that authorization NOT be tied to identity, or at least that the identity be anonymous. An example might be a teen-aged girl that wants to log in to get the results of her pregnancy test, but without revealing her name.  In that case a standard X.509 certificate could be used that contained a security label attribute and nothing more than a serial number, with no DN.

Because attribute certificates are presently tied to a distinguished NAME that is presumably contained in an identity certificate, but not necessarily to any particular public/private key or certificate, path validation up the chain to two different CAs would seem to be a nightmare, and revocation  even worse.

Finally, even the authors of the attribute certificate draft didn't know how to control a chain of authorization certificates, and in particular how to control delegation of rights, and so they only allow a one-deep attribute certificate chain.  They also don't seem to know how to control the interpretation of the semantics of a particular security label.  So they throw up their hands and invoke a deus ex machina type of solution, saying that the relying parties have to "trust the attribute authority root."  This is no solution at all.

In an offline note to me, Ed Reed recently made another cogent observation.  Whereas incorporating a security/clearance/rights label in an identity certificate binds that label inextricably to the public key (and to the identity, if that matters), the same is not true of an attribute certificate.  

In particular, if the function of the security label is to DENY the delegation of some particular capability or default to an entity, then all that entity has to do is to conveniently "lose" the attribute certificate and he is back in business.  This may not be obvious, but without negative delegation I really have no way to definitive way to control what CAs I trust to control what functions, except by the very ponderous mechanisms of closed user groups and policy OID constraints. Yuch.

The current situation, with dozens or perhaps hundreds of "trusted" roots in the various relying party software is a mess that is about to become a disaster, because enterprises have no convenient way of controlling what roots are really to be trusted, and for what.  I am increasingly convinced that adding attribute certificates to this already fragile structure will cause the entire house of cards to collapse.

We have already seen in the E-sign legislation that a number of opponents (well-intentioned or not so well intentioned) have pushed for an won the right to use "technology-neutral" alternatives to PKI.  If we continue to add more and more complexity with less and less justification, as I believe we are doing over and over again, I predict that we will see a counter-revolution, and "press one to confirm nonrepudiation" will become the norm.

In summary, I am afraid I have to object to advancing the proposed draft at this time.

Regards,

Bob

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

---

From: Ed Gerck <[email-masked]>
Date: Fri, 13 Oct 2000 17:10:59 -0700

IMO, attribute certificates as defined in the draft can be seen as a “patch” type
of solution that may introduce a series of inconsistencies (e.g., revocation
lists for either type of certificate, cross dependencies, etc.) that will only
highlight the broken model of trust being used.

On the other hand, attribute certificates with more attributes will tend to
have a shorter lifetime than attribute certificates with a lesser number of
attributes. The formula I calculated under very general assumptions which
I believe hold for the majority of cases is that the lifetime of the certificate
is inversely proportional to the sum of the inverse of each independent
attribute's lifetime (see PKIX archives, 99).

This means that it is indeed advantageous to divide information in attribute
certificates so that expiration of one short-lived attribute will not invalidate
an entire certificate with otherwise long-lived data. The analogy (due to Tony
Bartoletti at the time) is a box with dynamite sticks where upon the explosion
of one stick the entire box explodes – which sets a limit for the number of dynamite
sticks that one can safely store in one place. Placing too many attributes in one
certificate is generally not a good idea and this may be the only justification I
would find for PKIX to advance the draft, in spite of my first comment above.

Cheers,

Ed Gerck

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Oct 2000 17:52:17 +0100

Bob,

I don't think your objection should be entertained for the following
reasons:

Profiling of ACs is in the PKIX charter. This document has been discussed
on the PKIX list for more than 18 months now. You have not objected to
it before, though you have discussed it before on the list. Your mail
contains no specific technical issues with the document but rather just
some indication of your "feelings" towards it (phrases like: "I tend to 
disagree...",  "It seems unlikely that..." etc.)

The only point where you directly quote the draft is the discussion
on the "lifetime" of attributes in PKCs and ACs. This was discussed
at length on the PKIX list a long time back (not sure if you were
part of that or not?), but in any case it did get WG discussion.
The consensus was against the position you express in your mail.

And lastly:

> Finally, even the authors of the attribute certificate draft didn't know 
> how to control a chain of authorization certificates, and in particular 
> how to control delegation of rights, and so they only allow a one-deep 
> attribute certificate chain.  

I quote this directly since I'd love to know how you know what I know 
and what I don't know. In fact, the main reason for omitting AC chains 
is relative simplicity. I do have some doubts that the X.509(2000) model 
for delegation can be made to work well, but that is quite different 
from not knowing "how to control a chain". 

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com