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

From: Carlisle Adams <[email-masked]>
Date: Fri, 13 Oct 2000 12:44:56 -0400

Hi Polar,

I think that as this thread has progressed we've all come to a better
understanding of what you perceive the problem to be.  However, I suspect
you may be missing an important foundational premise which so many of us
take for granted that it may not be stated explicitly in the various
standards documents.

In PKI, a number of security implications rest upon the underlying trust
model.  If I have a particular root CA (i.e., I received it's public-key
out-of-band in a secure fashion, etc. -- all the usual conditions), then
that root CA defines for me a PKI.  That is, it is the starting (or ending)
point in my certificate path validation processing; any path that does not
validly end up at this root is rejected by my software.  Therefore, this
root CA defines for me a universe of PKI entities.  Such entities are
identified in some way, perhaps by DN in the subject field, or by some other
value(s) in subjectAltNames field, or by a combination of the two fields.

Now if, for some reason (my deliberate choice, or as a result of the browser
I downloaded, or whatever) I happen to have a second root CA, then this root
CA defines for me a second PKI, another universe of entities.  Is it
possible that a given entity could have an identity in each of these
universes?  Of course.  But my path validation software will trace a path
down to one root or the other, depending on which certificate it began with.
Is it possible that two different entities could have (accidentally or
maliciously) the same identity in each of these universes?  Again, of
course.  But, again, my path validation software will trace a path down to
one root or the other, depending on which certificate it began with.  The
point is that these two universes of PKI entities are always distinguishable
because they trace to one root or the other.  (Extend this to any number of
roots with corresponding universes and this remains true.)

Now, what about authorization via attribute certificates, which is where
this thread began?  The AC may be bound to a PKI entity only through
identity (DN, or issuer/serial), but this "identity" may appear in several
different PKIs.  Your question is, "how can the AC verifier know which PKI
was intended unless the AC issuer includes in the AC the full path of DNs
(identities) all the way to the root?"  The answer is that this new
extension is not at all necessary because this AC issuer (i.e., this AA)
itself has an identity, and *its* issuer has an identity, all the way up to
the SOA, which also has an identity.  All these identities must belong to
the same universe, from the perspective of the relying party (the verifier),
otherwise the AC is rejected.

X.509 (2000) is fairly clear about the idea that AAs do not create
identities; they rely upon the PKI to do this function and then simply point
to those identities in the ACs they issue (see, for example, Section 13).
Therefore, the AA must not simply have an awareness of the identities it can
point to; it must itself be able to verify these identities in order to
assign privileges to them.  In other words, the AA and the proposed AC
holder MUST BELONG TO THE SAME PKI.  This relationship must necessarily hold
recursively all the way up the chain to the SOA and the first AA in the
path.  Logically, this makes sense as well:  why would it be reasonable for
an AA in one universe to be able to assign privileges to some entity in an
arbitrary, different universe?  No, all entities involved must be part of
the same PKI because the AA is only making use of the identities defined in
the PKI of which it is a part and from which it has its own identity.

The extension you propose would not hurt, but would not help either.  It
would be a fairly sizable piece of extraneous, unnecessary information
carried in each and every attribute certificate.

Carlisle.

P.S., It seems to me that thinking about this one-to-one mapping between
root CAs and PKIs alleviates all the name clashing concerns.  Yes there can
be name (identity) clashes between universes of entities, but this doesn't
matter:  any certificate can be resolved to one and only one universe by
following its path of signatures to the root.  Furthermore, it is easy to
ensure that identity clashes will not be a concern within a single PKI:
this is why name constraints were invented.  A root CA that does its job
correctly will put name constraints in the certificates it issues to its
subordinate CAs, and will put name constraints in the cross-certificates it
issues to other CAs.  Any of these CAs can, of course, ignore these
constraints and (again, accidentally or maliciously) create name clashes,
but such certificates will not validate in proper path validation software
and so are of no consequence.  Any environment for which secure
authentication and authorization is important will use a root CA that
imposes proper name constraints in order to eliminate the possibility of
identity clashes within that PKI.  Clashes with entities in another PKI will
not lead to faulty authentication or authorization decisions because all
certificates being validated for a single purported entity must exist within
the same universe.

P.P.S., Stephen asked that we trim the Cc: list back to PKIX, and I agree
that we should probably do this.  However, I kept all the copied lists and
people on this response because I don't know how many of you currently
subscribe to PKIX and I felt it was important to address the concern being
raised so widely that name clashing was somehow a serious security problem
for attribute certificates and for PKI more generally.  This is not the
case, as I hope I have shown above.

---

From: Polar Humenn <[email-masked]>
Date: Fri, 13 Oct 2000 13:14:11 -0400 (EDT)

Carlisle,

Thank you for your very learned and well formed response.

You do draw an important conclusion that the AA and the Holder must belong
to the same "well-behaved" PKI in order for this scheme to work correctly.
(I wonder how many PKI's are actually really well-behaved? :). 

In any case, I do not see anywhere in the ac509 profile that specifies
that AA must belong to the same PKI (under the same rootCA?) as the
Holder's it authorizes? Can you point me to some text stating this
requirement, or some text that somehow implies this requirement?

I also see this requirement to be a crippling constraint.

The requirement for the AA and the Holder's it certificate to belong to the
same PKI means that I will be able to authorize certain subject entities
from HisCarCompany to have access to resources in MyCarCompany, unless I
do one of the following:

1. Create a new identity at MyCarCompany for subject entity X in 
   HisCarCompany.
     This is undesirable for many reasons. For example,
     if Person X from HisCarCompany gets fired. Also, it to generate
     new keys, new certificates, new names, new password, new
     token card, etc. Now, causes a single-sign-on scenario.
     
2. Create an entirely new PKI for the interested parties and an AA. 
     Out of the question for most. It's Way too much work with new keys,
     new names, new passwords, new tokens cards, etc.

It would be nice if PKI and AA combined could solve the single-sign-on
problem.

Of course, this problem would go away, if there is only one RootCA for all
organzations, and therefore on PKI. For example, HisCarCompany, and
MyCarCompany must get our CA certificates signed by the Verisign RootCA.
And we and everybody that Verisign signs, must be well behaved, and the DN
space is consequently unique.

Is this approach realistic and practical?

Cheers,
-Polar

> case, as I hope I have shown above.

-------------------------------------------------------------------
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: Polar Humenn <[email-masked]>
Date: Fri, 13 Oct 2000 13:22:19 -0400 (EDT)

My apologies,

I missed stating a negative in a paragraph below.  Sorry!

-Polar

> from HisCarCompany to have access to resources in MyCarCompany, unless I
^^^^^^^^^^^^^^^^^^^^^^^^Scratch that  paragraph!^^^^^^^^^^^^^^^^^^^^^^^^^^^

The requirement that the AA and the Holders it certifies must belong to
the same PKI means that I will NOT be able to authorize certain subject
entities from HisCarCompany to have access to resources in MyCarCompany,
unless I do one of the following:

> organizations, and therefore on PKI. For example, HisCarCompany, and

---

From: Ed Barkmeyer <[email-masked]>
Date: Fri, 13 Oct 2000 14:02:46 -0400

Carlisle,

Thanks for taking the trouble to copy your tutorial to us unwashed outliers who
happen to be on peripheral exploders (in my case, OMG ec).

One question:  Is the model you describe documented somewhere in the IETF or PKI
space?

(That is to say:  Before I read your tutorial, I never understood the "implicit
CA scoping rules", and while it may be common knowledge in the PKI standards
development community, it may not be common knowledge to the "new kid on the
block" who may be charged with implementing an AA.  And I can tell you from
experience that there are a lot of idiots like me who think they can read a
standard and understand it, whilst stupidly having failed to read an important
background document that defines the playing rules for the context in which that
standard was intended to be used.  In this case, I am exactly the kind of idiot
savant you needed to educate.  The tutorial was great, but what document should
I have read?  Next week's idiot will not have been on this collection of email
exploders.)

Thanks,
-Ed

P.S. Any OMG person will tell you that I am one of those people who took the
elementary school teacher's advice to heart:  "If you have a question, don't be
afraid to ask, because lots of people probably have the same question!"

-- 
Edward J. Barkmeyer                           Email: [email-masked]
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Mail Stop 8260              Tel: +1 301-975-3528
Gaithersburg, MD 20899-8260                   FAX: +1 301-975-4482

---

From: John Marsh <[email-masked]>
Date: Fri, 13 Oct 2000 16:09:14 -0400

Polar -
A modification to your suggestion of "one" -

I'd suggest world that looks more like the financial services world.  In the
financial services world, there's differentiation in what one has to do to get
varying levels of services and varying levels of universal acceptance.

Other than cash (which looks like no authentication unless the transaction gets very
high value), there's a couple levels of authentication & associated authorizations -

There's near universal acceptance of "certificates" from a very small number of
trusted "standard roots" - VISA, Discover, Mastercard, Diners, American Express.
Merchants handle cards from some subset of these (in the US - VISA & MC always, some
greater differentiation with AMEX & Discover, & Diners is much less accepted, but
exists essentially to be used by corporations to keep their employees from spending
money on anything that's not travel related.  In travel, it's fairly well
accepted.). There is some variation in both services to the card holder and
merchants, but as long as one of the "standard" cards is presented it's sufficient
up to the holder's credit limits.    Note that at this level, there are no
cross-certifications - there are individual "authorizations" but against universally
accepted certificates.

In addition, some merchants also offer their own "certificates" to the general
public - cards -  that are good at their place of business for special privileges
but are not intended for use at any other location (though they are some times
accepted for other purposes at other locations - e.g. Safeway stealing customers
from A&P by giving a discount to A&P card presenters).  Users aren't willing to hold
too many of these, but if it's a service that is highly valued to them, they will
allow them to show up in their wallet.

In the above cases, the level of potential damage on both sides for significant
breach is fairly low given the comparatively low dollar financial transactions
occuring.  At the same time, there's a relatively low level of authentication
evidence presented prior to receiving the card & there is typically a large number
of holders of the "certificate" type.

However, for very high valued services or internal users or representations for
purchase authority at other organizations - say for large purchases, purchases
dependent on acceptance, ... other arrangements end up getting created that may have
higher associated transaction costs, different levels of certification required,
stronger revocation list support, etc. It is also at this level that Carlisle's
cross-certifications really occur.

So the likely long term arrangements look like:

1)  No authentication required.
2)  Some small (always prime (-:) number of nearly univerally accepted root CAs
where no cross-certifications occur but where the acceptance risks are low.
3)  <this level may not exist in the long run> merchant's "own" CAs intended for the
general public.
4)  Specialized roots for much higher level of authentication when the transaction
involved is high risk and where cross-certifications may occur.

John