RE: [Emu] Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Emu] Re: Last call comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings
Yup, specifically 3280 says that a issuer, as represented by its DN will
guarantee unique serial numbers within its scope and issue within its
scope non-ambiguous subject DNs (e.g. no dupes).
-----Original Message-----
From: Sam Hartman [mailto:hartmans-ietf at mit.edu]
Sent: Friday, April 06, 2007 1:14 PM
To: Nicolas Williams
Cc: Bernard Aboba; ietf at ietf.org; emu at ietf.org
Subject: [Emu] Re: Last call
comments:draft-williams-on-channel-binding-01.txt: EAP channel bindings
>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
Nicolas> Also, I think my draft's definition of "end-point channel
Nicolas> bidning" needs to be tightened just a bit: not only must
Nicolas> the end-point IDs be cryptographically bound into the
Nicolas> channel, it must also be the case that the IDs
Nicolas> meaningfully identify the channel end-points -- that is,
Nicolas> that one nodes cannot assert the same ID as another
Nicolas> without sharing credentials with it. I think my text
Nicolas> implies this but does not make it sufficiently explicit.
Be careful. A DN given a trust anchor seems like a find end-point
identifier. However two nodes can share the same DN without sharing
the same credential. Under 3280 rules either the CA issued a
certificate it should not have issued or the two nodes are the same
subject. That's strong enough for the channel binding to be useful
even though the nodes may not share a credential.
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.