Hi, The last I would like is to stop, break or delay the actual deployments. If you find split certification useful, it is fine with me to address it with an extension. However, as Marc's said, in order to be possible it would need a change in the actual draft anyway to allow multiple signatures in SecureBlock and StoredData.
cheers On Thu, 2011-07-07 at 16:17 -0700, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/07/2011 03:34 PM, Cullen Jennings wrote: > > > > This would break all the current deployments and implementation and not just > > in a way where some new software would need to be pushed out - all new > > certificates would need to be issues. From my point of view, this is too > > late > > for this change and instead it could be addressed with an extension. > > I agree that it is probably too late, but I am concerned that this > modification > is not really possible in an extension, but instead requires a new version of > the protocol because it needs two signatures in SecureBlock and StoredData. > > > > > On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote: > > > >> Hi, > >> > >> please, let me know whether or not these modifications will be included in > >> the base draft at this point. > >> > >> Thanks, > >> > >> Gonzalo > >> > >> On 21/06/2011 10:58 PM, Marc Petit-Huguenin wrote: > >>> I read the paper and this modification makes sense to me (for example > >>> without this modification a peer that is purely used for routing and > >>> storage purpose, like a bootstrap peer, had to invent a valid, unique, > >>> and useless username just to acquire a certificate). > >>> > >>> So I support its inclusion in draft-ietf-p2psip-base. > >>> > >>> On 06/09/2011 10:47 AM, Diego Suarez wrote: > >>>> I think it would require a (slight) modification in the base document. > >>>> Current P2PSIP certification model is based on a single PKC (including > >>>> both usernames and nodeIDs) that uniquely identifies a user and her > >>>> devices. On the other hand, our model is base on a split > >>>> certification. Devices and users are independent. Each device has its > >>>> own PKC including a nodeID and a PK. Similarly, each user has her own > >>>> PKC including her username and a PK. This approach do not prevent a > >>>> centralized entity (such as an offline CA) to have information related > >>>> to the devices each user (or company, etc.) has registered, but > >>>> permits, among other improvements, a user to be connected to the system > >>>> through devices she has not registered herself such as a phone issued > >>>> by a telco or a fixed phone in a laboratory shared by all the members > >>>> of a research group. > >>> > >>> > >>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: Does this > >>>> model really required modifications in the base document, or can it be > >>>> designed as an extension? (Unfortunately the paper is not freely > >>>> available, so it is difficult to know really what is needed for this). > >>> > >>>> On 06/09/2011 07:31 AM, Diego Suarez wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I had in mind writing a draft about this, but since I'm running > >>>>>>> out of time, I would like to summarize a new certification model > >>>>>>> for P2PSIP I have been working on, in case it is of interest for > >>>>>>> the group. Further details can be found in paper: > >>>>>>> > >>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages > >>>>>>> of identity certificate segregation in P2PSIP systems, > >>>>>>> Communications, IET, vol. 5, pp. 879889, Apr. 2011. > >>>>>>> > >>>>>>> > >>>>>>> The idea is to split the certification of users and devices. > >>>>>>> Devices are identified by PKCs including a nodeID and the PK of > >>>>>>> the device, while users are identified by PKCs including a > >>>>>>> username and the PK of the user. Similar models have been used > >>>>>>> before in other communications systems, such as GSM where devices > >>>>>>> and users are separately represented by the international mobile > >>>>>>> equipment identity (IMEI) stored in the phones and the > >>>>>>> international mobile subscriber identity (IMSI) stored in the > >>>>>>> user subscriber identity module (SIM), respectively. > >>>>>>> > >>>>>>> Motivations of this model are: > >>>>>>> > >>>>>>> - Users and devices are different entities performing different > >>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P > >>>>>>> overlay network (represented by a nodeID) that offer services (to > >>>>>>> route messages, to store data, . . .) to the system, while users > >>>>>>> (represented by an username) utilize these services, usually to > >>>>>>> establish media communications using SIP. > >>>>>>> > >>>>>>> - Support for mobility scenarios where a user may be logged at > >>>>>>> different devices at the same time using the same PKC. > >>>>>>> > >>>>>>> - Support several users to be logged in the same device (like a > >>>>>>> fixed phone) at the same time. > >>>>>>> > >>>>>>> - Support for user independent hard-coded devices. > >>>>>>> > >>>>>>> - Interoperability with SIP. SIP certificates are not valid in > >>>>>>> actual P2PSIP since they don't include a nodeID. > >>>>>>> > >>>>>>> cheers > >>>>>>> > >>>>>>> Diego Suárez > >>>>>>> > >>>>>>> > >>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote: > >>>>>>>> Unless something major comes up, we plan to request the newest > >>>>>>>> version of the base draft, draft-ietf-p2psip-base-15, be > >>>>>>>> published. I'll put in the request in a week (June 16th or > >>>>>>>> 17th). If there are any further comments from the last call a > >>>>>>>> while ago (or further comments on the comments since then), > >>>>>>>> please send them to the list ASAP. > > - -- > Marc Petit-Huguenin > Personal email: [email protected] > Professional email: [email protected] > Blog: http://blog.marc.petit-huguenin.org > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > > iEYEARECAAYFAk4WPn0ACgkQ9RoMZyVa61eLNQCgi614Bs6sdoajQ+ASRC/36JWk > 5y8An1wyr5TbRVqZ6VTCEnfUfz0GIKud > =viZ4 > -----END PGP SIGNATURE----- > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
