Subject: RE: Objections to advancing the attribute certificate authenticat ion draft

From: Tim Moses <[email-masked]>
Date: Sun, 15 Oct 2000 21:21:03 -0400

Bob - One of the main reasons for favouring a collection of attribute
certificates over a collection of public-key certificates for asserting
privilege is that one of the main costs associated with public-key
certificates is that related to the management of the corresponding private
key.  The private key has to be secured for confidentiality and it has to be
activated, rolled-over and revoked.  

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Friday, October 13, 2000 6:57 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; <Ed Reed
Subject: Objections to advancing the attribute certificate
authentication draft

>
>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: Michael Zolotarev <[email-masked]>
Date: Mon, 16 Oct 2000 19:26:14 +1000

Anders,

> ACs are though redundant as:
> - ACs have no support in the commercial world

It is easy to claim that something that has just been formally defined has
no support in commercial world. 

> including browsers.  Never will. 

Probably. However we can see how it CAN be used, and some certain advantages
of it. So the time may change current (yet still very much questionable)
attitude.

> - ACs are in the "wrong" format: ASN.1.  XML is what's counts 
> in e-business

Rather, XML is what's *hot* in e-business. I'm not saying 'No' to XML. But I
do not accept it as an argument. The encoding format doesn't affect the
concept. There is a lot of things that can be blamed for being non-XML,
however widely accepted for more than historical reasons.

> - ACs are like PKCs originally thought of replacing paper 
> credentials in an off-line world. In
> an on-line world authority can be delivered directly from the 
> source which make issuing,
> distribution, validity, and revocation essentially "no-issues".

This is a 'pull' model, which is one of defined by the draft.

> 
> Internally there are other solutions such as Kerberos, 
The same argument applies to using PKC in general.

> Externally ACs complicate things
> more than they solve.
I'd like to hear more *meaty* arguments for it :)

Regards
Michael

---

From: Carlisle Adams <[email-masked]>
Date: Mon, 16 Oct 2000 11:06:10 -0400

Hi Bob,

Just a couple of quick responses to specific points below...

> ----------
> From: 	Bob Jueneman[SMTP:[email-masked]]
> Sent: 	Friday, October 13, 2000 6:56 PM
> European systems where the State is issuing high-grade identity
> certificates to their citizens.
> 
> certificates that  have been issued were either created by or vouched for
> by an organizational RA, or were issued by the organization itself. And
> authorization information.  
 
Yes, the identity certificates were issued by the organization, and it is
the organization that is authoritative for the authorization information.
No argument.  BUT, is it the same department within the organization?  Is it
exactly the same people within the organization that administer both
identity and privilege?  Not that I've seen (or heard about).  Whoever it
was in Novell that assigned you an employee ID number is almost certainly
not the same person that decides whether or not you can sign a cheque for
$10,000. to buy some office equipment or some new software for your machine.

Maybe we just work in different circles, but this separation of function
(identity versus authorization) is about the ONLY thing I've ever seen in
actual practice.

> 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.  
 
Yes, often identity is relevant to audit but not to access control.
However, audit is extremely important to many organizations (at least for
some types of transactions), so being able to bind these things together,
especially in a persistent way, can be valuable.

> 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.
 
Sure, a PKC with no DN that includes a security label attribute, or a PKC
with no DN and a corresponding AC that contains a security label attribute.
Either will work and both have their advantages and disadvantages.
Depending on the adv. and disadv. you pick one or the other for some
particular application.

> 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.
 
ACs MAY be tied to a DN, but are preferably tied to the certificate itself
via issuer/serial.

> 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.  
> 
> trust to control what functions, except by the very ponderous mechanisms
> of closed user groups and policy OID constraints. Yuch.
 
If you want to set up your security architecture in such a way that everyone
gets to do something unless there's a certificate saying "don't let me do
this thing", and you rely upon the entity to volunteer this certificate
whenever they feel like doing this thing, then I can't help but feel that
this is a flawed architecture...  :-)

No, if you want to operate in this manner (i.e., with "negative"
privileges), then the relying party must be responsible for acquiring this
information independent of the requesting entity.  There are multiple ways
to do this securely.  This doesn't argue against ACs.

> In summary, I am afraid I have to object to advancing the proposed draft
> at this time.
 
X.509 (2000) is, of course, already a standard.  I don't see what purpose
objecting to advancing a profile of this standard will serve.  If there are
specific technical flaws, that's one thing.  But objecting on the grounds
that you think the business case for ACs is suspect doesn't make sense.
That would be like trying to hold up RFC 2459 because you don't think
public-key certificates will work.  Trying to hold up a profile because you
really object to the base standard seems to be of little value.

Carlisle.