Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by maillists.intel-research.net (8.13.8/8.13.8) with SMTP id n1GEfiNN002966; Mon, 16 Feb 2009 06:41:45 -0800 X-VirusChecked: Checked X-Env-Sender: M.Bhutta@surrey.ac.uk X-Msg-Ref: server-11.tower-82.messagelabs.com!1234794794!66666254!8 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 10902 invoked from network); 16 Feb 2009 14:33:17 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-11.tower-82.messagelabs.com with SMTP; 16 Feb 2009 14:33:17 -0000 Received: from EVS-EC1-NODE4.surrey.ac.uk ([131.227.102.139]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Feb 2009 14:33:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99043.7BBFA4FD" Date: Mon, 16 Feb 2009 14:33:07 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcmQQ3u6VA382mQzRsyXflFz74TNeA== From: To: X-OriginalArrivalTime: 16 Feb 2009 14:33:07.0329 (UTC) FILETIME=[7BEFC710:01C99043] Cc: dtn-interest@maillists.intel-research.net Subject: [dtn-security] (no subject) X-BeenThere: dtn-security@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: DTN Security Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 14:41:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99043.7BBFA4FD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 As DTN support many different naming conventions, but all names should = be unique for communication to occur without errors. So, 1. To what extent it is correct that source will know the destination = endpoint Id ... The other question is:=20 "The problem is that current IBC schemes effectively act only as a kind of "group certificate" where all of the nodes using a given private key generator can use a single "certificate", = but the problem of validity for that "certificate" (which will contain the generator's parameters) is the same problem as verifying a CA certificate in a standard PKI" 1. To what extent we need the certificates, If above naming convention = is true ..=20 I know it is generic, but please comment your thoughts it will help to = dig into problem,=20 thanks, regards, Nasir ------_=_NextPart_001_01C99043.7BBFA4FD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

As DTN support many different naming conventions, but all names should = be unique for communication to occur without errors. So,
1. To what extent it is correct that source will know the destination = endpoint Id ...

The other question is:
   "The problem is that current IBC schemes = effectively
   act only as a kind of "group certificate" where = all of the nodes
   using a given private key generator can use a single = "certificate",
   but the problem of validity for that = "certificate" (which will
   contain the generator's parameters) is the same problem as = verifying
   a CA certificate in a standard PKI"

1. To what extent we need the certificates, If above naming convention = is true ..

I know it is generic, but please comment your thoughts it will help to = dig into problem,

thanks,

regards,
Nasir

------_=_NextPart_001_01C99043.7BBFA4FD--