Subject: Re: Path Names to AC Holders, Targets and Proxies

From: Russ Housley <[email-masked]>
Date: Sun, 08 Oct 2000 13:24:22 -0400

Polar:

>I have some questions about total interoperability about the PKIX
>Attribute Certificate when used in environments where your application
>does not have control over both clients and server, i.e. they both don't
>subscribe to the same LDAP server.
>
>I have some problems regarding the use of GeneralName for the Holder,
>Proxies and Targets fields of the AttributeCertificate.
>
>When using DN's for these names, they only specify one level of naming.
>That is, they do not specify the Identity Chain, (i.e. path) upto a
>certain authority. Specifically, they do not name the Holder's CA, and its
>CA, and so on.

This is intentional.  In these cases, we want to bind the attribute to any 
certificate issued to that identity.  If identity collisions are possible 
in your environment, then the attributes should be bound to an 
issuer/serial number pair instead of a General Name.  RFC 2459 requires 
that X.500 distinguished names be present for issuer names.  And, in real 
world implementations, they should include significantly more information 
than a simple common name.

>Even using the Issuer-Serial type of GeneralName is not good enough to
>identify a holder, proxy, or target of the Attribute Certificate because
>it has the same problem in identifying the issuer.

I disagree.  The names that you ave chosen only include common name.  In 
real life, distinguished names, Internet domain names, and RFC 822 names 
all include much more information.

>[much text deleted]
>
>1. CN=Baltimore
>2. CN=General Motors
>3. CN=Manufacturing
>4. CN=Engineering, L=Germany
>5. CN=Human Resources
>6. CN=Henry Ford      Serial#=1234

A more likely distinguished name for the issuer of certificate number 6 is:
         c=US, o=GM, ou=Mfgr, ou= German Engr, cn=HR
A collision with this name is much less likely.

>[much text deleted]
>
>1. CN=Verisign
>2. CN=Holden
>3. CN=Human Resources
>4. CN=Ian Botham, Serial#=1234

Again, a much more likely name for the issuer of certificate 4 is:
         c=AU, o=Holden, ou=HR

Russ

---

From: Polar Humenn <[email-masked]>
Date: Tue, 10 Oct 2000 10:06:53 -0400 (EDT)

On Sun, 8 Oct 2000, Russ Housley wrote:

> certificate issued to that identity.  

I don't think that particular is a good idea. That destroys the entire
notion of binding an identity to a certificate for the purposes of
identifying any thing and blows RFC 2459 out of the water. If that is an
intention, it is a misuse, and there should be steps taken in the standard
to prevent that type of misuse. Yuck!

> If identity collisions are possible in your environment, then the
> attributes should be bound to an issuer/serial number pair instead of
> a General Name.

I'm not talking about "my" environment. I'm looking at the entire world of
interoperability. If I had my environment, what would I even need a
standard for an AttributeCertificate for? 

If I had my environment, I would state that there would be critical
extensions to these Attribute certificates so that the paths to the holder
would be complete. However, what good does that do, in an interoperable
environment where you are handed an attribute certificate from some
service that doesn't complete the name.

I'm looking at the case of where I want to accept third party attribute
services of which I trust, but I which I have no control.  I want them to
adhere to standards.

Let's say I want to use the attribute certificate for a proof of purchase.
The Attribute Certificate says "George" has listening rights to play music
from my site. He is a guy from a poor country that has spent real money
to get this attribute certificate from third party service of which I
trust, but of which I have no control. Another George steals the attribute
certificate and uses it at my site. Because George and George match, i let
him listen to the music. The first George didn't buy rights for "any"
George to listen to his music.

I'm not talking about likelihood. I'm talking about VERIFIABLE Security.

> RFC 2459 requires that X.500 distinguished names be present for issuer
> names.  And, in real world implementations, they should include
> significantly more information than a simple common name.

RFC 2459 doesn't imply any structure similarity between the subject's DN
and the issuer's DN. Therefore nothing of the sort can be assumed. Having
more elements in the DN doesn't mean a thing mathematically. It's just a
blob of data, no matter how big or how small. My use of a simple common
name was only to make the problem understandable. I don't care if you had
128 RDNs in there. It's the same thing.

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Oct 2000 15:38:58 +0100

Polar,

Do you mean that you're willing to trust CAs to pick/certify non-colliding 
values (names, keys,...), but not willing to so-trust *any* AA? 

If that's so, don't use ACs.

> George to listen to his music.

You've made a bad choice trusting that AA. Its operational practices
are bad (actually apalling!). 

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