Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0PEhpXI033380; Wed, 25 Jan 2006 06:43:51 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0PEhpau033379; Wed, 25 Jan 2006 06:43:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0PEhnjC033359 for ; Wed, 25 Jan 2006 06:43:50 -0800 (PST) (envelope-from susanne.okunick@sit.fraunhofer.de) Received: from [141.12.87.207] (sitp222.sit.fraunhofer.de [141.12.68.222]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.1/8.13.1/9.9.9) with ESMTP id k0PEhgBK010341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jan 2006 15:43:42 +0100 Message-ID: <43D78E7E.20809@sit.fraunhofer.de> Date: Wed, 25 Jan 2006 15:43:10 +0100 From: Susanne Okunick User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: LTANS-ERS: Verification and data groups Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, At the verification of evidence records I get into difficulty. I think, sometimes the verification for data groups is not practicable! For data groups consisting of more than one documents the following points have to be checked (compare example in the draft; page 10,11): a) check whether the hash value of each data object is within the first sequence SEQ(h2b,h2c,h2a) in the reduced hashtree ( h2b,h2c,h2a) b) check whether the document group is complete. That means: All data objects have to be available at the time of verification (d2a,d2b,d2c). If a data group consits of five documents, I will need all five documents for the entire successfull verification. The first sequence of every reduced binary hashtree consists of *at least* two hash values. This is for 1) one data object or 2) a data group consisting of exactly two data objects! My question: How to identify the right case? Assuming the following simple reduced binary hashtree: [[h1a,h1b][h2][h3]] For verification you have to calculate the root of hash (h123): h123=H( binary sorted and concatenated (h12, h3) ) h12=H( binary sorted and concatenated (h1ab, h2) ) | h3 h1ab = H( binary sorted and concatenated (h1a, h1b) ) | h2 h1a | h1b Now there are two possibilities: 1) h1a and h1b don't build a data group => for whole verification you need the data object "d1a" to show that the data object's hash value is "h1a" 2) h1a and h1b are data objects of one data group => for verification both data objects d1a and d1b must be available and you have to show that both hash values are correctly computed Thus you never know (in case of having two hash values in the first sequence of reduced binary hashtree), whether one or two documents needed for verification. Best regards, Susanne P. S. In case of ternary hashtrees there is the same problem: Do you need one or three documents for correct verification? -- __________________________________________________________ Dipl.-Math.(FH) Susanne Okunick Fraunhofer Institute for Secure Information Technology Department Transaction and Document Security Rheinstraße 75, 64295 Darmstadt, Germany phone ++49 / (0)6151 869 60220, fax ++49 / (0)6151 869 322 email: susanne.okunick@sit.fraunhofer.de homepage: http://www.sit.fraunhofer.de __________________________________________________________ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KDsAwS071319; Fri, 20 Jan 2006 05:54:10 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0KDsAW5071318; Fri, 20 Jan 2006 05:54:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mx2.zhwin.ch (mx2.zhwin.ch [160.85.104.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0KDs8xl071308 for ; Fri, 20 Jan 2006 05:54:09 -0800 (PST) (envelope-from frr@zhwin.ch) Received: from orwell.zhwin.ch ([160.85.104.31]) by mx2.zhwin.ch with esmtp (Exim 4.54) id 1EzwiI-0006M8-LE; Fri, 20 Jan 2006 14:54:02 +0100 Received: from dove.zhwin.ch (Not Verified[160.85.196.13]) by orwell.zhwin.ch with NetIQ MailMarshal 6.0 Service Pack 1a (v6,0,3,33) id ; Fri, 20 Jan 2006 14:53:21 +0100 Received: from langouste.zhwin.ch ([160.85.196.12]) by dove.zhwin.ch with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jan 2006 14:53:59 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: AW: LTANS: Examples of ERS data - cross checking of implementations Date: Fri, 20 Jan 2006 14:53:59 +0100 Message-ID: <55FEC03AF31CBE458B6B455F5214CAC7434213@langouste.zhwin.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: Examples of ERS data - cross checking of implementations Thread-Index: AcYdEIFY460Vg+OgTjeAb7CS2k/XmgAm3wNQ From: "Frei Adrian \(frr\)" To: "Thomas Kunz" Cc: X-OriginalArrivalTime: 20 Jan 2006 13:53:59.0357 (UTC) FILETIME=[F68A6ED0:01C61DC8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0KDsAxl071313 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, Thomas Kunz wrote: > >>>- How did the concatenation and hashing of the values in the reduced > >>>hash tree happen? When I concatenate the three values (51B1..., > 5BD0..., > >>>60BB...) in the first list in ascending order an hash them with > >>>ripemd160, I get no value of the second list (B537..., 46D8...) > > > > > Are you (or Susanne) the one who wrote the implementation which > > generated the evidence record or did you try to verify the record with > > your own implementation? My Problem is, that if I concatenate and hash > > the 3 values of the first level of the hash tree I don't get a value of > > the second level. > > > The procedure how to concatenate and hash the values in the reduced > hashtree is decribed in section 3.3 of the I-D. > You concatenate the three values (51B1..., 5BD0..., 60BB...) in the > first list in ascending order an hash them with ripemd160. This hash > becomes member of the second list (B537..., 46D8...). Now you > concatenate these three hash values (the two in the list and the > calculated one) and hash them, etc. Continue this procedure until the > root hash is calculated. This root hash must correspond to the hashed > message in the timestamp. > Oh, stupid me. The "must become member of" and the fact that the digest of the document is included in the hash tree must have confused me a bit... Well, thanks a lot; I was able to verify the first archiveTimeStamp. Unfortunately I can't verify the whole evidence record; it seems that the .NET cms implementation does only support md5 and sha1 as a hashing algorithm. Might it be possible for one of you to provide an additional ER/document-pair? Thanks, Adrian Content Security by MailMarshal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JFrZKO059531; Thu, 19 Jan 2006 07:53:35 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0JFrZTC059530; Thu, 19 Jan 2006 07:53:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JFrXSU059505 for ; Thu, 19 Jan 2006 07:53:34 -0800 (PST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.87.208] (sitp210.sit.fraunhofer.de [141.12.68.210]) by mailext.sit.fraunhofer.de (8.13.1/8.13.1/9.9.9) with ESMTP id k0JFrQYC009976; Thu, 19 Jan 2006 16:53:27 +0100 Message-ID: <43CFB5E3.9080802@sit.fraunhofer.de> Date: Thu, 19 Jan 2006 16:53:07 +0100 From: Thomas Kunz User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Frei CC: ietf-ltans@imc.org Subject: Re: LTANS: Examples of ERS data - cross checking of implementations References: <43CD4F37.5090505@sit.fraunhofer.de> <43CF8935.80209@sit.fraunhofer.de> <1137682721.16097.27.camel@localhost.localdomain> In-Reply-To: <1137682721.16097.27.camel@localhost.localdomain> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090108010303050501090701" X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms090108010303050501090701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Adrian, Adrian Frei wrote: >>>- How did the concatenation and hashing of the values in the reduced >>>hash tree happen? When I concatenate the three values (51B1..., 5BD0..., >>>60BB...) in the first list in ascending order an hash them with >>>ripemd160, I get no value of the second list (B537..., 46D8...) > > Are you (or Susanne) the one who wrote the implementation which > generated the evidence record or did you try to verify the record with > your own implementation? My Problem is, that if I concatenate and hash > the 3 values of the first level of the hash tree I don't get a value of > the second level. > The procedure how to concatenate and hash the values in the reduced hashtree is decribed in section 3.3 of the I-D. You concatenate the three values (51B1..., 5BD0..., 60BB...) in the first list in ascending order an hash them with ripemd160. This hash becomes member of the second list (B537..., 46D8...). Now you concatenate these three hash values (the two in the list and the calculated one) and hash them, etc. Continue this procedure until the root hash is calculated. This root hash must correspond to the hashed message in the timestamp. Regards, Thomas ------------------------------------------------------------ Dipl. Inf. Thomas Kunz Fraunhofer-Institut für Sichere Informationstechnologie SIT Rheinstrasse 75 D-64295 Darmstadt (Germany) Tel: +49-6151-869-60204 ------------------------------------------------------------ e-mail: thomas.kunz@sit.fraunhofer.de http://www.sit.fraunhofer.de ------------------------------------------------------------ --------------ms090108010303050501090701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9 6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47 IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN +6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh 6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1 bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6 DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAxMTkxNTUzMDdaMCMGCSqGSIb3 DQEJBDEWBBRIGTD09WJAJhIk5FCM+aQahZ5TjjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAA21vTHvKtuQ9VM4jd+VRbsb3WO0ADd3VmOtUC9+vp8fl3heh5qWscXt mteBsaRPGfGOwq7Dxr1kEeCTtClS+vA9KGpzczTmfG5yQG9oRViFQ850W9JsA9IKlpEQV2Nj tCtF0bmKGn7yH1TeO8ZR53V+c4xR2hW9vfAkq0U5Gv3Hf9tGvKkFgaFmzKSRADaQ3JfCXkiF 0mpRBbzlPEADILT2mtxXpJHcsCVh3+a7aKwCBYKK5vHQwgKD+9qX6X3dPfWmzZhViPcX99f4 ZcC3lzkcB3bri5ZdtxAIs+kqd3Bw9VDDNDwHJAVYw4ikvZsuBZ9eHsa+zZFubHxsy1gDUwUA AAAAAAA= --------------ms090108010303050501090701-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JEwqSM056953; Thu, 19 Jan 2006 06:58:52 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0JEwqnl056952; Thu, 19 Jan 2006 06:58:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mx2.zhwin.ch (mx2.zhwin.ch [160.85.104.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JEwpAk056945 for ; Thu, 19 Jan 2006 06:58:52 -0800 (PST) (envelope-from frr@zhwin.ch) Received: from orwell.zhwin.ch ([160.85.104.31]) by mx2.zhwin.ch with esmtp (Exim 4.54) id 1EzbFN-0002LY-3H for ietf-ltans@imc.org; Thu, 19 Jan 2006 15:58:45 +0100 Received: from dove.zhwin.ch (Not Verified[160.85.196.13]) by orwell.zhwin.ch with NetIQ MailMarshal 6.0 Service Pack 1a (v6,0,3,33) id ; Thu, 19 Jan 2006 15:58:06 +0100 Received: from langouste.zhwin.ch ([160.85.196.12]) by dove.zhwin.ch with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jan 2006 15:58:44 +0100 Received: from 160.85.182.240 ([160.85.182.240]) by langouste.zhwin.ch ([160.85.196.12]) via Exchange Front-End Server mail.zhwin.ch ([160.85.196.13]) with Microsoft Exchange Server HTTP-DAV ; Thu, 19 Jan 2006 14:58:44 +0000 Received: from DSKT6049 by mail.zhwin.ch; 19 Jan 2006 15:58:41 +0100 Subject: RE: LTANS: Examples of ERS data - cross checking of implementations From: Adrian Frei To: ietf-ltans@imc.org In-Reply-To: <43CF8935.80209@sit.fraunhofer.de> References: <43CD4F37.5090505@sit.fraunhofer.de> <43CF8935.80209@sit.fraunhofer.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 19 Jan 2006 15:58:41 +0100 Message-Id: <1137682721.16097.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-OriginalArrivalTime: 19 Jan 2006 14:58:44.0546 (UTC) FILETIME=[D7E17A20:01C61D08] Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, Thanks for the answers so far. Santosh Chokhani wrote: > >- How did the concatenation and hashing of the values in the reduced > >hash tree happen? When I concatenate the three values (51B1..., 5BD0..., > >60BB...) in the first list in ascending order an hash them with > >ripemd160, I get no value of the second list (B537..., 46D8...) > > > [Santosh Chokhani] I do not understand this issue. Are you (or Susanne) the one who wrote the implementation which generated the evidence record or did you try to verify the record with your own implementation? My Problem is, that if I concatenate and hash the 3 values of the first level of the hash tree I don't get a value of the second level. Susanne Okunick wrote: > >- Why doesn't the second ArchivTimeStamp in the first > >ArchiveTimeStampChain contain a reduced hash tree? According to 4.3.2 in > >the draft "The first hash value list of each ArchiveTimeStamp must > >contain the hash value of the timestamp of the Archive Time-Stamp > >before". > > > I think, generally every ArchiveTimeStamp contains a reducedHashtree. > But if there is only one data object, the data object hash = hashed > message in the timestamp and no reducedHashtree is needed, so > reducedHashtree=NULL. Ok, I thought that too. But then 4.3.2. should be changed. And speaking of the absence of a reducedHashTree; 3.1 (last sentence in reducedHashtree paragraph) is also a bit unclear. > >- As a more general question: How is 4.2.3 in the draft meant? Do I have > >to hash the ArchiveTimeStampSequence or just the concatenated > >ArchiveTimeStampChains? I think there is a difference between the two > >things since the encoded ArchiveTimeStampSequence would include > >additional sequence and length tags. > > > In our implementation we hash the ArchiveTimeStampSequence. (Yes, there > is a difference). Hmm, two answers, two opinions. I also took the complete ArchiveTimeStampSequence, but I think the draft should clarify this issue. Regards, Adrian Content Security by MailMarshal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JCh1ZJ046595; Thu, 19 Jan 2006 04:43:01 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0JCh1dV046594; Thu, 19 Jan 2006 04:43:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0JCgxWe046582 for ; Thu, 19 Jan 2006 04:43:00 -0800 (PST) (envelope-from susanne.okunick@sit.fraunhofer.de) Received: from [141.12.87.207] (sitp220.sit.fraunhofer.de [141.12.68.220]) (authenticated bits=0) by mailext.sit.fraunhofer.de (8.13.1/8.13.1/9.9.9) with ESMTP id k0JCgsZJ012952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jan 2006 13:42:54 +0100 Message-ID: <43CF8935.80209@sit.fraunhofer.de> Date: Thu, 19 Jan 2006 13:42:29 +0100 From: Susanne Okunick User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: RE: LTANS: Examples of ERS data - cross checking of implementations References: <43CD4F37.5090505@sit.fraunhofer.de> In-Reply-To: <43CD4F37.5090505@sit.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, my answer to the questions: >- Why doesn't the second ArchivTimeStamp in the first >ArchiveTimeStampChain contain a reduced hash tree? According to 4.3.2 in >the draft "The first hash value list of each ArchiveTimeStamp must >contain the hash value of the timestamp of the Archive Time-Stamp >before". > > I think, generally every ArchiveTimeStamp contains a reducedHashtree. But if there is only one data object, the data object hash = hashed message in the timestamp and no reducedHashtree is needed, so reducedHashtree=NULL. >- As a more general question: How is 4.2.3 in the draft meant? Do I have >to hash the ArchiveTimeStampSequence or just the concatenated >ArchiveTimeStampChains? I think there is a difference between the two >things since the encoded ArchiveTimeStampSequence would include >additional sequence and length tags. > > In our implementation we hash the ArchiveTimeStampSequence. (Yes, there is a difference). Best regards Susanne -- __________________________________________________________ Dipl.-Math.(FH) Susanne Okunick Fraunhofer Institute for Secure Information Technology Department Transaction and Document Security Rheinstraße 75, 64295 Darmstadt, Germany phone ++49 / (0)6151 869 60220, fax ++49 / (0)6151 869 322 email: susanne.okunick@sit.fraunhofer.de homepage: http://www.sit.fraunhofer.de __________________________________________________________ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IKo3tb077499; Wed, 18 Jan 2006 12:50:03 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0IKo3SN077498; Wed, 18 Jan 2006 12:50:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from newodin.ietf.org ([132.151.6.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IKo2Jn077490 for ; Wed, 18 Jan 2006 12:50:02 -0800 (PST) (envelope-from mlee@newodin.ietf.org) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EzKFl-0007I4-OP; Wed, 18 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-pki-retention-00.txt Message-Id: Date: Wed, 18 Jan 2006 15:50:01 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Infrastructure Support for Retention of PKI Artifacts Author(s) : C. Wallace Filename : draft-ietf-ltans-pki-retention-00.txt Pages : 14 Date : 2006-1-18 In most PKIs, directory servers are used to provide current certificates and revocation information to relying parties. In situations where certificates must be validated relative to a time in the past, relying parties often have no means of obtaining the necessary PKI artifacts. This specification defines several directory attributes to support validation using historical PKI artifacts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-pki-retention-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-pki-retention-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-pki-retention-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-18115811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-pki-retention-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-pki-retention-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-18115811.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IFuIWV025505; Wed, 18 Jan 2006 07:56:18 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0IFuIrv025504; Wed, 18 Jan 2006 07:56:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0IFuIlK025495 for ; Wed, 18 Jan 2006 07:56:18 -0800 (PST) (envelope-from chokhani@orionsec.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: LTANS: Examples of ERS data - cross checking of implementations Date: Wed, 18 Jan 2006 08:02:10 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C879D69CE1@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS: Examples of ERS data - cross checking of implementations thread-index: AcYbiAulbNiMlPShS7mg1AozTTOuxQAvl/nA From: "Santosh Chokhani" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0IFuIlK025499 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would rather see the answers come from the I-D authors. That said, see my reading of the I-D and security requirements below. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Frei Adrian (frr) Sent: Tuesday, January 17, 2006 12:04 PM To: ietf-ltans@imc.org Subject: RE: LTANS: Examples of ERS data - cross checking of implementations Hello, I'm currently working on my own implementation of ERS and I would be glad to cross check my implementation with others. For now, I've tried to validate the attached data, but had no luck so far. So I've a few questions: - How did the concatenation and hashing of the values in the reduced hash tree happen? When I concatenate the three values (51B1..., 5BD0..., 60BB...) in the first list in ascending order an hash them with ripemd160, I get no value of the second list (B537..., 46D8...) [Santosh Chokhani] I do not understand this issue. - Why doesn't the second ArchivTimeStamp in the first ArchiveTimeStampChain contain a reduced hash tree? [Santosh Chokhani] The reason is that since the hash algorithm is still secure, including the hash of the current time stamp chain According to 4.3.2 in the draft "The first hash value list of each ArchiveTimeStamp must contain the hash value of the timestamp of the Archive Time-Stamp before". - As a more general question: How is 4.2.3 in the draft meant? Do I have to hash the ArchiveTimeStampSequence or just the concatenated ArchiveTimeStampChains? [Santosh Chokhani] I would think that you would need to hash the time stamp chains. I agree that the I-D needs to be lot more clearer in order to ensure interoperability. I think there is a difference between the two things since the encoded ArchiveTimeStampSequence would include additional sequence and length tags. Thanks, Adrian Content Security by MailMarshal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0HH4Mw7033900; Tue, 17 Jan 2006 09:04:22 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k0HH4M6P033899; Tue, 17 Jan 2006 09:04:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mx2.zhwin.ch (mx2.zhwin.ch [160.85.104.51]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k0HH4Lo8033855 for ; Tue, 17 Jan 2006 09:04:21 -0800 (PST) (envelope-from frr@zhwin.ch) Received: from orwell.zhwin.ch ([160.85.104.31]) by mx2.zhwin.ch with esmtp (Exim 4.54) id 1EyuFk-0005pl-B6 for ietf-ltans@imc.org; Tue, 17 Jan 2006 18:04:16 +0100 Received: from dove.zhwin.ch (Not Verified[160.85.196.13]) by orwell.zhwin.ch with NetIQ MailMarshal 6.0 Service Pack 1a (v6,0,3,33) id ; Tue, 17 Jan 2006 18:03:38 +0100 Received: from langouste.zhwin.ch ([160.85.196.12]) by dove.zhwin.ch with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jan 2006 18:04:16 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: LTANS: Examples of ERS data - cross checking of implementations Date: Tue, 17 Jan 2006 18:04:15 +0100 Message-ID: <55FEC03AF31CBE458B6B455F5214CAC7434201@langouste.zhwin.ch> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: LTANS: Examples of ERS data - cross checking of implementations Thread-Index: AcYbiAulbNiMlPShS7mg1AozTTOuxQ== From: "Frei Adrian \(frr\)" To: X-OriginalArrivalTime: 17 Jan 2006 17:04:16.0062 (UTC) FILETIME=[0C301DE0:01C61B88] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id k0HH4Mo8033893 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, I'm currently working on my own implementation of ERS and I would be glad to cross check my implementation with others. For now, I've tried to validate the attached data, but had no luck so far. So I've a few questions: - How did the concatenation and hashing of the values in the reduced hash tree happen? When I concatenate the three values (51B1..., 5BD0..., 60BB...) in the first list in ascending order an hash them with ripemd160, I get no value of the second list (B537..., 46D8...) - Why doesn't the second ArchivTimeStamp in the first ArchiveTimeStampChain contain a reduced hash tree? According to 4.3.2 in the draft "The first hash value list of each ArchiveTimeStamp must contain the hash value of the timestamp of the Archive Time-Stamp before". - As a more general question: How is 4.2.3 in the draft meant? Do I have to hash the ArchiveTimeStampSequence or just the concatenated ArchiveTimeStampChains? I think there is a difference between the two things since the encoded ArchiveTimeStampSequence would include additional sequence and length tags. Thanks, Adrian Content Security by MailMarshal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k05JpW5q058696; Thu, 5 Jan 2006 11:51:32 -0800 (PST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k05JpWu4058695; Thu, 5 Jan 2006 11:51:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from EXVS01.ex.dslextreme.net (netblock-66.51.199.51.dslextreme.com [66.51.199.51] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id k05JpW5Q058613 for ; Thu, 5 Jan 2006 11:51:32 -0800 (PST) (envelope-from chokhani@orionsec.com) 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_01C61232.37208DBC" Subject: Comments on draft-ietf-ltans-ers-04 Date: Thu, 5 Jan 2006 11:57:10 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C87999DFDE@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-ltans-ers-04 Thread-Index: AcYSMWmXhPH7AHRYS0W+3XbNCklKIw== From: "Santosh Chokhani" To: Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C61232.37208DBC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 They say it is better late than never. The following are my comments on the version 4 of the ERS draft. I have provided additional edits (nits as well as material) to the I-D authors. =20 Section 1.2, It would be helpful to explain that hash tree is that of the data only and not time-stamp, albeit, the data could include time stamp due to hash tree renewal. =20 Section 1.3, Terminology, The terms "data object" and "data object group" should be defined in this section. =20 Section 1.3, Terminology, In the definition of "Archive Time-Stamp Chain", it should be pointed out that the Archive Time-Stamp Chain is part of evidence record. =20 Section 1.3, Terminology, In the definition of "Archive Time-Stamp Sequence", it should be pointed out that the Archive Time-Stamp Sequence is part of evidence record. =20 Section 3.2, Last Sentence (repeated in quotes): "Note [ANSX995], [I180142] and [I180143] specify irrefutably verifiable time-stamps which do not depend on certificates, CRLS, or OCSP-Responses for digital signature verification." The sentence does not seem correct. The phrase "for digital signature verification" should be deleted since in symmetric key MAC and hash trees, you may not have public keys and hence PKI artifacts. =20 Section 3.3, The variable "h" is used to denote different values. For example see item 3 in the section. Other variable names should be chosen for different variables. =20 Section 4.2, 3rd paragraph, last sentence (repeated in quotes): The new Archive Time-Stamp must use the same hash algorithm within its hash-tree as the old one, which is specified in the hash algorithm field of the Archive Time-Stamp or within the time-stamp itself". This is confusing at two levels. One, it does not seem that the hash tree needs to be re-hashed. The root Hash can be hashed with the time stamp sequence. Two, it would seem that we would use the hash algorithm defined for the hash tree as opposed to one for calculating the hash for the time stamp token signing. =20 Section 5, This section is still unclear and the implementers will have problems. More clarity is needed in all three subsections to ensure interoperability and security. Santosh Chokhani=20 Orion Security Solutions, Inc.=20 1489 Chain Bridge Road, Suite 300=20 McLean, Virginia 22101=20 (703) 917-0060 Ext. 35 (voice)=20 (703) 917-0260 (Fax)=20 chokhani@orionsec.com=20 Visit our Web site=20 http://www.orionsec.com =20 =20 ________________________________ ------_=_NextPart_001_01C61232.37208DBC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

They say it is better late than never.  The following are my comments on = the version 4 of the ERS draft.  I have provided additional edits (nits = as well as material) to the I-D authors.

 

Section 1.2, It would be helpful to explain that hash tree is that of the data = only and not time-stamp, albeit, the data could include time stamp due to hash = tree renewal.

 

Section 1.3, Terminology, The terms “data object” and “data = object group” should be defined in this = section.

 

Section 1.3, Terminology, In the definition of “Archive Time-Stamp = Chain”, it should be pointed out that the Archive Time-Stamp Chain is part of = evidence record.

 

Section 1.3, Terminology, In the definition of “Archive Time-Stamp Sequence”, it should be pointed out that the Archive Time-Stamp = Sequence is part of evidence record.

 

Section 3.2, Last Sentence (repeated in quotes): “Note [ANSX995], [I180142] and [I180143] = specify irrefutably verifiable time-stamps which do not depend on certificates, = CRLS, or OCSP-Responses for digital signature verification.”  The = sentence does not seem correct.  The phrase “for digital signature verification” should be deleted since in symmetric key MAC and = hash trees, you may not have public keys and hence PKI = artifacts.

 

Section 3.3, The variable “h” is used to denote different = values.  For example see item 3 in the section.  Other variable names should be = chosen for different variables.

 

Section 4.2, 3rd paragraph, last sentence (repeated in quotes): The = new Archive Time-Stamp must use the same hash algorithm within its hash-tree = as the old one, which is specified in the hash algorithm field of the Archive Time-Stamp or within the time-stamp itself”.  This is = confusing at two levels.  One, it does not seem that the hash tree needs to be re-hashed.  The root Hash can be hashed with the time stamp sequence.  Two, it would seem that we would use the hash algorithm = defined for the hash tree as opposed to one for calculating the hash for the = time stamp token signing.

 

Section 5, This section is still unclear and the implementers will have = problems.  More clarity is needed in all three subsections to ensure = interoperability and security.

Santosh = Chokhani
Orion Security Solutions, Inc.
1489 Chain Bridge Road, = Suite 300
McLean, Virginia 22101
(703) 917-0060 = Ext. = 35 (voice)
(703) 917-0260 (Fax)
chokhani@orionsec.com=
Visit our Web site
http://www.orionsec.com

 

------_=_NextPart_001_01C61232.37208DBC--