Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets andProxies

From: "Manger, James H" <[email-masked]>
Date: Wed, 11 Oct 2000 12:32:20 +1100

A relying party verifying an attribute certificate that only includes the
holder's name must match a name from an AA to a name from a CA.
 
Matching names from two sources is dangerous if the two sources can issued
the same name to different entities.  It is safe, however, if this cannot
occur.
 
In the general case trusting an arbitrary combination of CAs and AAs (even
if they all individually do their job correctly) is insecure when verifying
an AC that only contains the holder name - as Polar described.
 
However, this is NOT a good reason to mandate extra fields.  It is possible
to securely verify an AC that only contains the holder name as long as the
relying party's set of trusted CAs and AAs have some commonality in their
naming schemes.  It is sufficient that the same name cannot be issued to
different entities by different CAs and AAs in this trusted collection.
 
Use globally unambiguous names (e.g. DNS) or restrict your set of trusted
CAs and AAs for a given scenario.

It must not be mandated that attribute certificates be bound to public key
certificates - a major benefit of attribute certificates was separating
these two domains of control.
 
> what we really want to do here is issue privileges to a public key, not
just the name of one.
 
Absolutely not!  The whole idea is that the source of authority for a given
privilege knows who (by name) they want to assign it to, but does not care
what public key that person uses.  The cost is that the names used must be
unambiguous in a large context that just the AA.

---

From: "Christopher S. Francis" <[email-masked]>
Date: Wed, 11 Oct 2000 08:51:20 -0400

James,

-----Original Message-----
From: Manger, James H [mailto:[email-masked]]
Sent: Tuesday, October 10, 2000 9:32 PM
To: [email-masked]
Subject: RE: Fwd: AttributeCertificates: Path Names to AC Holders, Targets
andProxies

.. .snip

However, this is NOT a good reason to mandate extra fields.  It is possible
to securely verify an AC that only contains the holder name as long as the
relying party's set of trusted CAs and AAs have some commonality in their
naming schemes.  It is sufficient that the same name cannot be issued to
different entities by different CAs and AAs in this trusted collection.
....end snip
[Chris Francis - WetStone Technologies] It seems reasonable then to assert
that a relying party's list of trusted SOAs should have unique Distinguished
Names.  This is something that the RP has complete control over and it
avoids the whole problem.  I suspect that many implementations already
impose a similar limitation on the list of trusted roots for PKC validation.
Chris

---

From: Polar Humenn <[email-masked]>
Date: Wed, 11 Oct 2000 09:47:04 -0400 (EDT)

> holder's name must match a name from an AA to a name from a CA.

Then you MUST name the CA and its CA and its CA, and so on.

> the same name to different entities.  It is safe, however, if this cannot

However, there is no way for you to control that. The only thing you can
control is that you only accept a set of root CA's (with different keys)
that have different names.

> an AC that only contains the holder name - as Polar described.

True. So, how does one solve this problem? Not by constraining the
environment.

> different entities by different CAs and AAs in this trusted collection.

And therefore you limit or break interoperability on a wide scale.

> CAs and AAs for a given scenario.

I don't have control over names that CA's issue, nor do I have control
over AAs that issue privilege certificates. That's like you being the 51st
state and mandating that the Social Security Agency to conform and use
YOUR person naming scheme for the entire nation and the DMV's of all
states to produce drivers licenses using YOUR person naming scheme so the
person can drive YOUR state.

> these two domains of control.

Okay I can see that, for things such as Kerberos or unix user ids.
However, with DN's you have the special complex identification problem.
With DN's you are meant to be pointing to a public key. Some evidence is
needed to prove that you are not issuing privileges to a forgery or that
you are not accepting privileges meant for somebody else. Having a
complete path from a root CA might do it. However, that always requires a
lookup to make sure that you have the right certificate and corresponding
signatures that it verifies.

Holder: DN,DNCA,...,DNRootCA

Even if the principal which is the Holder delivers the certificate in
whatever protocol he is using to authenticate himself, the Holder's name
still must be looked up via the DN path in the Attribute Certificate and
be verified. An objectDigest might alleviate that. Still if the Holder
didn't deliver his certificate a certificate lookup is still needed.

So there are two cases in the forms of a protocol, say TLS.

1. The authenticated entity delivers its certificate chain.
   The AC must name the holder using a DN path includes the DN path
   constructed from the certificate chain as a prefix.  The DN path
   in the AC must contain the DN all the way up to the RootCA.

   The certificate from the Holder's RootCA named in the AC must be looked
   up and it must be able to verify the authenticated entities chain as
   well. This covers the case where you trust the same RootCA's the AA
   trusts. So no objectDigest is really needed.

   If you and the AA have no agreement on which RootCA's you trust
   there must be an ObjectDigest! And Strangely enough IT MUST BE THE
   ObjectDigest of the RootCA certificate, not the Holder's!

2. The authenticated entity does not deliver is certificate chain.
   Quite possibly its authentication information is gone. The
   authenticated entity's name has been passed on to another server  as
   being previously authenticated, say at the firewall.  However, you 
   only do this in situations where the certificates that were used
   during authentication can be retrieved somehow.
   
   The AC must name the authentication identity and it's objectDigest
   to make sure that the AC is talking about the proper certificate.
   In this case to be absolutely sure, the authenticated entities
   certificate must be looked up, and the objectDigest verified against
   it.

> unambiguous in a large context that just the AA.

Okay. I can see your point. I'm a big fan of Kerberos and other faster
authentication schemes. However, just using naming in the point of AA must
cause a lookup for verification at least to common trust points. It's not
unreasonable.  Although it still bothers me. Peoples pictures and
signatures on are drivers licenses for a reason.

However, the issue still remains of name "collisions" or "coincidences"
of which cannot be verified.

One approach, of which I think James is getting at, is to mandate that all
DN's in the Entire World and Universe be unique. That would mean a
stringent relationship MUST exist between a subjects DN and an Issuers DN
for public key certificates, i.e. DNS. However, I think, since the
inception of RFC2459 and it's predecessors, this was a detail that was not
addressed, or was addressed to be unwarranted.

Therefore one can only conclude that a NAME of a principal in RFC2459 is
the COMPLETE list of DNs from the subject up to the root CA's DN. It cannot
be shorter. Therefore the Holder must be named by a complete list of DN's
up to its RootCA. 

If we use just DN's and no objectDigests, this must mean that there is
at least a common agreement between all AAs and users of ACs that they
trust the same RootCA's, or the naming scheme of RootCA's. That is if a
DN resolves to a RootCA on the AA side, it resolves to the same RootCA on
the user's side.

I think the basic upshot is that the Holder field must name the entire DN
path up to its rootCA. That is indeed the complete name of the defined
X.509 principal.

Cheers,
-Polar

-------------------------------------------------------------------
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