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

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

Santosh,

I think you are being a bit unfair, as I did explain on the list
as clearly as I could the attack and the protection (early Nov 2004).

Anyway, I do not feel like boring other readers to death by starting
the whole discussion once again.

Maybe we can sit down at a table and chat if we happen to meet at a
conference someday :)

Regards,

--
Julien

On Mon, Oct 22, 2007 at 10:41:10AM -0700, Santosh Chokhani wrote:
> 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
> 
>