RE: New Liaison Statement, "Liaison to IETF on the resolution of DR320"

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Julien,

What I recall is that your attack was a CA trusted to issue CA
certificates by the relying party going rogue.  X.509 does not protect
against that.

You also mentioned that you had protection against it, you were
unwilling to share it, and you said that you will share it after you
publish your work.

I have yet to see your proposal.

As a matter of fact on PKIX or X.500 forum within last year again I
asked you to share your proposal and you never replied.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Julien Stern
Sent: Monday, October 22, 2007 10:34 AM
To: ietf-pkix@xxxxxxx
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution
of DR320"


On Mon, Oct 22, 2007 at 06:18:22AM -0700, Santosh Chokhani wrote:
> 
> We have been down this route before.

Oooooh Yes. Lots of fun and (gentle) arguments...

> See my presentation to PKIX in Fall 2004 IETF meeting in Washington
DC.
> 
> My understanding from 2004 presentation was that Russ Housley proposed
instead of ensuring certificate certification path and CRL certification
path matching, we make sure that we ensure that the paths begin at the
same trust anchor.  It was felt by the group (not I) that coupled with
name constraints in cross certified environment is sufficient to
mitigate the risk to an acceptably low level.  Of course, my argument
always has been that using the certificate certification path to
constrain the CRL certification path provides you both with security and
efficiency, something you do not always get.  The primary reason to not
adopt my suggestion is that it requires change to client software.

I did not feel either that trust anchor matching was sufficient enough.

As you may remember, I also felt that your proposed solution, while
improving the situation, did not close every possible attacks, and I
proposed an alternative that was (in my humble opinion) even more secure
but with even more changes on the client software.

Anyway, my current take on the subject would be roughly the following.
RFC3280bis could include something in the line of:

"The uniqueness of DN of all entities in all the Trust Anchors
hierarchies SHOULD be enforced. If the uniqueness cannot be guaranteed
in some circonstances, client software MAY implement additional checks
in order to lower the risk of outputing an incorrect revocation value
during
path validation. [We could give example of additional checks here:
checking the trust anchor matching, check the full path matching,
checking the AuthorityKeyIdentifier hash matching, etc]. Client
implementors should however be aware that these additional checks may
hinder interoperability in the general case."

--
Julien