Pekka Nikander wrote: > [I am not a member in msec or smug, and therefore I don't > know if this point has been taken up there already. It may > even be that my message is rejected from those list due to > my non-membership status.]
I'm not on either of those myself. Hopefully, somebody there will let us know soon enough if we should take this offline... > I find the idea presented in the draft very refreshing and > beautiful. The fact that multicast group IDs are 112 bits > (instead of 64 bits) makes it work even better than for > basic SUCV/CAM. On the other hand, since I am no expert > in multicast and have only a very bad understanding on how > you create new multicast groups in the first place, I cannot > comment that side. Thanks! > Anyway, in Section 5.3 you write: > > > 2. The private key, the public key, the counter and the GroupID > > are distributed to the (authorized) group members. Note that > > private key requires confidentiality because it only has to > > be known to the authorized group members. The public key, > > the counter and the GroupID can be sent in clear but require > > integrity. > > Now, I was left wondering why to send the private key itself? > If we assume that all the hosts in the multicast group have > their own public/private key pair (e.g. for basic SUCV or > in order to authenticate them for some other reason), > wouldn't it be easier just to delegate the right to join > the multicast group? That is, instead of sending the private > key, you would send an SPKI or KeyNote2 certificate stating > that the public key of the host is authorized to join the > multicast group represented by the group key? This is really a very interesting idea. I share your enthusiasm with schemes that can embed the 'acl' in the certificate, as you put it in another recent message (mip wg). The scheme above would work in a world in which all the group members had SUCV type addresses, you're right. This is quite a jump, but I think one of the very interesting problems to look into is what one could do (not just in mcast/anycast) assuming every system had a public/private key pair tied into its ID and/or address. [other benefits agreed to but elided...] > I am not so sure about the anycast case, though. My > understanding about anycast is that in anycast you want > all anycast hosts to behave equally. Therefore they > should look the same, and distributing the private key > might actually be a good idea. I guess one could impose hierarchy and declare one of the anycast members the master of the group. This might simplify certificate handling. But it would be more dynamic to allow all members to be equal. So, to add to the confusion, perhaps in anycast one wants the other members to 'vouch' for each other and to periodically renew this vote. Are there any threshold signature schemes that would allow a minimum number of members to co-sign a cert for a given member? I don't know enough about threshold cryptography, but it seems like all those schemes are pretty rigid (fixed set of signers, fixed number of signers). Hopefully, someone in these aliases can provide some guidance? -gabriel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
