From owner-ietf-ltans Wed Sep 8 01:40:10 2004 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 i888eAWw090713; Wed, 8 Sep 2004 01:40:10 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i888eAUR090712; Wed, 8 Sep 2004 01:40:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i888e8j2090622 for ; Wed, 8 Sep 2004 01:40:09 -0700 (PDT) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-maranello [141.12.87.97]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id KAA28100 for ; Wed, 8 Sep 2004 10:39:52 +0200 (MET DST) Message-ID: <413EC58F.90604@sit.fraunhofer.de> Date: Wed, 08 Sep 2004 10:40:47 +0200 From: Thomas Kunz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Notary services: Additional use-cases Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020108060202080203030402" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020108060202080203030402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, in addition to the use-cases already described in the notary services requirements, we would like to present some further use-cases. Rectification of false statements: One service can be the rectification, the supplementation, or the cancellation of some parts of the original document on demand of the document's owner. In a similar use-case the service can obliterate confidential parts (e.g. names of involved persons) in copy documents in order to publish it. Both use-cases can be understood as special kinds of transformations. In particular in the first use-case the service has to document the rectifications. Best regards, Thomas ------------------------------------------------------------ Dipl. Inf. Thomas Kunz Fraunhofer - Institut für Sichere Telekooperation (FhG-SIT) Dolivostrasse 15 D-64293 Darmstadt (Germany) Tel: +49-6151-869-60204 ------------------------------------------------------------ e-mail: thomas.kunz@sit.fraunhofer.de http://www.sit.fraunhofer.de ------------------------------------------------------------ --------------ms020108060202080203030402 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 CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA5MDgwODQwNDdaMCMGCSqGSIb3 DQEJBDEWBBRXWj87VqYffQvKCfcmWXmKPSLlqTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBADYkEqfk2LIXQDZKR6jz11JhLIF0HX68zuMTsxfmWJac38mZxL0cH/bf bm+CUcDGMWGkZRnajFwdLJ69QVi0LFfZ9LnsyQyC8kc9OjvR3NTzduFO2+dY0ZLZULPqVihs uJ5BjJEC8dBrVUHPv+3G96g38fh+HAFOy0iHI+DawacVerPkeV4sN7s4xt8pit+avDWhiBUH uaxJoFhWUb5+pBWueFo4AKy82V21kp/aw9AgZX9hzKvbDG0aTGSl6HsabxCpAm62x6DlOtlW NovX03sL+Kzo/hUk/9yDL6vn1mEgiN9BLybfxMrWU2TaIm4MCNVJRz64yoAoTV9pOewh85oA AAAAAAA= --------------ms020108060202080203030402-- From owner-ietf-ltans Wed Sep 8 13:30:57 2004 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 i88KUvwi097459; Wed, 8 Sep 2004 13:30:57 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88KUvR7097458; Wed, 8 Sep 2004 13:30:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [12.158.35.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88KUs2P097450 for ; Wed, 8 Sep 2004 13:30:55 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob4.obsmtp.com ([12.158.35.250]) with SMTP; Wed, 08 Sep 2004 13:30:59 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i88KUXbA017900; Wed, 8 Sep 2004 13:30:43 -0700 (PDT) Received: from mailsj-dev (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i88KUNkq025026; Wed, 8 Sep 2004 13:30:33 -0700 (PDT) Received: from MasinterT40 (c-131-136.corp.adobe.com [153.32.131.136]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3Q008PSOYMV7@mailsj-v1.corp.adobe.com>; Wed, 08 Sep 2004 13:30:22 -0700 (PDT) Date: Wed, 08 Sep 2004 13:30:22 -0700 From: Larry Masinter Subject: RE: Notary services: Additional use-cases In-reply-to: <413EC58F.90604@sit.fraunhofer.de> To: "'Thomas Kunz'" , ietf-ltans@imc.org Message-id: <0I3Q008PUOYMV7@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSVgmcG7QwO0HvEQc67zBJO1BINeAAX+pNA Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Rectification of false statements: > > One service can be the rectification, the supplementation, or the > cancellation of some parts of the original document on demand of the > document's owner. > In a similar use-case the service can obliterate confidential parts > (e.g. names of involved persons) in copy documents in order to publish > it. > Both use-cases can be understood as special kinds of transformations. > In particular in the first use-case the service has to document the > rectifications. I'm not sure I understand this suggestion... is this something that some notaries perform in some jurisdictions? I know there are some general categories of document processing services that are performed by different organizations, but I don't know where the working group wants to draw the boundary. From owner-ietf-ltans Wed Sep 8 13:37:24 2004 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 i88KbOnw097954; Wed, 8 Sep 2004 13:37:24 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88KbOZn097953; Wed, 8 Sep 2004 13:37:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob3.obsmtp.com [12.158.35.213]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88KbN8p097946 for ; Wed, 8 Sep 2004 13:37:23 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob3.obsmtp.com ([12.158.35.250]) with SMTP; Wed, 08 Sep 2004 13:37:27 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i88KbRNf008329; Wed, 8 Sep 2004 13:37:27 -0700 (PDT) Received: from mailsj-dev (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i88KbRkq026561; Wed, 8 Sep 2004 13:37:27 -0700 (PDT) Received: from MasinterT40 (c-131-136.corp.adobe.com [153.32.131.136]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3Q008YPPAEV7@mailsj-v1.corp.adobe.com>; Wed, 08 Sep 2004 13:37:27 -0700 (PDT) Date: Wed, 08 Sep 2004 13:37:26 -0700 From: Larry Masinter Subject: Notary services requirements -- directions? In-reply-to: <561F9357D239EB428AE3A4F14244431303946C@Louise2> To: "'Richard Hansberger'" , ietf-ltans@imc.org Message-id: <0I3Q008YQPAEV7@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSKuByANBgH4cTvRo26zpmmh8oZfQLKsAvQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Many state laws mandate that Notaries may NOT notarize documents with "blank > or incomplete" spaces. Notaries are expected to review documents carefully, > though not to interpret them for signers. In every case and in every state, > the signer MUST appear before the Notary. Physical presence of the signer > before the Notary is almost the entire premise of notarization. This is interesting information, but I'm not sure how it would affect the document on notary service requirements. Is it proposed that the fact that "Notaries" do these services should affect what we are calling a "Notary Service" in LTANS? > Acknowledgments and jurats are only two types of notarial acts. There are at > least 7 others (off the top of my head). What is common to them all is a > notarial certificate that contains wording indicating the act performed. By > far, however, acknowledgments and jurats comprise the bulk of what Notaries > do on a daily basis. > > California actually does have provisions for electronic notarization (we are > running pilots right now), and three other states do as well: > CO, AZ, PA. I think that we can mainly hope to create a standard interface for those acts that are feasible for "electronic notarization", and that a review of the electronic notarization pilots would be a good place to start. Personally, I would rather not have a long document explaining in detail what real Notaries do, and then point out that most of those things (like verifying physical identity and reading and understanding the document content) aren't in scope for LTANS. Larry From owner-ietf-ltans Wed Sep 8 17:24:35 2004 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 i890OZX6017172; Wed, 8 Sep 2004 17:24:35 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i890OZah017171; Wed, 8 Sep 2004 17:24:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i890OYg3017105 for ; Wed, 8 Sep 2004 17:24:34 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W8911KN500000884; Wed, 08 Sep 2004 17:20:59 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Sep 2004 17:21:18 -0800 Message-ID: <561F9357D239EB428AE3A4F1424443130165F6@Louise2> From: Richard Hansberger To: "'Larry Masinter'" , ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? Date: Wed, 8 Sep 2004 17:21:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: 010325bcec8ba57ba1ddcf5cf9db93c2 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain Larry, In answer to your first question, we've always understood the term "Notary Service" to be a technology that Notaries could use, not a technology that others can use in lieu of notarization. If that means the name of the service needs to change, I'll leave that decision in more capable hands. In answer to your second question, I probably just gave more information that is relevant to the work product at hand. I guess the primary question would be: What is the purpose of a "Notary Service"? Is it what I understand it to be (a technology used by a Notary), or is it intended to be a technology that performs "notarization" per se? If I understand the answer, I'll filter out unnecessary information. Thanks, Rich Hansberger Director of eNotarization National Notary Association rhansberger@nationalnotary.org -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Wednesday, September 08, 2004 1:37 PM To: 'Richard Hansberger'; ietf-ltans@imc.org Subject: Notary services requirements -- directions? > Many state laws mandate that Notaries may NOT notarize documents with "blank > or incomplete" spaces. Notaries are expected to review documents carefully, > though not to interpret them for signers. In every case and in every state, > the signer MUST appear before the Notary. Physical presence of the signer > before the Notary is almost the entire premise of notarization. This is interesting information, but I'm not sure how it would affect the document on notary service requirements. Is it proposed that the fact that "Notaries" do these services should affect what we are calling a "Notary Service" in LTANS? > Acknowledgments and jurats are only two types of notarial acts. There are at > least 7 others (off the top of my head). What is common to them all is a > notarial certificate that contains wording indicating the act performed. By > far, however, acknowledgments and jurats comprise the bulk of what Notaries > do on a daily basis. > > California actually does have provisions for electronic notarization (we are > running pilots right now), and three other states do as well: > CO, AZ, PA. I think that we can mainly hope to create a standard interface for those acts that are feasible for "electronic notarization", and that a review of the electronic notarization pilots would be a good place to start. Personally, I would rather not have a long document explaining in detail what real Notaries do, and then point out that most of those things (like verifying physical identity and reading and understanding the document content) aren't in scope for LTANS. Larry ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- From owner-ietf-ltans Wed Sep 8 19:36:44 2004 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 i892aiWJ027856; Wed, 8 Sep 2004 19:36:44 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i892aidA027855; Wed, 8 Sep 2004 19:36:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i892ai6i027849 for ; Wed, 8 Sep 2004 19:36:44 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i892aoqa002185 for ; Wed, 8 Sep 2004 22:36:50 -0400 From: "Santosh Chokhani" To: Subject: RE: Notary services requirements -- directions? Date: Wed, 8 Sep 2004 22:36:44 -0400 Message-ID: <003701c49615$dbbeca10$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <561F9357D239EB428AE3A4F1424443130165F6@Louise2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I thought that the electronic notary will replace some of the human notary services. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Richard Hansberger Sent: Wednesday, September 08, 2004 9:21 PM To: 'Larry Masinter'; ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? Larry, In answer to your first question, we've always understood the term "Notary Service" to be a technology that Notaries could use, not a technology that others can use in lieu of notarization. If that means the name of the service needs to change, I'll leave that decision in more capable hands. In answer to your second question, I probably just gave more information that is relevant to the work product at hand. I guess the primary question would be: What is the purpose of a "Notary Service"? Is it what I understand it to be (a technology used by a Notary), or is it intended to be a technology that performs "notarization" per se? If I understand the answer, I'll filter out unnecessary information. Thanks, Rich Hansberger Director of eNotarization National Notary Association rhansberger@nationalnotary.org -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Wednesday, September 08, 2004 1:37 PM To: 'Richard Hansberger'; ietf-ltans@imc.org Subject: Notary services requirements -- directions? > Many state laws mandate that Notaries may NOT notarize documents with "blank > or incomplete" spaces. Notaries are expected to review documents carefully, > though not to interpret them for signers. In every case and in every state, > the signer MUST appear before the Notary. Physical presence of the > signer before the Notary is almost the entire premise of notarization. This is interesting information, but I'm not sure how it would affect the document on notary service requirements. Is it proposed that the fact that "Notaries" do these services should affect what we are calling a "Notary Service" in LTANS? > Acknowledgments and jurats are only two types of notarial acts. There > are at > least 7 others (off the top of my head). What is common to them all is > a notarial certificate that contains wording indicating the act > performed. By > far, however, acknowledgments and jurats comprise the bulk of what Notaries > do on a daily basis. > > California actually does have provisions for electronic notarization > (we are > running pilots right now), and three other states do as well: CO, AZ, > PA. I think that we can mainly hope to create a standard interface for those acts that are feasible for "electronic notarization", and that a review of the electronic notarization pilots would be a good place to start. Personally, I would rather not have a long document explaining in detail what real Notaries do, and then point out that most of those things (like verifying physical identity and reading and understanding the document content) aren't in scope for LTANS. Larry From owner-ietf-ltans Thu Sep 9 07:44:41 2004 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 i89EifZ3051786; Thu, 9 Sep 2004 07:44:41 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89EifFo051785; Thu, 9 Sep 2004 07:44:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Eiedq051757 for ; Thu, 9 Sep 2004 07:44:40 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from noorhome.net (localhost [127.0.0.1]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0I3S008FU2NBQV@igw.noorhome.net> for ietf-ltans@imc.org; Thu, 09 Sep 2004 07:23:36 -0700 (PDT) Received: from [12.18.36.40] by igw.noorhome.net (mshttpd); Thu, 09 Sep 2004 10:23:35 -0400 Date: Thu, 09 Sep 2004 10:23:35 -0400 From: Arshad Noor Subject: Re: RE: Notary services requirements -- directions? To: ietf-ltans@imc.org Message-id: <73d390e0.90e073d3@noorhome.net> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In re-reading the Description of the Working Group for LTANS, I now sense that it has two very different objectives - one which is reasonable and the other, which may be premature. The goal of arriving at protocols, structures and mechanisms for archiving and validating digitally signed documents over very long periods is the reasonable goal, since it addresses purely technical issues. The goal of having such technology replace existing legal practices, however small, without documenting all potential risks, is dangerous. I would recommend that the WG first describe, specifically, which aspects of the human notary processes are expected to be automated through technology (through detailed use cases), and then identify the current & anticipated risks to each step of the revised processes and the environment, before embarking on defining solutions. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: Santosh Chokhani Date: Wednesday, September 8, 2004 10:36 pm Subject: RE: Notary services requirements -- directions? > > I thought that the electronic notary will replace some of the > human notary > services. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- > ltans@mail.imc.org]On Behalf Of Richard Hansberger > Sent: Wednesday, September 08, 2004 9:21 PM > To: 'Larry Masinter'; ietf-ltans@imc.org > Subject: RE: Notary services requirements -- directions? > > > Larry, > > In answer to your first question, we've always understood the term > "NotaryService" to be a technology that Notaries could use, not a > technology that > others can use in lieu of notarization. If that means the name of the > service needs to change, I'll leave that decision in more capable > hands. > In answer to your second question, I probably just gave more > informationthat is relevant to the work product at hand. > > I guess the primary question would be: What is the purpose of a > "NotaryService"? Is it what I understand it to be (a technology > used by a Notary), > or is it intended to be a technology that performs "notarization" > per se? > > If I understand the answer, I'll filter out unnecessary information. > > Thanks, > Rich Hansberger > Director of eNotarization > National Notary Association > rhansberger@nationalnotary.org > > -----Original Message----- > From: Larry Masinter [mailto:LMM@acm.org] > Sent: Wednesday, September 08, 2004 1:37 PM > To: 'Richard Hansberger'; ietf-ltans@imc.org > Subject: Notary services requirements -- directions? > > > > Many state laws mandate that Notaries may NOT notarize documents > with"blank > > or incomplete" spaces. Notaries are expected to review documents > carefully, > > though not to interpret them for signers. In every case and in every > state, > > the signer MUST appear before the Notary. Physical presence of the > > signer before the Notary is almost the entire premise of > notarization. > This is interesting information, but I'm not sure how it would > affect the > document on notary service requirements. Is it proposed that the > fact that > "Notaries" do these services should affect what we are calling a > "NotaryService" in LTANS? > > > Acknowledgments and jurats are only two types of notarial acts. > There> are > at > > least 7 others (off the top of my head). What is common to them > all is > > a notarial certificate that contains wording indicating the act > > performed. > By > > far, however, acknowledgments and jurats comprise the bulk of what > Notaries > > do on a daily basis. > > > > California actually does have provisions for electronic notarization > > (we > are > > running pilots right now), and three other states do as well: > CO, AZ, > > PA. > > I think that we can mainly hope to create a standard interface for > thoseacts that are feasible for "electronic notarization", and > that a review of > the electronic notarization pilots would be a good place to start. > > Personally, I would rather not have a long document explaining in > detailwhat real Notaries do, and then point out that most of those > things (like > verifying physical identity and reading and understanding the document > content) aren't in scope for LTANS. > > Larry > > From owner-ietf-ltans Thu Sep 16 05:19:36 2004 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 i8GCJadf030700; Thu, 16 Sep 2004 05:19:36 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GCJa2q030699; Thu, 16 Sep 2004 05:19:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GCJYu1030684 for ; Thu, 16 Sep 2004 05:19:35 -0700 (PDT) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-aragorn [141.12.86.73]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id OAA28337; Thu, 16 Sep 2004 14:19:21 +0200 (MET DST) Message-ID: <414984C8.3000203@sit.fraunhofer.de> Date: Thu, 16 Sep 2004 14:19:20 +0200 From: "Andreas U. Schmidt" Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Use case administering of oaths Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In view of the information provided by Richard Hansberger and the corresponding information that I obtained from German notaries public and which is in full accordance to that, I would like to have the parenthesis (maybe even virtually) be replaced by (note that many jurisdictions at present require the personal presence of the person delivering the oath with the notary, thus oaths cannot be delivered 'virtually') Though I agree with Larry that long explanations of the duties of human notaries, followed by a shrugging remark that they are invalid for notary services are to be avoided, I still think this is a singularly important clarification. AUS From owner-ietf-ltans Sun Sep 19 22:02:39 2004 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 i8K52dSI041260; Sun, 19 Sep 2004 22:02:39 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8K52dfx041259; Sun, 19 Sep 2004 22:02:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [12.158.35.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8K52ac8041233 for ; Sun, 19 Sep 2004 22:02:38 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob4.obsmtp.com ([12.158.35.250]) with SMTP; Sun, 19 Sep 2004 22:02:43 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i8K52hNf011363 for ; Sun, 19 Sep 2004 22:02:43 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i8K52bks012655 for ; Sun, 19 Sep 2004 22:02:43 -0700 (PDT) Received: from MasinterT40 ([130.248.179.4]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4B000GAQ0DOM@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Sun, 19 Sep 2004 22:02:37 -0700 (PDT) Date: Sun, 19 Sep 2004 22:02:38 -0700 From: Larry Masinter Subject: RE: RE: Notary services requirements -- directions? In-reply-to: <73d390e0.90e073d3@noorhome.net> To: ietf-ltans@imc.org Message-id: <0I4B000GCQ0DOM@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSWfvOWwfxQ0iQbTj2BUeHCqU1JfwITM8kg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm looking at the task of updating the Notary Services Requirement document, and I'm still not sure about what direction the working group wants to take. Arshad Noor wrote: > I would recommend that the WG first describe, specifically, > which aspects of the human notary processes are expected > to be automated through technology (through detailed use > cases), and then identify the current & anticipated risks to > each step of the revised processes and the environment, > before embarking on defining solutions. I think the scope of "Digital Notary Services" includes some processes that don't have an exact analogy with human notary processes. For example, mechanical time-stamping by tamper-resistant devices isn't a process that is easily described as an "aspect of the human notary processes". So while I agree with Arshad's stepwise approach, the range of possibilities is somewhat broader. I think we are looking at a range of network services that provide future assurances about current or past documents or events. >From this point of view, we can look at the "human notary processes" for inspiration, but not necessarily as the driver of requirements. Proposed revised Abstract: This document establishes the scope and requirements for protocol development in the area of 'digital notary services': network services that provide future assurances about current or past documents or events. The term 'notary service' is used by analogy with the wide range of services offered by human notaries for paper-based processes. The document discusses the historical context of notary services, defines terms, includes use cases and scenarios, and establishes technical requirements for network protocols for communication with network elements providing related services. We were hoping to get some information from the OASIS LegalXML group... does anyone have any news on that, or on the liaison request? Larry From owner-ietf-ltans Tue Sep 21 12:39:04 2004 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 i8LJd4FV064740; Tue, 21 Sep 2004 12:39:04 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LJd4dw064739; Tue, 21 Sep 2004 12:39:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LJd1Ac064731 for ; Tue, 21 Sep 2004 12:39:02 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14208; Tue, 21 Sep 2004 15:39:03 -0400 (EDT) Message-Id: <200409211939.PAA14208@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-reqs-02.txt Date: Tue, 21 Sep 2004 15:39:03 -0400 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 : Long term archive service requirements Author(s) : C. Wallace, et al. Filename : draft-ietf-ltans-reqs-02.txt Pages : 17 Date : 2004-9-21 In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the technical requirements for a long-term archive service to support such scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-02.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-reqs-02.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-reqs-02.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: <2004-9-21153213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21153213.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ltans Wed Sep 22 16:34:42 2004 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 i8MNYf2A098692; Wed, 22 Sep 2004 16:34:41 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MNYfD0098691; Wed, 22 Sep 2004 16:34:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MNYdwx098681 for ; Wed, 22 Sep 2004 16:34:40 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W8N01TC0000004B8; Wed, 22 Sep 2004 16:29:48 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Sep 2004 16:31:07 -0800 Message-ID: <561F9357D239EB428AE3A4F14244431368CD88@Louise2> From: Richard Hansberger To: "'Larry Masinter'" , "'ietf-ltans@imc.org'" Subject: RE: RE: Notary services requirements -- directions? Date: Wed, 22 Sep 2004 16:30:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: 1732cbf026a2ed1a54fe104183c420fe Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain Larry, I am a member of the OASIS LegalXML group. I can introduce a liaison from this group to the chair, John Messing, directly. I would humbly suggest that you revise the abstract as below. The simple fact of the matter is that human Notaries in the states and abroad now perform paperless electronic notarizations that fulfill the requirements of notarial law, as well as offer time/date stamping services akin to what this group is attempting to do (mostly through dig sig technology). Human Notaries simply provide other assurances that the "digital Notary services" do not; however, I fully expect to embrace the work product of this group to extend the work we do even further. Proposed revised Abstract (IN CAPS): This document establishes the scope and requirements for protocol development in the area of 'digital notary services': network services that provide future assurances about current or past documents or events. The term 'notary service' is used by analogy with the wide range of services offered by human notaries for ELECTRONIC OR PAPER-BASED processes. The document discusses the historical context of notary services, defines terms, includes use cases and scenarios, and establishes technical requirements for network protocols for communication with network elements providing related services. Richard J. Hansberger Director of eNotarization National Notary Association 818-739-4027 -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Sunday, September 19, 2004 9:03 PM To: ietf-ltans@imc.org Subject: RE: RE: Notary services requirements -- directions? I'm looking at the task of updating the Notary Services Requirement document, and I'm still not sure about what direction the working group wants to take. Arshad Noor wrote: > I would recommend that the WG first describe, specifically, > which aspects of the human notary processes are expected > to be automated through technology (through detailed use > cases), and then identify the current & anticipated risks to > each step of the revised processes and the environment, > before embarking on defining solutions. I think the scope of "Digital Notary Services" includes some processes that don't have an exact analogy with human notary processes. For example, mechanical time-stamping by tamper-resistant devices isn't a process that is easily described as an "aspect of the human notary processes". So while I agree with Arshad's stepwise approach, the range of possibilities is somewhat broader. I think we are looking at a range of network services that provide future assurances about current or past documents or events. >From this point of view, we can look at the "human notary processes" for inspiration, but not necessarily as the driver of requirements. Proposed revised Abstract: This document establishes the scope and requirements for protocol development in the area of 'digital notary services': network services that provide future assurances about current or past documents or events. The term 'notary service' is used by analogy with the wide range of services offered by human notaries for paper-based processes. The document discusses the historical context of notary services, defines terms, includes use cases and scenarios, and establishes technical requirements for network protocols for communication with network elements providing related services. We were hoping to get some information from the OASIS LegalXML group... does anyone have any news on that, or on the liaison request? Larry ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- From owner-ietf-ltans Thu Sep 23 00:35:14 2004 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 i8N7ZEBB086831; Thu, 23 Sep 2004 00:35:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8N7ZEuo086830; Thu, 23 Sep 2004 00:35:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N7Z7Ke086735 for ; Thu, 23 Sep 2004 00:35:12 -0700 (PDT) (envelope-from tobias@ixos.de) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i8N7Yx7T003008; Thu, 23 Sep 2004 09:35:00 +0200 (MEST) 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: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Date: Thu, 23 Sep 2004 09:34:59 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B0702C6645@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Thread-Index: AcSgFE3mJiX0asSISq2Eswgg+fIdpQArvGPg From: "Tobias Gondrom" To: Cc: "Carl Wallace" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8N7ZDKe086821 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello friends, the first document of our working group is coming to a final state. I asked Carl and the authors of the document to integrate the input of the last discussions inspired by Denis into the document so that we get to a final version. From my feeling the discussion here on the mailing-list has come to the time of conclusion about the requirements for long-term archive. Many discussions and ideas have been presented. For me it was very insightful and interesting to learn the different views and requirements from all over the world. We took our time for all the aspects, now I think we can move to a conclusion with this document so that we can lead our discussions concerning the Notary Services easier. I think that Carl, Ulrich and Ralf did a good job on this and hope that you agree. So I start the WG LAST CALL for our first WG document: "draft-ietf-ltans-reqs-02.txt" I declare WG Last Call (period 2 weeks) terminating at 7th October 2004 12:00 EST. Best regards Tobias Chair of LTANS Ps.: Small remark: Soon after completion of this Last Call I prepare to start the Last Call for the ERS document so that we can focus our work fully on the notary services problems at the 61st IETF meeting in November. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, September 21, 2004 9:39 PM > To: i-d-announce@ietf.org > Cc: ietf-ltans@imc.org > Subject: I-D ACTION:draft-ietf-ltans-reqs-02.txt > > 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 : Long term archive service requirements > Author(s) : C. Wallace, et al. > Filename : draft-ietf-ltans-reqs-02.txt > Pages : 17 > Date : 2004-9-21 > > In many scenarios, users need to be able to ensure and prove the > existence and integrity of data, especially digitally signed data, in > a common and reproducible way over a long and possibly undetermined > period of time. This document specifies the technical requirements > for a long-term archive service to support such scenarios. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-02.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-reqs-02.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-reqs-02.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. From owner-ietf-ltans Thu Sep 23 07:58:51 2004 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 i8NEwp2H081454; Thu, 23 Sep 2004 07:58:51 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8NEwpOB081453; Thu, 23 Sep 2004 07:58:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NEwmrB081429 for ; Thu, 23 Sep 2004 07:58:50 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0I4I003E90M06W@igw.noorhome.net> for ietf-ltans@imc.org; Thu, 23 Sep 2004 07:37:13 -0700 (PDT) Date: Thu, 23 Sep 2004 07:58:31 -0700 From: Arshad Noor Subject: Re: Notary services requirements -- directions? In-reply-to: <561F9357D239EB428AE3A4F14244431368CD88@Louise2> To: Richard Hansberger Cc: "'Larry Masinter'" , "'ietf-ltans@imc.org'" Message-id: <4152E497.2080508@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 References: <561F9357D239EB428AE3A4F14244431368CD88@Louise2> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Richard, Can you point me to specifc implementations of the "paperless electronic notarizations" - especially in the US? I'm interested in how this has been implemented, and am also curious if the implementations have defined the detailed use-case scenarios with the risk-assessments for current & anticipated risks. Thank you. Arshad Noor StrongAuth, Inc. Richard Hansberger wrote: > The simple > fact of the matter is that human Notaries in the states and abroad now > perform paperless electronic notarizations that fulfill the requirements of > notarial law, as well as offer time/date stamping services akin to what this > group is attempting to do (mostly through dig sig technology). From owner-ietf-ltans Mon Sep 27 03:31:25 2004 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 i8RAVPg9062995; Mon, 27 Sep 2004 03:31:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RAVPNl062994; Mon, 27 Sep 2004 03:31:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RAVNKf062910 for ; Mon, 27 Sep 2004 03:31:24 -0700 (PDT) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-aragorn [141.12.86.73]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id MAA10595; Mon, 27 Sep 2004 12:31:08 +0200 (MET DST) Message-ID: <4157EBEC.5010006@sit.fraunhofer.de> Date: Mon, 27 Sep 2004 12:31:08 +0200 From: "Andreas U. Schmidt" Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: notary service requirements: suggested replacement for use-case 3.3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, from the outset, I found the use-case 3.3 'certification of copy documents' rather misleading. First, the creation of copies, which are to fully replace the original seemed to me just a very special case of general document transformations, which need not be restricted to simple format conversions. Then the statement that 'transformation of one document format into another can be achieved' was also doubtful. Given the complexity of some data formats and the notorious 'what You see is what You sign' problem, I think that the transformation of documents is a general process in which a notary service can be at best a helpful tool, and not a single instance which is 'able to attest that one document contains the same information as another ... ' I therefore propose to change use case 3.3 as follows: 3.3 certification of transformed documents If a party wants to transform a signed document into a target document, a notary service can issue a signed transformation seal asserting that a transformation has been correctly performed and thereby ensuring the validity of the target document. For this, the service needs to be provided with all necessary information on original and target document, signatures and transformation, and in some cases the application context. The meaning of the term 'validity' of the target document depends its desired application domain, an important example being a) its legal validity as a replacement of the original. In this case, the goal of the transformation is that the target document is held legally valid in all situations in which the original was. Further examples: b) conversion from a data format that has become obsolete (migration); c) corrections and amendments in legal documents, e.g., contracts; d) deletion of certain data within a document for reasons of data protection or secrecy (e.g., patient names in medical records that are to be processed by a third party). In many cases, due to the complexity of real-world transformations, the task of the notary service may consist solely in compiling and applying the transfomration seal to the target document. 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 i8RAVPg9062995; Mon, 27 Sep 2004 03:31:25 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8RAVPNl062994; Mon, 27 Sep 2004 03:31:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8RAVNKf062910 for ; Mon, 27 Sep 2004 03:31:24 -0700 (PDT) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-aragorn [141.12.86.73]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id MAA10595; Mon, 27 Sep 2004 12:31:08 +0200 (MET DST) Message-ID: <4157EBEC.5010006@sit.fraunhofer.de> Date: Mon, 27 Sep 2004 12:31:08 +0200 From: "Andreas U. Schmidt" Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: notary service requirements: suggested replacement for use-case 3.3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All, from the outset, I found the use-case 3.3 'certification of copy documents' rather misleading. First, the creation of copies, which are to fully replace the original seemed to me just a very special case of general document transformations, which need not be restricted to simple format conversions. Then the statement that 'transformation of one document format into another can be achieved' was also doubtful. Given the complexity of some data formats and the notorious 'what You see is what You sign' problem, I think that the transformation of documents is a general process in which a notary service can be at best a helpful tool, and not a single instance which is 'able to attest that one document contains the same information as another ... ' I therefore propose to change use case 3.3 as follows: 3.3 certification of transformed documents If a party wants to transform a signed document into a target document, a notary service can issue a signed transformation seal asserting that a transformation has been correctly performed and thereby ensuring the validity of the target document. For this, the service needs to be provided with all necessary information on original and target document, signatures and transformation, and in some cases the application context. The meaning of the term 'validity' of the target document depends its desired application domain, an important example being a) its legal validity as a replacement of the original. In this case, the goal of the transformation is that the target document is held legally valid in all situations in which the original was. Further examples: b) conversion from a data format that has become obsolete (migration); c) corrections and amendments in legal documents, e.g., contracts; d) deletion of certain data within a document for reasons of data protection or secrecy (e.g., patient names in medical records that are to be processed by a third party). In many cases, due to the complexity of real-world transformations, the task of the notary service may consist solely in compiling and applying the transfomration seal to the target document. 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 i8NEwp2H081454; Thu, 23 Sep 2004 07:58:51 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8NEwpOB081453; Thu, 23 Sep 2004 07:58:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8NEwmrB081429 for ; Thu, 23 Sep 2004 07:58:50 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from strongauth.com (athena.noorhome.net [192.168.0.10]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0I4I003E90M06W@igw.noorhome.net> for ietf-ltans@imc.org; Thu, 23 Sep 2004 07:37:13 -0700 (PDT) Date: Thu, 23 Sep 2004 07:58:31 -0700 From: Arshad Noor Subject: Re: Notary services requirements -- directions? In-reply-to: <561F9357D239EB428AE3A4F14244431368CD88@Louise2> To: Richard Hansberger Cc: "'Larry Masinter'" , "'ietf-ltans@imc.org'" Message-id: <4152E497.2080508@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 References: <561F9357D239EB428AE3A4F14244431368CD88@Louise2> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Richard, Can you point me to specifc implementations of the "paperless electronic notarizations" - especially in the US? I'm interested in how this has been implemented, and am also curious if the implementations have defined the detailed use-case scenarios with the risk-assessments for current & anticipated risks. Thank you. Arshad Noor StrongAuth, Inc. Richard Hansberger wrote: > The simple > fact of the matter is that human Notaries in the states and abroad now > perform paperless electronic notarizations that fulfill the requirements of > notarial law, as well as offer time/date stamping services akin to what this > group is attempting to do (mostly through dig sig technology). 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 i8N7ZEBB086831; Thu, 23 Sep 2004 00:35:14 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8N7ZEuo086830; Thu, 23 Sep 2004 00:35:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.31.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8N7Z7Ke086735 for ; Thu, 23 Sep 2004 00:35:12 -0700 (PDT) (envelope-from tobias@ixos.de) Received: from MUCXGC1.opentext.net (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.9/8.12.9) with ESMTP id i8N7Yx7T003008; Thu, 23 Sep 2004 09:35:00 +0200 (MEST) 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: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Date: Thu, 23 Sep 2004 09:34:59 +0200 Message-ID: <3C1BE8610E44734499EF92FB35F5B0702C6645@MUCXGC1.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG LAST CALL: draft-ietf-ltans-reqs-02.txt Thread-Index: AcSgFE3mJiX0asSISq2Eswgg+fIdpQArvGPg From: "Tobias Gondrom" To: Cc: "Carl Wallace" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8N7ZDKe086821 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello friends, the first document of our working group is coming to a final state. I asked Carl and the authors of the document to integrate the input of the last discussions inspired by Denis into the document so that we get to a final version. From my feeling the discussion here on the mailing-list has come to the time of conclusion about the requirements for long-term archive. Many discussions and ideas have been presented. For me it was very insightful and interesting to learn the different views and requirements from all over the world. We took our time for all the aspects, now I think we can move to a conclusion with this document so that we can lead our discussions concerning the Notary Services easier. I think that Carl, Ulrich and Ralf did a good job on this and hope that you agree. So I start the WG LAST CALL for our first WG document: "draft-ietf-ltans-reqs-02.txt" I declare WG Last Call (period 2 weeks) terminating at 7th October 2004 12:00 EST. Best regards Tobias Chair of LTANS Ps.: Small remark: Soon after completion of this Last Call I prepare to start the Last Call for the ERS document so that we can focus our work fully on the notary services problems at the 61st IETF meeting in November. > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, September 21, 2004 9:39 PM > To: i-d-announce@ietf.org > Cc: ietf-ltans@imc.org > Subject: I-D ACTION:draft-ietf-ltans-reqs-02.txt > > 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 : Long term archive service requirements > Author(s) : C. Wallace, et al. > Filename : draft-ietf-ltans-reqs-02.txt > Pages : 17 > Date : 2004-9-21 > > In many scenarios, users need to be able to ensure and prove the > existence and integrity of data, especially digitally signed data, in > a common and reproducible way over a long and possibly undetermined > period of time. This document specifies the technical requirements > for a long-term archive service to support such scenarios. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-02.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-reqs-02.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-reqs-02.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. 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 i8MNYf2A098692; Wed, 22 Sep 2004 16:34:41 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8MNYfD0098691; Wed, 22 Sep 2004 16:34:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8MNYdwx098681 for ; Wed, 22 Sep 2004 16:34:40 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W8N01TC0000004B8; Wed, 22 Sep 2004 16:29:48 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id ; Wed, 22 Sep 2004 16:31:07 -0800 Message-ID: <561F9357D239EB428AE3A4F14244431368CD88@Louise2> From: Richard Hansberger To: "'Larry Masinter'" , "'ietf-ltans@imc.org'" Subject: RE: RE: Notary services requirements -- directions? Date: Wed, 22 Sep 2004 16:30:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: 1732cbf026a2ed1a54fe104183c420fe Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain Larry, I am a member of the OASIS LegalXML group. I can introduce a liaison from this group to the chair, John Messing, directly. I would humbly suggest that you revise the abstract as below. The simple fact of the matter is that human Notaries in the states and abroad now perform paperless electronic notarizations that fulfill the requirements of notarial law, as well as offer time/date stamping services akin to what this group is attempting to do (mostly through dig sig technology). Human Notaries simply provide other assurances that the "digital Notary services" do not; however, I fully expect to embrace the work product of this group to extend the work we do even further. Proposed revised Abstract (IN CAPS): This document establishes the scope and requirements for protocol development in the area of 'digital notary services': network services that provide future assurances about current or past documents or events. The term 'notary service' is used by analogy with the wide range of services offered by human notaries for ELECTRONIC OR PAPER-BASED processes. The document discusses the historical context of notary services, defines terms, includes use cases and scenarios, and establishes technical requirements for network protocols for communication with network elements providing related services. Richard J. Hansberger Director of eNotarization National Notary Association 818-739-4027 -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Sunday, September 19, 2004 9:03 PM To: ietf-ltans@imc.org Subject: RE: RE: Notary services requirements -- directions? I'm looking at the task of updating the Notary Services Requirement document, and I'm still not sure about what direction the working group wants to take. Arshad Noor wrote: > I would recommend that the WG first describe, specifically, > which aspects of the human notary processes are expected > to be automated through technology (through detailed use > cases), and then identify the current & anticipated risks to > each step of the revised processes and the environment, > before embarking on defining solutions. I think the scope of "Digital Notary Services" includes some processes that don't have an exact analogy with human notary processes. For example, mechanical time-stamping by tamper-resistant devices isn't a process that is easily described as an "aspect of the human notary processes". So while I agree with Arshad's stepwise approach, the range of possibilities is somewhat broader. I think we are looking at a range of network services that provide future assurances about current or past documents or events. >From this point of view, we can look at the "human notary processes" for inspiration, but not necessarily as the driver of requirements. Proposed revised Abstract: This document establishes the scope and requirements for protocol development in the area of 'digital notary services': network services that provide future assurances about current or past documents or events. The term 'notary service' is used by analogy with the wide range of services offered by human notaries for paper-based processes. The document discusses the historical context of notary services, defines terms, includes use cases and scenarios, and establishes technical requirements for network protocols for communication with network elements providing related services. We were hoping to get some information from the OASIS LegalXML group... does anyone have any news on that, or on the liaison request? Larry ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- 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 i8LJd4FV064740; Tue, 21 Sep 2004 12:39:04 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8LJd4dw064739; Tue, 21 Sep 2004 12:39:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8LJd1Ac064731 for ; Tue, 21 Sep 2004 12:39:02 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14208; Tue, 21 Sep 2004 15:39:03 -0400 (EDT) Message-Id: <200409211939.PAA14208@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ltans-reqs-02.txt Date: Tue, 21 Sep 2004 15:39:03 -0400 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 : Long term archive service requirements Author(s) : C. Wallace, et al. Filename : draft-ietf-ltans-reqs-02.txt Pages : 17 Date : 2004-9-21 In many scenarios, users need to be able to ensure and prove the existence and integrity of data, especially digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the technical requirements for a long-term archive service to support such scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-reqs-02.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-reqs-02.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-reqs-02.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: <2004-9-21153213.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-reqs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-reqs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-21153213.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 i8K52dSI041260; Sun, 19 Sep 2004 22:02:39 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8K52dfx041259; Sun, 19 Sep 2004 22:02:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [12.158.35.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i8K52ac8041233 for ; Sun, 19 Sep 2004 22:02:38 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob4.obsmtp.com ([12.158.35.250]) with SMTP; Sun, 19 Sep 2004 22:02:43 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i8K52hNf011363 for ; Sun, 19 Sep 2004 22:02:43 -0700 (PDT) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i8K52bks012655 for ; Sun, 19 Sep 2004 22:02:43 -0700 (PDT) Received: from MasinterT40 ([130.248.179.4]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I4B000GAQ0DOM@mailsj-v1.corp.adobe.com> for ietf-ltans@imc.org; Sun, 19 Sep 2004 22:02:37 -0700 (PDT) Date: Sun, 19 Sep 2004 22:02:38 -0700 From: Larry Masinter Subject: RE: RE: Notary services requirements -- directions? In-reply-to: <73d390e0.90e073d3@noorhome.net> To: ietf-ltans@imc.org Message-id: <0I4B000GCQ0DOM@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSWfvOWwfxQ0iQbTj2BUeHCqU1JfwITM8kg Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm looking at the task of updating the Notary Services Requirement document, and I'm still not sure about what direction the working group wants to take. Arshad Noor wrote: > I would recommend that the WG first describe, specifically, > which aspects of the human notary processes are expected > to be automated through technology (through detailed use > cases), and then identify the current & anticipated risks to > each step of the revised processes and the environment, > before embarking on defining solutions. I think the scope of "Digital Notary Services" includes some processes that don't have an exact analogy with human notary processes. For example, mechanical time-stamping by tamper-resistant devices isn't a process that is easily described as an "aspect of the human notary processes". So while I agree with Arshad's stepwise approach, the range of possibilities is somewhat broader. I think we are looking at a range of network services that provide future assurances about current or past documents or events. >From this point of view, we can look at the "human notary processes" for inspiration, but not necessarily as the driver of requirements. Proposed revised Abstract: This document establishes the scope and requirements for protocol development in the area of 'digital notary services': network services that provide future assurances about current or past documents or events. The term 'notary service' is used by analogy with the wide range of services offered by human notaries for paper-based processes. The document discusses the historical context of notary services, defines terms, includes use cases and scenarios, and establishes technical requirements for network protocols for communication with network elements providing related services. We were hoping to get some information from the OASIS LegalXML group... does anyone have any news on that, or on the liaison request? Larry 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 i8GCJadf030700; Thu, 16 Sep 2004 05:19:36 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i8GCJa2q030699; Thu, 16 Sep 2004 05:19:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i8GCJYu1030684 for ; Thu, 16 Sep 2004 05:19:35 -0700 (PDT) (envelope-from Andreas.U.Schmidt@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-aragorn [141.12.86.73]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id OAA28337; Thu, 16 Sep 2004 14:19:21 +0200 (MET DST) Message-ID: <414984C8.3000203@sit.fraunhofer.de> Date: Thu, 16 Sep 2004 14:19:20 +0200 From: "Andreas U. Schmidt" Reply-To: Andreas.U.Schmidt@sit.fraunhofer.de User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Use case administering of oaths Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In view of the information provided by Richard Hansberger and the corresponding information that I obtained from German notaries public and which is in full accordance to that, I would like to have the parenthesis (maybe even virtually) be replaced by (note that many jurisdictions at present require the personal presence of the person delivering the oath with the notary, thus oaths cannot be delivered 'virtually') Though I agree with Larry that long explanations of the duties of human notaries, followed by a shrugging remark that they are invalid for notary services are to be avoided, I still think this is a singularly important clarification. AUS 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 i89EifZ3051786; Thu, 9 Sep 2004 07:44:41 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i89EifFo051785; Thu, 9 Sep 2004 07:44:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i89Eiedq051757 for ; Thu, 9 Sep 2004 07:44:40 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from noorhome.net (localhost [127.0.0.1]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0I3S008FU2NBQV@igw.noorhome.net> for ietf-ltans@imc.org; Thu, 09 Sep 2004 07:23:36 -0700 (PDT) Received: from [12.18.36.40] by igw.noorhome.net (mshttpd); Thu, 09 Sep 2004 10:23:35 -0400 Date: Thu, 09 Sep 2004 10:23:35 -0400 From: Arshad Noor Subject: Re: RE: Notary services requirements -- directions? To: ietf-ltans@imc.org Message-id: <73d390e0.90e073d3@noorhome.net> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 Patch 1 (built Aug 19 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In re-reading the Description of the Working Group for LTANS, I now sense that it has two very different objectives - one which is reasonable and the other, which may be premature. The goal of arriving at protocols, structures and mechanisms for archiving and validating digitally signed documents over very long periods is the reasonable goal, since it addresses purely technical issues. The goal of having such technology replace existing legal practices, however small, without documenting all potential risks, is dangerous. I would recommend that the WG first describe, specifically, which aspects of the human notary processes are expected to be automated through technology (through detailed use cases), and then identify the current & anticipated risks to each step of the revised processes and the environment, before embarking on defining solutions. Arshad Noor StrongAuth, Inc. ----- Original Message ----- From: Santosh Chokhani Date: Wednesday, September 8, 2004 10:36 pm Subject: RE: Notary services requirements -- directions? > > I thought that the electronic notary will replace some of the > human notary > services. > > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf- > ltans@mail.imc.org]On Behalf Of Richard Hansberger > Sent: Wednesday, September 08, 2004 9:21 PM > To: 'Larry Masinter'; ietf-ltans@imc.org > Subject: RE: Notary services requirements -- directions? > > > Larry, > > In answer to your first question, we've always understood the term > "NotaryService" to be a technology that Notaries could use, not a > technology that > others can use in lieu of notarization. If that means the name of the > service needs to change, I'll leave that decision in more capable > hands. > In answer to your second question, I probably just gave more > informationthat is relevant to the work product at hand. > > I guess the primary question would be: What is the purpose of a > "NotaryService"? Is it what I understand it to be (a technology > used by a Notary), > or is it intended to be a technology that performs "notarization" > per se? > > If I understand the answer, I'll filter out unnecessary information. > > Thanks, > Rich Hansberger > Director of eNotarization > National Notary Association > rhansberger@nationalnotary.org > > -----Original Message----- > From: Larry Masinter [mailto:LMM@acm.org] > Sent: Wednesday, September 08, 2004 1:37 PM > To: 'Richard Hansberger'; ietf-ltans@imc.org > Subject: Notary services requirements -- directions? > > > > Many state laws mandate that Notaries may NOT notarize documents > with"blank > > or incomplete" spaces. Notaries are expected to review documents > carefully, > > though not to interpret them for signers. In every case and in every > state, > > the signer MUST appear before the Notary. Physical presence of the > > signer before the Notary is almost the entire premise of > notarization. > This is interesting information, but I'm not sure how it would > affect the > document on notary service requirements. Is it proposed that the > fact that > "Notaries" do these services should affect what we are calling a > "NotaryService" in LTANS? > > > Acknowledgments and jurats are only two types of notarial acts. > There> are > at > > least 7 others (off the top of my head). What is common to them > all is > > a notarial certificate that contains wording indicating the act > > performed. > By > > far, however, acknowledgments and jurats comprise the bulk of what > Notaries > > do on a daily basis. > > > > California actually does have provisions for electronic notarization > > (we > are > > running pilots right now), and three other states do as well: > CO, AZ, > > PA. > > I think that we can mainly hope to create a standard interface for > thoseacts that are feasible for "electronic notarization", and > that a review of > the electronic notarization pilots would be a good place to start. > > Personally, I would rather not have a long document explaining in > detailwhat real Notaries do, and then point out that most of those > things (like > verifying physical identity and reading and understanding the document > content) aren't in scope for LTANS. > > Larry > > 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 i892aiWJ027856; Wed, 8 Sep 2004 19:36:44 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i892aidA027855; Wed, 8 Sep 2004 19:36:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i892ai6i027849 for ; Wed, 8 Sep 2004 19:36:44 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i892aoqa002185 for ; Wed, 8 Sep 2004 22:36:50 -0400 From: "Santosh Chokhani" To: Subject: RE: Notary services requirements -- directions? Date: Wed, 8 Sep 2004 22:36:44 -0400 Message-ID: <003701c49615$dbbeca10$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <561F9357D239EB428AE3A4F1424443130165F6@Louise2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I thought that the electronic notary will replace some of the human notary services. -----Original Message----- From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Richard Hansberger Sent: Wednesday, September 08, 2004 9:21 PM To: 'Larry Masinter'; ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? Larry, In answer to your first question, we've always understood the term "Notary Service" to be a technology that Notaries could use, not a technology that others can use in lieu of notarization. If that means the name of the service needs to change, I'll leave that decision in more capable hands. In answer to your second question, I probably just gave more information that is relevant to the work product at hand. I guess the primary question would be: What is the purpose of a "Notary Service"? Is it what I understand it to be (a technology used by a Notary), or is it intended to be a technology that performs "notarization" per se? If I understand the answer, I'll filter out unnecessary information. Thanks, Rich Hansberger Director of eNotarization National Notary Association rhansberger@nationalnotary.org -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Wednesday, September 08, 2004 1:37 PM To: 'Richard Hansberger'; ietf-ltans@imc.org Subject: Notary services requirements -- directions? > Many state laws mandate that Notaries may NOT notarize documents with "blank > or incomplete" spaces. Notaries are expected to review documents carefully, > though not to interpret them for signers. In every case and in every state, > the signer MUST appear before the Notary. Physical presence of the > signer before the Notary is almost the entire premise of notarization. This is interesting information, but I'm not sure how it would affect the document on notary service requirements. Is it proposed that the fact that "Notaries" do these services should affect what we are calling a "Notary Service" in LTANS? > Acknowledgments and jurats are only two types of notarial acts. There > are at > least 7 others (off the top of my head). What is common to them all is > a notarial certificate that contains wording indicating the act > performed. By > far, however, acknowledgments and jurats comprise the bulk of what Notaries > do on a daily basis. > > California actually does have provisions for electronic notarization > (we are > running pilots right now), and three other states do as well: CO, AZ, > PA. I think that we can mainly hope to create a standard interface for those acts that are feasible for "electronic notarization", and that a review of the electronic notarization pilots would be a good place to start. Personally, I would rather not have a long document explaining in detail what real Notaries do, and then point out that most of those things (like verifying physical identity and reading and understanding the document content) aren't in scope for LTANS. Larry 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 i890OZX6017172; Wed, 8 Sep 2004 17:24:35 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i890OZah017171; Wed, 8 Sep 2004 17:24:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from MessageInpector.nationalnotary.org (mail.nationalnotary.org [65.115.114.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i890OYg3017105 for ; Wed, 8 Sep 2004 17:24:34 -0700 (PDT) (envelope-from rhansberger@nationalnotary.org) Received: from louise2.nationalnotary.org (LOUISE2 [192.168.1.247]) by MessageInpector.nationalnotary.org (Switch-2.2.8/Switch-2.2.4) with ESMTP id W8911KN500000884; Wed, 08 Sep 2004 17:20:59 -0800 Received: by Louise2 with Internet Mail Service (5.5.2657.72) id ; Wed, 8 Sep 2004 17:21:18 -0800 Message-ID: <561F9357D239EB428AE3A4F1424443130165F6@Louise2> From: Richard Hansberger To: "'Larry Masinter'" , ietf-ltans@imc.org Subject: RE: Notary services requirements -- directions? Date: Wed, 8 Sep 2004 17:21:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="--123456789-987654321-abcdefg" X-MessageInspectorSig: 010325bcec8ba57ba1ddcf5cf9db93c2 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----123456789-987654321-abcdefg Content-Type: text/plain Larry, In answer to your first question, we've always understood the term "Notary Service" to be a technology that Notaries could use, not a technology that others can use in lieu of notarization. If that means the name of the service needs to change, I'll leave that decision in more capable hands. In answer to your second question, I probably just gave more information that is relevant to the work product at hand. I guess the primary question would be: What is the purpose of a "Notary Service"? Is it what I understand it to be (a technology used by a Notary), or is it intended to be a technology that performs "notarization" per se? If I understand the answer, I'll filter out unnecessary information. Thanks, Rich Hansberger Director of eNotarization National Notary Association rhansberger@nationalnotary.org -----Original Message----- From: Larry Masinter [mailto:LMM@acm.org] Sent: Wednesday, September 08, 2004 1:37 PM To: 'Richard Hansberger'; ietf-ltans@imc.org Subject: Notary services requirements -- directions? > Many state laws mandate that Notaries may NOT notarize documents with "blank > or incomplete" spaces. Notaries are expected to review documents carefully, > though not to interpret them for signers. In every case and in every state, > the signer MUST appear before the Notary. Physical presence of the signer > before the Notary is almost the entire premise of notarization. This is interesting information, but I'm not sure how it would affect the document on notary service requirements. Is it proposed that the fact that "Notaries" do these services should affect what we are calling a "Notary Service" in LTANS? > Acknowledgments and jurats are only two types of notarial acts. There are at > least 7 others (off the top of my head). What is common to them all is a > notarial certificate that contains wording indicating the act performed. By > far, however, acknowledgments and jurats comprise the bulk of what Notaries > do on a daily basis. > > California actually does have provisions for electronic notarization (we are > running pilots right now), and three other states do as well: > CO, AZ, PA. I think that we can mainly hope to create a standard interface for those acts that are feasible for "electronic notarization", and that a review of the electronic notarization pilots would be a good place to start. Personally, I would rather not have a long document explaining in detail what real Notaries do, and then point out that most of those things (like verifying physical identity and reading and understanding the document content) aren't in scope for LTANS. Larry ----123456789-987654321-abcdefg Content-Type: text/plain Content-Disposition: inline This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately. ----123456789-987654321-abcdefg-- 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 i88KbOnw097954; Wed, 8 Sep 2004 13:37:24 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88KbOZn097953; Wed, 8 Sep 2004 13:37:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob3.obsmtp.com [12.158.35.213]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88KbN8p097946 for ; Wed, 8 Sep 2004 13:37:23 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.7]) by exprod6ob3.obsmtp.com ([12.158.35.250]) with SMTP; Wed, 08 Sep 2004 13:37:27 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-7.sea.adobe.com (8.12.10/8.12.10) with ESMTP id i88KbRNf008329; Wed, 8 Sep 2004 13:37:27 -0700 (PDT) Received: from mailsj-dev (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i88KbRkq026561; Wed, 8 Sep 2004 13:37:27 -0700 (PDT) Received: from MasinterT40 (c-131-136.corp.adobe.com [153.32.131.136]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3Q008YPPAEV7@mailsj-v1.corp.adobe.com>; Wed, 08 Sep 2004 13:37:27 -0700 (PDT) Date: Wed, 08 Sep 2004 13:37:26 -0700 From: Larry Masinter Subject: Notary services requirements -- directions? In-reply-to: <561F9357D239EB428AE3A4F14244431303946C@Louise2> To: "'Richard Hansberger'" , ietf-ltans@imc.org Message-id: <0I3Q008YQPAEV7@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSKuByANBgH4cTvRo26zpmmh8oZfQLKsAvQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Many state laws mandate that Notaries may NOT notarize documents with "blank > or incomplete" spaces. Notaries are expected to review documents carefully, > though not to interpret them for signers. In every case and in every state, > the signer MUST appear before the Notary. Physical presence of the signer > before the Notary is almost the entire premise of notarization. This is interesting information, but I'm not sure how it would affect the document on notary service requirements. Is it proposed that the fact that "Notaries" do these services should affect what we are calling a "Notary Service" in LTANS? > Acknowledgments and jurats are only two types of notarial acts. There are at > least 7 others (off the top of my head). What is common to them all is a > notarial certificate that contains wording indicating the act performed. By > far, however, acknowledgments and jurats comprise the bulk of what Notaries > do on a daily basis. > > California actually does have provisions for electronic notarization (we are > running pilots right now), and three other states do as well: > CO, AZ, PA. I think that we can mainly hope to create a standard interface for those acts that are feasible for "electronic notarization", and that a review of the electronic notarization pilots would be a good place to start. Personally, I would rather not have a long document explaining in detail what real Notaries do, and then point out that most of those things (like verifying physical identity and reading and understanding the document content) aren't in scope for LTANS. Larry 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 i88KUvwi097459; Wed, 8 Sep 2004 13:30:57 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i88KUvR7097458; Wed, 8 Sep 2004 13:30:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from psmtp.com (exprod6ob4.obsmtp.com [12.158.35.214]) by above.proper.com (8.12.11/8.12.9) with SMTP id i88KUs2P097450 for ; Wed, 8 Sep 2004 13:30:55 -0700 (PDT) (envelope-from LMM@acm.org) Received: from source ([192.150.22.8]) by exprod6ob4.obsmtp.com ([12.158.35.250]) with SMTP; Wed, 08 Sep 2004 13:30:59 PDT Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-8.adobe.com (8.12.10/8.12.10) with ESMTP id i88KUXbA017900; Wed, 8 Sep 2004 13:30:43 -0700 (PDT) Received: from mailsj-dev (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-3.corp.adobe.com (8.12.9/8.12.9) with ESMTP id i88KUNkq025026; Wed, 8 Sep 2004 13:30:33 -0700 (PDT) Received: from MasinterT40 (c-131-136.corp.adobe.com [153.32.131.136]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3Q008PSOYMV7@mailsj-v1.corp.adobe.com>; Wed, 08 Sep 2004 13:30:22 -0700 (PDT) Date: Wed, 08 Sep 2004 13:30:22 -0700 From: Larry Masinter Subject: RE: Notary services: Additional use-cases In-reply-to: <413EC58F.90604@sit.fraunhofer.de> To: "'Thomas Kunz'" , ietf-ltans@imc.org Message-id: <0I3Q008PUOYMV7@mailsj-v1.corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcSVgmcG7QwO0HvEQc67zBJO1BINeAAX+pNA Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Rectification of false statements: > > One service can be the rectification, the supplementation, or the > cancellation of some parts of the original document on demand of the > document's owner. > In a similar use-case the service can obliterate confidential parts > (e.g. names of involved persons) in copy documents in order to publish > it. > Both use-cases can be understood as special kinds of transformations. > In particular in the first use-case the service has to document the > rectifications. I'm not sure I understand this suggestion... is this something that some notaries perform in some jurisdictions? I know there are some general categories of document processing services that are performed by different organizations, but I don't know where the working group wants to draw the boundary. 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 i888eAWw090713; Wed, 8 Sep 2004 01:40:10 -0700 (PDT) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i888eAUR090712; Wed, 8 Sep 2004 01:40:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from sonne.sit.fraunhofer.de (sonne.sit.fraunhofer.de [141.12.62.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i888e8j2090622 for ; Wed, 8 Sep 2004 01:40:09 -0700 (PDT) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from sit.fraunhofer.de (pc-maranello [141.12.87.97]) by sonne.sit.fraunhofer.de (8.8.8/8.8.5) with ESMTP id KAA28100 for ; Wed, 8 Sep 2004 10:39:52 +0200 (MET DST) Message-ID: <413EC58F.90604@sit.fraunhofer.de> Date: Wed, 08 Sep 2004 10:40:47 +0200 From: Thomas Kunz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ltans@imc.org Subject: Notary services: Additional use-cases Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020108060202080203030402" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020108060202080203030402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, in addition to the use-cases already described in the notary services requirements, we would like to present some further use-cases. Rectification of false statements: One service can be the rectification, the supplementation, or the cancellation of some parts of the original document on demand of the document's owner. In a similar use-case the service can obliterate confidential parts (e.g. names of involved persons) in copy documents in order to publish it. Both use-cases can be understood as special kinds of transformations. In particular in the first use-case the service has to document the rectifications. Best regards, Thomas ------------------------------------------------------------ Dipl. Inf. Thomas Kunz Fraunhofer - Institut für Sichere Telekooperation (FhG-SIT) Dolivostrasse 15 D-64293 Darmstadt (Germany) Tel: +49-6151-869-60204 ------------------------------------------------------------ e-mail: thomas.kunz@sit.fraunhofer.de http://www.sit.fraunhofer.de ------------------------------------------------------------ --------------ms020108060202080203030402 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 CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA5MDgwODQwNDdaMCMGCSqGSIb3 DQEJBDEWBBRXWj87VqYffQvKCfcmWXmKPSLlqTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBADYkEqfk2LIXQDZKR6jz11JhLIF0HX68zuMTsxfmWJac38mZxL0cH/bf bm+CUcDGMWGkZRnajFwdLJ69QVi0LFfZ9LnsyQyC8kc9OjvR3NTzduFO2+dY0ZLZULPqVihs uJ5BjJEC8dBrVUHPv+3G96g38fh+HAFOy0iHI+DawacVerPkeV4sN7s4xt8pit+avDWhiBUH uaxJoFhWUb5+pBWueFo4AKy82V21kp/aw9AgZX9hzKvbDG0aTGSl6HsabxCpAm62x6DlOtlW NovX03sL+Kzo/hUk/9yDL6vn1mEgiN9BLybfxMrWU2TaIm4MCNVJRz64yoAoTV9pOewh85oA AAAAAAA= --------------ms020108060202080203030402--