Subject: Path Names to AC Holders, Targets and Proxies

From: Polar Humenn <[email-masked]>
Date: Fri, 6 Oct 2000 10:28:00 -0400 (EDT)

Greetings IETF,

This is Polar Humenn with the Object Management Group (OMG).

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.

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.

Let me illustrate a security hole that this specification has:

Let's say I am a CA that defines employee identities. I'm pretty low on
the totem pole, because of my organizational structure. My identity
certificate has a path from a real trusted authority, such as:

1. CN=Baltimore
2. CN=General Motors
3. CN=Manufacturing
4. CN=Engineering, L=Germany
5. CN=Human Resources

All my employee identities are defined by 5 and their certificates are
signed by 5's public key. Here's one of my employees and his certificate
serial number:

6. CN=Henry Ford      Serial#=1234

I obviously listed the chain with 1 as the most significant. For example,
if Henry authenticates via TLS, he delivers a chain of these 6
certificates.

And now for something completely different, let's switch to Holden Car
Company, Australia.

The privilege service that Holden subscribes to wants to issue a attribute
certificate to Henry Ford from General Motors so that he can access the
Holden plant through the Internet. It is clearly not enough that I just
define the "Holder" as using the Issuer-Serial form of GeneralName, such
as:

CN=Human Resources
Serial#=1234

I really have to fully define the path of the holder so that we can verify
that the attribute certificate actually applies to the identity I am
presented with.

For a contrived example, let's say the GM has authenticated a client using
SSL, and the plant has Versign's verification certificate (i.e.
CN=Verisign). The authentication provides me with the following cert
chain, which the GM plant has verified:

1. CN=Verisign
2. CN=Holden
3. CN=Human Resources
4. CN=Ian Botham, Serial#=1234

Then he delivers to the plant the Attribute Certificate for Henry Ford.

Does it match? Yes, it sure does. 
Should this happen? Obviously not.

I know it's a bit contrived, but it is a security hole.

Now, if the Holder contained the name path to that serial number, then
there wouldn't even be a question of whether the AC applied to Ian Botham
or not.  (Provided both the privilege service and target both trust the
same named high-level certificates, such as Verisign or Baltimore for
verification).

The same goes for the naming of the targets and proxies.

The problem exists for regular DN naming as their may be two CN=Henry
Fords at both GM and Holden.

What can we do about this problem?

I would suggest either changing the definition of GeneralName to include
DN paths. Alternatively, I may suggest attribute extensions (critical or
non-critical?) that complete the path from the Holder, proxies, or
targets.

I do not have a problem with the Issuer of the Attribute Certificate,
because that will be followed by some verifying PK certificates, which
consequently defines the issuers name path.

Any comments?

Cheers and Thanks,
-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: [email-masked]
Date: Tue, 10 Oct 2000 11:27:18 -0400

Stephen,

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

Actually I think that Polar's point is that the imprecision in
the IETF names specification(s) takes the AA's policies and practices
out of the picture.  The existing specification doesn't allow the
AA to reliably specify an *interoperable*, well-defined and unique
name - even if it wants to!!

It seems (to me, at least) that the ISO already owns the fuzzy,
multi-option specifications space, so IETF specifications should
focus on specializing ISO specs to promote interoperability.

-DMC

--
Dave Chizmadia
Computer Sciences Corp.

Stephen Farrell <[email-masked]> on 10/10/2000 10:38:58 AM

Please respond to [email-masked]

To:   Polar Humenn <[email-masked]>
cc:   Russ Housley <[email-masked]>, [email-masked],
      [email-masked], [email-masked]
Subject:  Re: Path Names to AC Holders, Targets and Proxies

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.

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

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