Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TGeWP2028369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 09:40:32 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7TGeWmC028368; Wed, 29 Aug 2007 09:40:32 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TGeVGi028361 for ; Wed, 29 Aug 2007 09:40:31 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=h3FbjaPi/8QSfXzg8E0fmjkuqJZB49FyB+NDxT0yb+pyl5KelLGrkV0uGCz7LgFV; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IQQak-0001le-Om; Wed, 29 Aug 2007 12:40:30 -0400 Message-ID: <00bc01c7ea5b$5ffe18c0$174f7d40@home.glassey.com> From: "todd glassey" To: "Thomas Kunz" Cc: , "Mike Fratto" References: <886F5D4C78AFB14D87261206BFB9612E1D31D6B9@scygmxs1.cygnacom.com> <46D2DB71.4030808@sit.fraunhofer.de> <00ef01c7e8c9$33d954a0$174f7d40@home.glassey.com> <46D58918.7020905@sit.fraunhofer.de> Subject: Re: draft-ietf-ltans-dssc-00 comments Date: Wed, 29 Aug 2007 09:40:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79fcb926006a1da99515ffdf884af3ac38350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Herr Kunz - allow me to expand and provide some links backing up what I am saying here. More inline below - [ By the way - although these rules are specific to US Courts, through the MRA's (Mutual Recognition Agreement's) and the Legal Metrological Agreement's between our Countries these are important factors to at least review in the design of anything that will be used to contain long-term legally-provable instances of anything, no matter what Jurisdiction they are operated in or pursuant to the rules of...] ----- Original Message ----- From: "Thomas Kunz" To: "todd glassey" Cc: Sent: Wednesday, August 29, 2007 7:56 AM Subject: Re: draft-ietf-ltans-dssc-00 comments > todd glassey schrieb: > >> >> That is a decision controlled by the Hosting Entity's Operations Policies >> and needs to be retained as such. The answer is that both methods should >> work IMHO. >> > With "Hosting Entity" do you mean the publisher of a policy? Yes although that policy may be layered on other local policies and/or controls as well. > > >>> > For policy brevity, >> >> which IS NOT a good thing here... Policy is what allows NEA to be used >> in a number of different scenario's >> > Unfortunately, we are not familiar with the abbreviations you use (NEA, > MRA, FRE). So would you please give some explanations? Thanks. NEA is the IETF NEA proposed protocol - a toolset for preqwualifing and continuously qualifying a node or infrastructure for 'permission to operate' within a network at some defined level of Entitlement. MRA is a term meaning 'Mutual Recognition Agreements' - these are treaties and other agreement's like the "Legal Metrological Agreement's" which create the ability to internationally timestamp digital content. Here for example is a MRA between the US and Iceland which also notices conformity with EFTA and EEA entity rules as well. http://ts.nist.gov/Standards/Global/upload/US-EEA_EFTA_States_MRA_Oct_17_051.pdf - the point is that there a MANY of these which constrain the operations of international commerce - something that LTANS needs to facilitate the enduring proof of. FRE is the US Federal Rules of Evidence - which constrain how content is qualified as evidence for the US District and Circuit Courts. http://www.law.cornell.edu/rules/fre/ > > >> Nope... I dont think this has anything to do with "law cases". I think it >> has to do with logging and assurance models and that's about it. What's >> missing is to qualify NEA under the new Judge Grimm ruling so that NEA >> based testimnoy ius admissible into the US and Foreign Court's that >> support similar standards or MRA's. >> >> You want to know what is missing here? >> >> a.. Relevance; i.e. meets F.R.E. 401 >> > > > Also at this point, some further explanations would be nice and helpful > for understanding. On May 4th 2007 a US Federal Court Judge (Chief Magistrate Judge Paul W. Grimm) from the Maryland District Courts issued what many are referring to as a landmark ruling in a key case called Lorraine v Markel, and as to what that case has to do with the IETF's LTANS group, it set the standard under the US Federal Rules of Evidence for what ESI (Electronically Stored Information) MUST comply with in order to be admissible in a US Court. See our link at www.wireless-time.com/site/news/news-judicial1.htm for links to the Judges ruling itself. Poof - instant hurdle for anything that would create or maintain digital content for legal review. The scope of this ruling is just now being understood because a number of us have actually broken the interacting laws down through flowcharting and process mapping to make a mechanical determination of the scope of this ruling. http://www.ediscoverylaw.com/2007/05/articles/case-summaries/chief-us-magistrate-judge-grimm-provides-detailed-analysis-of-evidentiary-issues-associated-with-electronic-evidence/ That scope not only includes any and all information which civilians may bring before the Court but also to any ESI which a US Attorney may come to bring before the Federal Court's as evidence of something. That means any document which is formally filed with the US Government by ANYONE is constrained under this since it is the Courts, which under the Constritutions Articles and in particular, US Code's Title 5, provides relief from Executive and certain DoD Branch actions as well as Lower Court rulings. So Judge Grimm's District Court (DC) ruling actually effects the use of LTANS technology in the US directly but it also forces that same recognition by any "Foreign Entity which is tied to the US through Mutual Recognition Agreement's for time and other legal standards"... and yes this ruling invalidates a number of the components and idea behind RFC3161 as well as the ETSI's time stamping directive which violates those MRAs directly andIMHO International Law as such. As to why he could do this - Judge Grimm is one of the US Court Systems strongest proponents of rules for digital content. He is a very noted Judge who's role as the Chief Magistrate Judge for his district gives him exactly this ability. http://www.msa.md.gov/msa/mdmanual/39fed/04usmag/html/msa13723.html http://www.thesedonaconference.org/people/profiles/GrimmPaul Todd > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TEuTXH019822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 07:56:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7TEuTKQ019821; Wed, 29 Aug 2007 07:56:29 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TEuRCo019814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2007 07:56:28 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.89.208] (sitp1_73.sit.fraunhofer.de [141.12.68.73]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l7TEuOmt011683; Wed, 29 Aug 2007 16:56:25 +0200 Message-ID: <46D58918.7020905@sit.fraunhofer.de> Date: Wed, 29 Aug 2007 16:56:24 +0200 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: todd glassey CC: ietf-ltans@imc.org Subject: Re: draft-ietf-ltans-dssc-00 comments References: <886F5D4C78AFB14D87261206BFB9612E1D31D6B9@scygmxs1.cygnacom.com> <46D2DB71.4030808@sit.fraunhofer.de> <00ef01c7e8c9$33d954a0$174f7d40@home.glassey.com> In-Reply-To: <00ef01c7e8c9$33d954a0$174f7d40@home.glassey.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020408060809000506050904" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020408060809000506050904 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit todd glassey schrieb: > > That is a decision controlled by the Hosting Entity's Operations > Policies and needs to be retained as such. The answer is that both > methods should work IMHO. > With "Hosting Entity" do you mean the publisher of a policy? >> > For policy brevity, > > which IS NOT a good thing here... Policy is what allows NEA to be used > in a number of different scenario's > Unfortunately, we are not familiar with the abbreviations you use (NEA, MRA, FRE). So would you please give some explanations? Thanks. > Nope... I dont think this has anything to do with "law cases". I think > it has to do with logging and assurance models and that's about it. > What's missing is to qualify NEA under the new Judge Grimm ruling so > that NEA based testimnoy ius admissible into the US and Foreign Court's > that support similar standards or MRA's. > > You want to know what is missing here? > > a.. Relevance; i.e. meets F.R.E. 401 > Also at this point, some further explanations would be nice and helpful for understanding. --------------ms020408060809000506050904 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 CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA4MjkxNDU2MjRaMCMGCSqGSIb3 DQEJBDEWBBQkSxl8amLarIou1KMrdaQ/QekSEDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAJisM08TPyXRcgf3cTKuC5lXKXoeW/a2k847ua3lOfklwKMhwWhdzoRg wPeo9Wn6C07M/cdlI0B85HS5DU7KV4N5ilF/KEQp9jtTjUyXtNxXRXA9lkgfEHfS2Q8urxlW +V1KCux60iO/VKTssxwd690eERYcJRPfYYFyBJmFGciiWPH+R0wkA5cgCx8NfUvCc0eNwubu zfXFk21v5UvrVZQOrwOIF4PyCI5BD/RbVWhAyVsodRDjn2+VNHDTXnHAf6VWngTX7s7ssZW6 1NtmaGQuqdJ/lL0ikNaQ/dgqxC93y8fCD8Z3vdw7xy8fzf9OVLfVXFfJvueCeVzmnAhaV70A AAAAAAA= --------------ms020408060809000506050904-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TEhb9Q018669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2007 07:43:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7TEhb5N018668; Wed, 29 Aug 2007 07:43:37 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7TEhX8e018642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2007 07:43:35 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.89.208] (sitp1_73.sit.fraunhofer.de [141.12.68.73]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l7TEh2WW011084; Wed, 29 Aug 2007 16:43:03 +0200 Message-ID: <46D585F6.2040107@sit.fraunhofer.de> Date: Wed, 29 Aug 2007 16:43:02 +0200 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peter Sylvester CC: ietf-ltans@imc.org Subject: Re: draft-ietf-ltans-dssc-00 comments References: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> <46D30F9F.4080003@edelweb.fr> In-Reply-To: <46D30F9F.4080003@edelweb.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000200020208070500080706" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms000200020208070500080706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Guten Tag, Peter Sylvester schrieb: > Guten Abend, > > I have a problem with the first important use case concerning archiving. > > I am not sure what is actually what kind of signatures are addressed here. > > - An archive service can have internal signatures or signatures on > attestations > concerning that data that are archived. > - user signatures of data in archive, i.e. the archive stored signed > documents. > > Which means also who is supposed to re-sign, time stamp or whatever. > With the first use case (long-term archiving) we address user signatures of data in the archive as well as signatures in (archive)timestamps. So the re-signing is done by the archive service. Of course when verifying the internal signatures of the archive service (e.g. signatures on attestations), the validity of the used algorithms can also be checked, but I think, that is covered by our second use case (signing and verifying). Regards Thomas --------------ms000200020208070500080706 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 CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA4MjkxNDQzMDJaMCMGCSqGSIb3 DQEJBDEWBBQa+87wTLFE7lGhtv3zFzOaIh/93DBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAIGfxKgEvt+KTjzFwBtoBzYyrljH8NXhEogXDBidXlUDWG+nJMtPjYQ7 ds6E6finau274rqDeuLvc/52BjwBm1XNvN2/Lyh5mE/+0xf6tZIe1zKhTMUuYutwO2bUI8+0 JQlJtQ+grRg7A8y/FqK3SWx6TZDSnLuAszioEhPdMbJOJPt0m6boH0QwMtVzOZCQkLPjnqvo NPeaC3PH4bA9HQ39qAwCDD2DBrtNyQj3POLldbRLehjHTXQLIDz5ISzd1A41tEPMEpN384eb ojPuvF6peZ2UI1KTEYZaQh3zGf1qedAzmz8DzjWOCCxq/TCHneGFIoJDZ1uhYWI7rFQjwrQA AAAAAAA= --------------ms000200020208070500080706-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RHulbW018215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 10:56:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7RHulmB018214; Mon, 27 Aug 2007 10:56:47 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RHujQS018207 for ; Mon, 27 Aug 2007 10:56:46 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 5A8F438 for ; Mon, 27 Aug 2007 19:56:42 +0200 (CEST) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32515-08 for ; Mon, 27 Aug 2007 19:56:38 +0200 (CEST) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 57CBC34 for ; Mon, 27 Aug 2007 19:56:38 +0200 (CEST) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007082719562948:19470 ; Mon, 27 Aug 2007 19:56:29 +0200 Message-ID: <46D30F9F.4080003@edelweb.fr> Date: Mon, 27 Aug 2007 19:53:35 +0200 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: draft-ietf-ltans-dssc-00 comments References: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 08/27/2007 07:56:30 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 08/27/2007 07:56:37 PM, Serialize complete at 08/27/2007 07:56:37 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000505010705020608030709" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms000505010705020608030709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Guten Abend, I have a problem with the first important use case concerning archiving. I am not sure what is actually what kind of signatures are addressed here. - An archive service can have internal signatures or signatures on attestations concerning that data that are archived. - user signatures of data in archive, i.e. the archive stored signed documents. Which means also who is supposed to re-sign, time stamp or whatever. I think the paragraph needs at least some more precise definition, in particular with regard to what is defined in LTAP. regards Peter --------------ms000505010705020608030709 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwODI3MTc1MzM1WjAjBgkqhkiG9w0B CQQxFgQUi7mqOx84pNz/qnq3oNpOpluajdIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCq+KMoDeMHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCq+KMoDeMA0GCSqGSIb3DQEBAQUABIGApNYc9G+f/IR0Mhgc Vo4nfDHL70U8emL/iJct1Z8ZnAjhqgyoyrxleHxSSeX4/tW/9jNxKtM49d2EvDIS3sNIc6aM 0Lv8kMV6fr1cPyPWNLjvBnqclxYHwP9ZgAWkltKkFfXrrAp/nnSGybrXRF3cqRf2e+AcM+di CoSzaZh5CDwAAAAAAAA= --------------ms000505010705020608030709-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RGfqMW011484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 09:41:52 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7RGfq0F011483; Mon, 27 Aug 2007 09:41:52 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RGfpUe011477 for ; Mon, 27 Aug 2007 09:41:51 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QTmAaHimsOHl6t/+6GvuSZlIbHhjZgtFGzlU6Cfwyhi4ZJXR0zH5mCs/TtSIhouM; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IPhew-0003C1-4e; Mon, 27 Aug 2007 12:41:50 -0400 Message-ID: <00ef01c7e8c9$33d954a0$174f7d40@home.glassey.com> From: "todd glassey" To: "Thomas Kunz" , "Carl Wallace" Cc: References: <886F5D4C78AFB14D87261206BFB9612E1D31D6B9@scygmxs1.cygnacom.com> <46D2DB71.4030808@sit.fraunhofer.de> Subject: Re: draft-ietf-ltans-dssc-00 comments Date: Mon, 27 Aug 2007 09:41:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79a26d60f0f47f222d59e25b950905595b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Thomas Kunz" To: "Carl Wallace" Cc: Sent: Monday, August 27, 2007 7:10 AM Subject: Re: draft-ietf-ltans-dssc-00 comments > Hello Carl, > > sorry for the late answer. > > Carl Wallace schrieb: >> Here are a few comments on DSSC. I'll send an off list email with some >> editorial comments. >> >> - In section 4.1, the fifth element in the sequence should be named >> SuitableAlgorithm to be consistent with the schema in Appendix B >> > OK > > >> - The draft should provide some guidance regarding constraints. For >> example, should one define key size constraints per public key algorithm >> or per each signature algorithm? That is a decision controlled by the Hosting Entity's Operations Policies and needs to be retained as such. The answer is that both methods should work IMHO. > > For policy brevity, which IS NOT a good thing here... Policy is what allows NEA to be used in a number of different scenario's >> the former would be better. Perhaps an alternative would be to bind >> constraints and validity periods within SuitableAlgorithm. >> > I would also prefer the definition of constraints per public key > algorithm. But how is that to be represented? Is it part of the internal policy controlled by SuitableAlgorithm or where then is it enumerated? > >> - Section 5 should include processing for constraints. > OK > >> - The spec should prohibit including multiple instances of the same >> algorithm identifier w/ the same constraints. If they have those different policy contraints tagged to them then they are different policy instances. Hence it would be reasonable to have multiple policies around the same PKI model. >> > OK > >> - If an ASN.1 version is to be produced, using an enveloping signature >> would make the mapping to CMS easier. >> > OK. An ASN.1 version should come with the next version of the draft. > >> - The assumption in Section 3.2 that one must find an old policy in order >> to determine if an algorithm was valid at a point in the past is too >> complicated. Suitability definitions should accumulate in a single >> policy definition. An enterprise could maintain several policies. For >> example, one complete, one current and one past policy could be >> maintained. Uh, policies could be setup based on Role and Responsibility Separation Models and as such its likely that similar policies would exist in the same NEA Domain(s). >> > In our notion, the policies are published by specific institutions (e.g. > annually) and one policy represents the evaluations based on current > knowledge (e.g. on current findings, RSA with 1024 bit key length could be > valid until end of 2007, but next year a new policy could be published > which states that RSA 1024 is valid until end of 2008). > To expect, that a policy also contains all past evaluations of an > algorithms could be error-prone. Customized Policies are the creation of those that adopt the NEA system, but basic operations policies are what the framework should come out-of-the-bag with. > In our opinion, the question, if the evaluation of an algorithm in an old > policy is different from that in the current policy is primarily important > in law cases. Nope... I dont think this has anything to do with "law cases". I think it has to do with logging and assurance models and that's about it. What's missing is to qualify NEA under the new Judge Grimm ruling so that NEA based testimnoy ius admissible into the US and Foreign Court's that support similar standards or MRA's. You want to know what is missing here? a.. Relevance; i.e. meets F.R.E. 401 So a process for determining relevancy of the information produced and its integrity is key. a.. Authentication; i.e. meets F.R.E. 901 Authentication as to where the information came from is key. Also that the material submitted is what was authenticated meaning that content-integrity propcesses are mandatory as well. a.. Hearsay (if offered for truth) i.e. meets F.R.E 801 The mechanical processes for how this information is produced must be mapped out such that it can be demonstrated to a Court that this data is either beyond hear-say or that the heay-say exceptions in re statements against interest is brouught into play such that this evidence is admissible. a.. Original or Duplicate i.e. meets F.R.E. 1001-1008 OK so is this the original data from the system or a copy/fake of it? a.. Probative Value Outweighed by Prejudicial Value i.e. meets F.R.E. 403 This actually is a set of pre-built policy statements which are designed to meet the requirements of FRE403. These would be a part of the NEA boiler plate and would be the basis of NEA Data's being admitted into the Courts as proper Machine-Testimony. As noted in the above list, these are the five key tests for Digital Evidence being admitted to the US Federal Courts. Of these probably 1,2, 3 and 4 are key tests. Test 5 would be something that would happen at hearing time if the rest of the submission actually meets the other tests and that the opposing counsel doesnt object to 'how it meets those tests' which this group is directly responsible for designing. otherwise each system fielded will have to be proven in Court under a DAUBERT type hearing and if that is true then the IETF will have totally failed there. As to old policy and its review, the review of old policy relative to new policy should only come into play when a new system is installed into a network hosting NEA service-qualifications, or when an existing policy expires and a new one comes into play, and that only has to do with changes in the Entitlement and Logging Constraints for that "New Policy" relative to the old one. > And there you cannot trust, that the current policy correctly quotes past > evaluations, instead you will have to look in the old policy. Only if there is a policy saying that. I can think of any number of NEA scenario's where the current client doesnt care what the past policies were. So I disagree as to 'that the old policies will always need to be reviewed' or be maintained as 'reviewable'. > > Best regards, > Thomas > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7RGapKT011053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 09:36:51 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7RGapu2011052; Mon, 27 Aug 2007 09:36:51 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7RGaoL0011046 for ; Mon, 27 Aug 2007 09:36:51 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 4459 invoked from network); 27 Aug 2007 16:33:34 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;27 Aug 2007 16:33:34 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 27 Aug 2007 16:33:33 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Aug 2007 12:36:48 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D982@scygmxs1.cygnacom.com> From: Carl Wallace To: Thomas Kunz Cc: ietf-ltans@imc.org Subject: RE: draft-ietf-ltans-dssc-00 comments Date: Mon, 27 Aug 2007 12:36:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E8C8.73F01C1A" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7E8C8.73F01C1A Content-Type: text/plain > > - The assumption in Section 3.2 that one must find an old policy in > > order to determine if an algorithm was valid at a point in > the past is > > too complicated. Suitability definitions should accumulate in a > > single policy definition. An enterprise could maintain several > > policies. For example, one complete, one current and one > past policy could be maintained. > > > In our notion, the policies are published by specific > institutions (e.g. > annually) and one policy represents the evaluations based on > current knowledge (e.g. on current findings, RSA with 1024 > bit key length could be valid until end of 2007, but next > year a new policy could be published which states that RSA > 1024 is valid until end of 2008). > To expect, that a policy also contains all past evaluations > of an algorithms could be error-prone. > In our opinion, the question, if the evaluation of an > algorithm in an old policy is different from that in the > current policy is primarily important in law cases. And there > you cannot trust, that the current policy correctly quotes > past evaluations, instead you will have to look in the old policy. I wasn't suggesting that a policy contain all past evaluations. I was suggesting that the current policy would contain the current position with regard to an algorithm's life span, even if the algorithm is no longer viable, and that's the only thing that matters. I don't see the value in referring to an old policy since the position on an algorithm can change over time. Using your example, in my opinion, the only thing that matters to the verifier is what the current position is with regard to an algorithm. The fact that an algorithm's expected life span at the time a signature was generated was thought to be shorter than it turned out to be isn't important. Annual publication makes sense and makes it easy to perform the accumulation. Someone verifying an evidence record will need to know when an algorithm stopped being suitable. It'd be nice if this information could be contained in one location instead of having to collect old policies, i.e., verifiers always use the current edition. My comment that there could be multiple policies was probably confusing. The idea there was that for apps that don't use any expired algorithm, there could be a very brief policy statement with just the currently viable algorithms. Having one full statement is probably easiest though. ------_=_NextPart_001_01C7E8C8.73F01C1A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-ietf-ltans-dssc-00 comments

<snip>
> > - The assumption in Section 3.2 that one = must find an old policy in
> > order to determine if an algorithm was = valid at a point in
> the past is
> > too complicated.  Suitability = definitions should accumulate in a
> > single policy definition.  An = enterprise could maintain several
> > policies.  For example, one complete, = one current and one
> past policy could be maintained.
> >
> In our notion, the policies are published by = specific
> institutions (e.g.
> annually) and one policy represents the = evaluations based on
> current knowledge (e.g. on current findings, = RSA with 1024
> bit key length could be valid until end of = 2007, but next
> year a new policy could be published which = states that RSA
> 1024 is valid until end of 2008).
> To expect, that a policy also contains all past = evaluations
> of an algorithms could be error-prone.
> In our opinion, the question, if the evaluation = of an
> algorithm in an old policy is different from = that in the
> current policy is primarily important in law = cases. And there
> you cannot trust, that the current policy = correctly quotes
> past evaluations, instead you will have to look = in the old policy.

I wasn't suggesting that a policy contain all past = evaluations.  I was suggesting that the current policy would = contain the current position with regard to an algorithm's life span, = even if the algorithm is no longer viable, and that's the only thing = that matters.  I don't see the value in referring to an old policy = since the position on an algorithm can change over time.  Using = your example, in my opinion, the only thing that matters to the = verifier is what the current position is with regard to an = algorithm.  The fact that an algorithm's expected life span at the = time a signature was generated was thought to be shorter than it turned = out to be isn't important. 

Annual publication makes sense and makes it easy to = perform the accumulation.  Someone verifying an evidence record = will need to know when an algorithm stopped being suitable.  It'd = be nice if this information could be contained in one location instead = of having to collect old policies, i.e., verifiers always use the = current edition.  My comment that there could be multiple policies = was probably confusing.  The idea there was that for apps that = don't use any expired algorithm, there could be a very brief policy = statement with just the currently viable algorithms.  Having one = full statement is probably easiest though.

------_=_NextPart_001_01C7E8C8.73F01C1A-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7REB6l1095628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Aug 2007 07:11:06 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7REB6VJ095627; Mon, 27 Aug 2007 07:11:06 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.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 balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7REB3q8095604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Aug 2007 07:11:05 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.89.208] (sitp2_26.sit.fraunhofer.de [141.12.69.26]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id l7REAvVF018199; Mon, 27 Aug 2007 16:10:57 +0200 Message-ID: <46D2DB71.4030808@sit.fraunhofer.de> Date: Mon, 27 Aug 2007 16:10:57 +0200 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Carl Wallace CC: ietf-ltans@imc.org Subject: Re: draft-ietf-ltans-dssc-00 comments References: <886F5D4C78AFB14D87261206BFB9612E1D31D6B9@scygmxs1.cygnacom.com> In-Reply-To: <886F5D4C78AFB14D87261206BFB9612E1D31D6B9@scygmxs1.cygnacom.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070309080407070303040809" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms070309080407070303040809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Carl, sorry for the late answer. Carl Wallace schrieb: > Here are a few comments on DSSC. I'll send an off list email with some > editorial comments. > > - In section 4.1, the fifth element in the sequence should be named > SuitableAlgorithm to be consistent with the schema in Appendix B > OK > - The draft should provide some guidance regarding constraints. For > example, should one define key size constraints per public key algorithm > or per each signature algorithm? For policy brevity, the former would > be better. Perhaps an alternative would be to bind constraints and > validity periods within SuitableAlgorithm. > I would also prefer the definition of constraints per public key algorithm. > - Section 5 should include processing for constraints. > OK > - The spec should prohibit including multiple instances of the same > algorithm identifier w/ the same constraints. > OK > - If an ASN.1 version is to be produced, using an enveloping signature > would make the mapping to CMS easier. > OK. An ASN.1 version should come with the next version of the draft. > - The assumption in Section 3.2 that one must find an old policy in > order to determine if an algorithm was valid at a point in the past is > too complicated. Suitability definitions should accumulate in a single > policy definition. An enterprise could maintain several policies. For > example, one complete, one current and one past policy could be maintained. > In our notion, the policies are published by specific institutions (e.g. annually) and one policy represents the evaluations based on current knowledge (e.g. on current findings, RSA with 1024 bit key length could be valid until end of 2007, but next year a new policy could be published which states that RSA 1024 is valid until end of 2008). To expect, that a policy also contains all past evaluations of an algorithms could be error-prone. In our opinion, the question, if the evaluation of an algorithm in an old policy is different from that in the current policy is primarily important in law cases. And there you cannot trust, that the current policy correctly quotes past evaluations, instead you will have to look in the old policy. Best regards, Thomas --------------ms070309080407070303040809 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 CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzA4MjcxNDEwNTdaMCMGCSqGSIb3 DQEJBDEWBBRxUuQEVQc2RXudLFAInv2XActvUDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAAmY9WwykkS16VtWnW0Jb6aFl0tF/myTUN9aT5kq0EYq4C7JTk4kunJF nzEjp5fIVp209zVwTxy7WQGHkfeSbTuvXRcxHyvMlZt8qToA1H64+llpyI0tsf38isQvKPCT LWWfwNPqYQpcywcGrXRfqatBgRdNUrobuf/TapLl80a67N9M/OWtKWVh9pwOMJv7LbNT9aKx 51SykrpOsswY1xmowTWTtxzE4H1iPkcBr0RM6ATYVNa+k0NG8x2KthPlkQPK6De1mKo6jV79 4Pnwmr/K/VZKwlBOyN43BxQWZY4sTZW1R+JjB9bRJ1dU27Zkkqp1ibSErRR5HamBH9QEuXcA AAAAAAA= --------------ms070309080407070303040809-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7KHsUQx050632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 10:54:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7KHsUF4050631; Mon, 20 Aug 2007 10:54:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7KHsT5N050623 for ; Mon, 20 Aug 2007 10:54:30 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 1406 invoked from network); 20 Aug 2007 17:51:23 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;20 Aug 2007 17:51:23 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 20 Aug 2007 17:51:23 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Aug 2007 13:54:28 -0400 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D31D6B9@scygmxs1.cygnacom.com> From: Carl Wallace To: ietf-ltans@imc.org Subject: draft-ietf-ltans-dssc-00 comments Date: Mon, 20 Aug 2007 13:54:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E353.272F3FF0" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7E353.272F3FF0 Content-Type: text/plain Here are a few comments on DSSC. I'll send an off list email with some editorial comments. - In section 4.1, the fifth element in the sequence should be named SuitableAlgorithm to be consistent with the schema in Appendix B - The draft should provide some guidance regarding constraints. For example, should one define key size constraints per public key algorithm or per each signature algorithm? For policy brevity, the former would be better. Perhaps an alternative would be to bind constraints and validity periods within SuitableAlgorithm. - Section 5 should include processing for constraints. - The spec should prohibit including multiple instances of the same algorithm identifier w/ the same constraints. - If an ASN.1 version is to be produced, using an enveloping signature would make the mapping to CMS easier. - The assumption in Section 3.2 that one must find an old policy in order to determine if an algorithm was valid at a point in the past is too complicated. Suitability definitions should accumulate in a single policy definition. An enterprise could maintain several policies. For example, one complete, one current and one past policy could be maintained. ------_=_NextPart_001_01C7E353.272F3FF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable draft-ietf-ltans-dssc-00 comments

Here are a few comments on DSSC.  I'll send an = off list email with some editorial comments.

- In section 4.1, the fifth element in the sequence = should be named SuitableAlgorithm to be consistent with the schema in = Appendix B

- The draft should provide some guidance regarding = constraints.  For example, should one define key size constraints = per public key algorithm or per each signature algorithm?  For = policy brevity, the former would be better.  Perhaps an = alternative would be to bind constraints and validity periods within = SuitableAlgorithm.

- Section 5 should include processing for = constraints. 

- The spec should prohibit including multiple = instances of the same algorithm identifier w/ the same = constraints.

- If an ASN.1 version is to be produced, using an = enveloping signature would make the mapping to CMS easier.

- The assumption in Section 3.2 that one must find an = old policy in order to determine if an algorithm was valid at a point = in the past is too complicated.  Suitability definitions should = accumulate in a single policy definition.  An enterprise could = maintain several policies.  For example, one complete, one current = and one past policy could be maintained.

------_=_NextPart_001_01C7E353.272F3FF0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HNh4pt010166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 16:43:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HNh46N010165; Fri, 17 Aug 2007 16:43:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HNh4MO010159 for ; Fri, 17 Aug 2007 16:43:04 -0700 (MST) (envelope-from rfc-editor@rfc-editor.org) Received: by bosco.isi.edu (Postfix, from userid 70) id 9531ADFB25; Fri, 17 Aug 2007 16:42:01 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4998 on Evidence Record Syntax (ERS) From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ietf-ltans@imc.org Message-Id: <20070817234201.9531ADFB25@bosco.isi.edu> Date: Fri, 17 Aug 2007 16:42:01 -0700 (PDT) Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A new Request for Comments is now available in online RFC libraries. RFC 4998 Title: Evidence Record Syntax (ERS) Author: T. Gondrom, R. Brandner, U. Pordesch Status: Standards Track Date: August 2007 Mailbox: tobias.gondrom@opentext.com, ralf.brandner@intercomponentware.com, ulrich.pordesch@zv.fraunhofer.de Pages: 32 Characters: 66888 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ltans-ers-15.txt URL: http://www.rfc-editor.org/rfc/rfc4998.txt In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS TRACK] This document is a product of the Long-Term Archive and Notary Services Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ...