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

From: Carlisle Adams <[email-masked]>
Date: Tue, 10 Oct 2000 16:26:47 -0400

Hi Polar,

> ----------
> From: 	Polar Humenn[SMTP:[email-masked]]
> Sent: 	Tuesday, October 10, 2000 3:27 PM
> To: 	Al Arsenault
> Cc: 	Stephen Farrell; Patrik  Faltstrom; [email-masked];
> [email-masked]; Thumrongsak Kosiyatrakul; Shiu-Kai Chin; Susan Older
> Subject: 	Re: Fwd: AttributeCertificates: Path Names to AC Holders,
> Targets  andProxies
> 
(...some text deleted...)

	The start of the solution is mandating the use of ObjectDigest,
where a
	digest can be verified against the Holder's Public Key or Public Key
	Certificate. The question after that is where does one pull the
Holder's
	cert or public key from, should it not be readily available, i.e.
wasn't
	delivered with the AttributeCertificate. This would constitute
having the
	entire DN path to the Holders public key certificate anyway, and
using 
	the ObjectDigest for verification of the identity.

	Could we suggest a critical attribute extension that will contain
the 
	path to the ObjectDigest?
 
Actually, the syntax in X.509 (2000) is that holder is a SEQUENCE of three
optionals (general name, issuer/serial, and object digest).  If the group
decides to do what you're suggesting, no new critical extension would be
necessary; all the profile would have to do is mandate two (or all three) of
the optional fields.

Having said that, however, I'm still not convinced that there is a problem
in the specifications.  The relying party has two chains of certificates:
an AC chain; and a corresponding PKC chain.  BOTH chains have to validate
properly (i.e., fit within specified name and path length constraints, etc.,
etc., AND terminate at a trusted public key).  The trusted public key of the
AC Source-of-Authority (which may or may not be the same as the root CA,
depending upon the model) must have been acquired via a secure out-of-band
mechanism.  Given that both the AC path and the corresponding PKC path are
validated by the relying party, where is the "logic hole" for the attack
you're concerned about?

Carlisle.

---

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

On Tue, 10 Oct 2000, Carlisle Adams wrote:

> > The start of the solution is mandating the use of ObjectDigest, where
> > a digest can be verified against the Holder's Public Key or Public Key
> > Holder's cert or public key from, should it not be readily available,
> > i.e. wasn't delivered with the AttributeCertificate. This would
> > constitute having the entire DN path to the Holders public key
> > certificate anyway, and using the ObjectDigest for verification of the
> > identity.
> 
> > Could we suggest a critical attribute extension that will contain the

Not good enough. You still need a proper full DN path, (i.e. sequence of
DNs) from the root CA of the Holder's certificate. You need it to locate
the Holder's certificate to verify it against the ObjectDigest.

> Having said that, however, I'm still not convinced that there is a
> problem in the specifications.  The relying party has two chains of
> certificates: an AC chain; and a corresponding PKC chain.  BOTH chains
> have to validate properly (i.e., fit within specified name and path
> length constraints, etc., etc., AND terminate at a trusted public
> key).  The trusted public key of the AC Source-of-Authority (which may
> or may not be the same as the root CA, depending upon the model) must
> have been acquired via a secure out-of-band mechanism.  Given that
> both the AC path and the corresponding PKC path are validated by the
> relying party, where is the "logic hole" for the attack you're
> concerned about?

The hole is currently that the AA is allowed to certify that "Henry Ford"
has some privileges without stating the chain of authorities that defined
"Henry Ford"s name (and public key). 

If your system accepts identities from a number of different public key
certificate authorities, Henry Ford can come from two different trusted
CA's. Which Henry Ford really has the privileges? Information has been
thrown away.  In the current scenario, I may have to accept both, because
I wouldn't be able to tell which one the AC was pointing to. If you use
the Issuer Serial form, all you do is just push the problem up one level.

Now, if I had the ObjectDigest I could verify that the privileges belonged
to the Henry Ford to which they were issued. The only thing to do, is be
able to locate the public key certificate in the advent that I don't
already have it. That's why I sort of suggested a DN path critical
extension. Constrained environments wouldn't have to provide it, but
interoperable ones would to make any real sense of it.

As Bob really said, what we really want to do here is issue privileges to
a public key, not just the name of one.

Cheers,
-Polar

> Carlisle.

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