Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

From: "Linn, John" <[email-masked]>
Date: Thu, 19 Oct 2000 13:27:54 -0400

Polar writes, excerpting: 

> Quite frankly, I'd like to understand why attribute certificates are
> needed at all? Why not just put the attributes in the subject's PKC?
> 

X.509 allows attributes to be stored in PKCs, specifically within the
subjectDirectoryAttributes element, as an alternative to representing them
within separate ACs.  Early in the development of the PKIX AC profile, I
suggested that PKIX also reflect this option.  This choice was unpopular in
discussion and therefore not adopted, partly because of concern (also
discussed within the introduction to draft-ietf-pkix-ac509prof-05) that
inclusion of attribute data within PKCs would imply a need for more frequent
revocation and partly because some environments dictate management of
identity vs. attribute data by separate authorities.  These factors are
valid, though may apply in greater or lesser degree in different cases and
under different operational assumptions.  It's possible, I believe, that
representation of attributes in PKCs can be workable and effective in some
contexts, particularly if revocation is accomplished via on-line techniques
rather than via CRLs. 

--jl

---

From: Polar Humenn <[email-masked]>
Date: Thu, 19 Oct 2000 13:57:57 -0400 (EDT)

> contexts, particularly if revocation is accomplished via on-line techniques

I see your point. However, since one may have *many* certificates relating
to a public key, or a even a DN, there is no need to revoke the "previous"
certificates.

In the needs for "other" authorities to issue attributes, they can issue
different certificates with the same public key, and quite possibly the
same DN (but let's not get into that :), and not have to revoke the
original certificate.

And in this day in age, I agree with you that revocation should be
accomplished via on-line techniques and NOT CRLs. They just go back to the
day where your credit card was looked up on a book at the cash register.
Still the cashier called in any over $50. My credit card now gets get
checked on-line all the time, even if I spend 64 cents on a cup of coffee.

Cheers,
-Polar

> --jl

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

---

From: Al Arsenault <[email-masked]>
Date: Thu, 19 Oct 2000 14:40:34 -0400

To further expand on John's comments:

"Linn, John" wrote:
> identity vs. attribute data by separate authorities.  

AWA: It should also be noted that numerous contributors to PKIX
(including myself, in a former life) have a lot of experience (10 years?
longer?) with a very large, very expensive operational PKI that did
exactly this - put all of the attributes - clearances, privileges, etc.
- in the subjectDirectoryAttributes element of an X.509v3 certificate. 
(Actually, that was the second iteration.  The first iteration, which
was built prior to X.509v3 and thus used X.509v1 certificates, put all
those attributes in the subjectPublicKey field.  My, that was fun!)
Experience in that system indicated that a lot of those attributes
changed very frequently - on the order of every few months, if the
reorganizations were spinning out of control again, and on the order of
every couple of years as a matter of business. When the system was
small, this wasn't a major problem - you just revoked the old certs
every time you reorganized and issued new ones.  But then this led to
the situation that revocation checking got ugly - big CRLs or lots of
real-time checking - and the number of certificates in the system at one
time exploded.  There was a massive groundswell of support for moving to
a structure whereby the actual PKC had information that was reasonably
stable, and didn't normally change too often; and to find some other
structure in which to put the "transient" information.  Attribute Certs
seemed to fit the bill.

And, as John points out, there's also the issue of who controls the
attributes.  As a general rule, the people who are responsible for
certifying identities and issuing PKCs - often called the "Pass and
Identification" people - have no jurisdiction over most of the
attributes under consideration. So it was easier to have the Attribute
Authority be the entity that actually controlled the attribute, instead
of some CA doing it on the basis of "well, he said so."

Now, as John correctly points out, this case is in some ways unique, and
the circumstances will not be the same in other situations.  I can
easily conceive of situations in which attribute certificates do not add
substantial value - several of my customers fit into that category right
now.  But the structures were advanced and supported by some set of
people because in actual experience it seemed to be the right answer.

>These factors are

AWA: I agree, although I'm less convinced that OCSP-vice-CRLs is
important.  I think it's more closely related to how often the attribute
changes.

> --jl

			Al Arsenault

---

From: Polar Humenn <[email-masked]>
Date: Thu, 19 Oct 2000 14:52:09 -0400 (EDT)

Hi Al,

The problem is that an Attribute Certificte Authority must be separate
from a Identity Certificate Authority, because it has control over the
attribute information. So, if we have the IDentity CA issues a certificate
of [IDCA,George,kGeorge] where, kGeorge is the public key of george. If
the Attribute Certificate Authority issues a new certificate (effectively
cross certifying George) [ACA,George,kGeorge,Attributes] what's the real
difference to having a separate data structure?

Do you really think the correlation problem of a separate AC at the
Relying Party is that easy?

Cheers,
-Polar

---

From: Al Arsenault <[email-masked]>
Date: Thu, 19 Oct 2000 15:21:40 -0400

> Relying Party is that easy?

In THAT particular system it was, because everything chained back to
what was essentially a single trusted Root CA. (It was called a "Policy
Approving Authority" or PAA, but it was in effect a single
globally-trusted root.) And, name constraints were enforced throughout
the system, providing a guarantee that unless some CA screwed up
somewhere or a trusted human was an active attacker, every DN was indeed
unique. (And such a screw-up or attacker would ultimately be detectable
through other means.)

Now, in other scenarios which don't have such a strictly-enforced
policy, it's a different ballgame.  I've been dealing with it a lot
lately, though, because my company primarily sells two products, one of
which is a CA/PKI product and the other which is essentially an
Attribute Certificate/PMI product. When implemented properly, each
product is secure, and if they're integrated properly, the combination
is secure (for whatever values of "secure").  But if some customer wants
to do something new with them - which happens a lot, because attribute
certificates are so new in practice - we work carefully with them to
make sure that they're not doing anything foolish, or that will inhibit
the desired security level.

The bottom line on all of this is that there are ways to do things
"securely", and ways to do them "insecurely" for whatever definition of
"secure" you prefer.  What we need to do in the standards world is (1)
do the best we can to ensure that "secure" is possible with conformant
products; and (2) make clear where the risks lie.  I give a talk on
occasion whose theme is "standards are no substitute for proper system
engineering."  I really believe that.

		Al Arsenault
		Chief Security Architect
		Diversinet Corp.

---

From: Polar Humenn <[email-masked]>
Date: Thu, 19 Oct 2000 17:39:07 -0400 (EDT)

> unique. (And such a screw-up or attacker would ultimately be detectable

True. However, all parties know (or should I say suspect) extactly what
the common trusted root is.

In the general case of PKI, all I really have is a notion of being able to
authenticate a holder of a particular private key. That's it! I have some
"hint" called a certificate which may give him a name in some space. BTW,
He doesn't even have to give me that hint. But if he does, the certificate
he gives me may not mean anything to me. That is, I might not trust the
certificate's CA. However, it might help me find a certificate I have for
him that I do trust, (under the same DN, or a different one?). I guess
this is called path discovery?

Some SSL implementations don't really work like that. The client delivers a
chain to a root, and its compared against a "trusted" root certificate
registered in the servers space. That's not really a
"cross-certification", but is the practical side of things. 

To cross certify, I should really have my bonafide root CA create a
certificate by extracting the public key from the "trusted" root
certificates and giving the new certificate a name. Correct?

This approach I believe is the approach that Carlisle suggests. 

On the cross certify, especially with a ubiquitous directory, I would like
to use the CA name in the "trusted' certificate given to me. That would
make it easy to locate. However, that may violate name constraints of my
own CA because I may not be allowed to issue certificates in that space.
Isn't that right? I would have to use a different name.

I guess that's why I'm skeptical that names actually work at all between
at least three parties. Of course, as you have concluded and determined
still takes a lot of work, you need to initally have all parties *believe*
they are under the same trusted root. (and actually implemented it as
such).

> I give a talk on occasion whose theme is "standards are no substitute
> for proper system engineering."  I really believe that.

I agree. However, when you want to be "interoperable" it would be nice if
the standards could constrain, if not eliminate, the risks where possible.

Cheers,
-Polar

---

From: Dale Gustafson <[email-masked]>
Date: Fri, 20 Oct 2000 11:01:11 -0500

Al, Polar,

Let me also try to summarize.

I think we've arrived at the current state because the group genuinely perceives
the need for Attribute Certificates.  I think there is a common sense that there
is or will soon be a compelling need for secure applications to distribute and
utilize tamper-resistant, application specific data elements within the global
PKI.  It is envisioned that authoritative entities will deploy Attribute
Authority systems that manage the life cycle of these special certificates.  We
further speculate that each authoritative entity will work with it's various
constituents to define the form, fit, and function of a specific attribute
certificate that will be utilized by a well-defined set of applications.  This
application specific certificate's format and content will be updated from time
to time as the applications evolve, etc. under some management process
controlled by the authoritative entity.

Past experience has strongly suggested what NOT to do but has not necessarily
indicated the most appropriate course of action.

Logically, and assuming the need is real, there are at least three possible
approaches:

1. Embed the Attribute Certificate information in x.509 v3 Identification
Certificates

Each industry or market group (banking, finance, insurance, communications,
government, et. al.) can create a set non-critical extensions that allow their
application-specific information to be carried in a common public key
certificate or certificates.

In the near term (at least) this is the most effective approach because each
design can take a free ride on all of the PKI infrastructure that is being put
in place at great expense.  The downside is that the combined certificate
retains all of the properties of a public key certificate irrespective of
whether that makes sense for the attribute information and the secure
application(s) that will utilize it.

2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate

This has been suggested in the past but was not well received, likely because it
was obvious that significant additional overhead would be added to each
attribute certificate but it could not be shown that such a close coupling of
the attribute certificate and public key certificate would have technical merit
that justifies the cost.  Problems of keeping the ID certificate and attribute
together are eliminated but there are still two certificate chains.  The
infrastructure for and deployment of ID certificates can be utilized "as is".

3. Provide a Link from the Attribute Certificate to the Public Key Certificate

This approach appeared at the outset to be the most elegant and, most
importantly, appeared to be the most flexible.  It has just now become more
apparent that creating a reliable, "dynamic" link between the two certificates
is difficult.  This has been discussed at length recently.

Perhaps others can recall other approaches that have been suggested.

My sense is that the real value of a separate attribute certificate is that it
invites others with specific application expertise to join the process "earlier"
without making everyone's work overly complex -- if (and only if) that's true,
will people be willing to pay some reasonable price to accomplish the necessary
up-front planning.

What appears to be missing is a framework that enables secure application
builders to understand when they can "have at it" knowing they have a reasonably
stable environment around them.  That is, allows and encourages their innovative
work to move forward in  parallel with that of other industry and market
groups.  In order for that to happen, there needs to be a common understanding
that the basic problem is bounded and within range.

A framework for attribute certificates might better define many of the things we
have recently discussed:

 - encode / decode methods supported (ASN.1, XML, other)
 - commonly used data elements
 - encryption methods (selected attributes, full certificate)
 - delivery methods (SSL, S/MIME, directories, other)
 - certificate path creation / signature validation
 - certificate status checking
 - summary:  distinction between ID certificates and attribute certificates
 - other ?

Perhaps this has already been done elsewhere.  I suspect even an all-knowing
expert would have to look long and hard at the overall requirements for
attribute certificates before deciding that a single approach would suffice.

Comments?

Best Regards,

Dale Gustafson

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Oct 2000 13:08:03 -0400

Polar,

Al pointed out in his experience, and the rule is true in a more 
general context, the folks responsible for managing access control 
are not the same as those responsible for managing identity (and 
maybe keys). This is a good motivation for use of ACs. Use of ACs 
allows each authority to manage authorization separate from one 
another, and from the identity issuer. Changes to your authorization 
in one context can be made without having to coordinate with other 
AAs, or with a CA.

Steve