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

["Julien Stern" <julien.stern@xxxxxxxxxxxxx>]

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