From root@core3.amsl.com Tue Sep 15 07:00:01 2009 Return-Path: X-Original-To: ltans@ietf.org Delivered-To: ltans@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B763C3A6966; Tue, 15 Sep 2009 07:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090915140001.B763C3A6966@core3.amsl.com> Date: Tue, 15 Sep 2009 07:00:01 -0700 (PDT) X-Mailman-Approved-At: Tue, 15 Sep 2009 07:02:34 -0700 Cc: ltans@ietf.org Subject: [ltans] I-D Action:draft-ietf-ltans-dssc-11.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 14:00:01 -0000 --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 : Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-11.txt Pages : 48 Date : 2009-09-15 Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time which may be in the past, at the present time or in the future.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ltans-dssc-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-15065404.I-D@ietf.org> --NextPart-- From tglassey@earthlink.net Tue Sep 15 08:16:30 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFE913A688B for ; Tue, 15 Sep 2009 08:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=0.827, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6erT0p03+yhi for ; Tue, 15 Sep 2009 08:16:29 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CA1C83A6A48 for ; Tue, 15 Sep 2009 08:16:29 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FFH6bQ002487 for ; Tue, 15 Sep 2009 08:17:16 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=R6ue148j6kgRYn9/ALa8kDC7ma4Dxssr+bniaa8Du7po5gxaogY4bgQ04Ow4QXGW; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MnZmB-0003H5-Sh for ietf-ltans@imc.org; Tue, 15 Sep 2009 11:17:03 -0400 Message-ID: <4AAFAFEE.9090201@earthlink.net> Date: Tue, 15 Sep 2009 08:17:02 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ietf-ltans@imc.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79e5aa3e32663fdf1cec509c5b4fae26be350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 Subject: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 15:16:30 -0000 Folks - I want to propose a new term for describing certain relationships in a network model. The term is "Proof Source Provider" or PSP and it means some service which is providing a trust-anchor for some other process or the like. The PSP is the party or system which provides the oversight and process control for an TRUST-ANCHOR - the component of the trust element which ties the specific content to that trust element. The Term Trust Anchor (now widely in use in Secure DNS) was coined in PKIX several years ago but is critically valuable now in other areas and we should embrace both it and the idea of the Proof Source Provider and the Proof Source they use to cerate admissibility for the evidence. It (PSP) pertains then to auditing trust relationships and their ability to convey policy and control over a larger methodology and is a key part of relational trust models which are propagated across multiple technologies and would be used in LTANS Security and other key processes. Why this is important is that systems and processes which we would build from these technologies would also perform functions in the real world which would have legal implications and so the ability to represent trust-anchor processes in the records created would admissible in global courts. This nomenclature provides a resource for this and other uses. Todd Glassey From brussell@pericore.com Tue Sep 15 08:28:41 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F55C3A6A47 for ; Tue, 15 Sep 2009 08:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.893 X-Spam-Level: X-Spam-Status: No, score=-3.893 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMgyb7F-rTUy for ; Tue, 15 Sep 2009 08:28:40 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id DEF113A6976 for ; Tue, 15 Sep 2009 08:28:36 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FFTCWV003804 for ; Tue, 15 Sep 2009 08:29:23 -0700 (MST) (envelope-from brussell@pericore.com) Received: from BH001.mail.lan ([10.110.21.101]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 11:29:11 -0400 Received: from HUB010.mail.lan ([10.110.17.10]) by BH001.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 11:29:10 -0400 Received: from HUB014.mail.lan (10.110.17.14) by HUB010.mail.lan (10.110.17.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 15 Sep 2009 11:29:10 -0400 Received: from MAILR003.mail.lan ([10.110.18.20]) by HUB014.mail.lan ([10.110.17.14]) with mapi; Tue, 15 Sep 2009 11:29:09 -0400 From: Bill Russell To: Todd Glassey , "ietf-ltans@imc.org" Date: Tue, 15 Sep 2009 11:28:18 -0400 Thread-Topic: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies Thread-Index: Aco2GUT70hCyaDTSTWCXJVyouNjoZA== Message-ID: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 15 Sep 2009 15:29:10.0072 (UTC) FILETIME=[4572E380:01CA3619] X-Mailman-Approved-At: Tue, 15 Sep 2009 08:34:13 -0700 Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 15:28:41 -0000 V2UgKFBlcmljb3JlKSBhbHJlYWR5IHVzZSB0aGF0IHRlcm0gdG8gZXhwcmVzcyBkaWdpdGFsbHkg c2lnbmVkIGF1dGhvcml6YXRpb25zLiBBbHNvLCBDb3Jlc3RyZWV0IHVzZXMgdGhhdCB0ZXJtIGlu IG9uZSBvZiB0aGVpciBwcm9kdWN0cy4gSSB0aGluayB0aGUgdGVybSBpcyBvdmVybG9hZGVkIGFu ZCBzaG91bGQgbm90IGJlIHVzZWQgYXMgeW91IHByb3Bvc2UuDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiAiVG9kZCBHbGFzc2V5IiA8dGdsYXNzZXlAZWFydGhsaW5rLm5ldD4N ClRvOiAiaWV0Zi1sdGFuc0BpbWMub3JnIiA8aWV0Zi1sdGFuc0BpbWMub3JnPg0KU2VudDogOS8x NS8wOSAxMToxNyBBTQ0KU3ViamVjdDogW2x0YW5zXSAiUHJvb2YgU291cmNlIFByb3ZpZGVyIiAt IG5ldyB0ZXJtIGZvciB1c2UgaW4gZGVzY3JpYmluZyB0cnVzdCBjaGFpbnMgaW4gZG9jdW1lbnQg aGllcmFyY2hpZXMNCg0KRm9sa3MgLQ0KSSB3YW50IHRvIHByb3Bvc2UgYSBuZXcgdGVybSBmb3Ig ZGVzY3JpYmluZyBjZXJ0YWluIHJlbGF0aW9uc2hpcHMgaW4gYSANCm5ldHdvcmsgbW9kZWwuIFRo ZSB0ZXJtIGlzICAiUHJvb2YgU291cmNlIFByb3ZpZGVyIiBvciBQU1AgYW5kIGl0IG1lYW5zIA0K c29tZSBzZXJ2aWNlIHdoaWNoIGlzIHByb3ZpZGluZyBhIHRydXN0LWFuY2hvciBmb3Igc29tZSBv dGhlciBwcm9jZXNzIG9yIA0KdGhlIGxpa2UuIFRoZSBQU1AgaXMgdGhlIHBhcnR5IG9yIHN5c3Rl bSB3aGljaCBwcm92aWRlcyB0aGUgb3ZlcnNpZ2h0IA0KYW5kIHByb2Nlc3MgY29udHJvbCBmb3Ig YW4gVFJVU1QtQU5DSE9SIC0gdGhlIGNvbXBvbmVudCBvZiB0aGUgdHJ1c3QgDQplbGVtZW50IHdo aWNoIHRpZXMgdGhlIHNwZWNpZmljIGNvbnRlbnQgdG8gdGhhdCB0cnVzdCBlbGVtZW50LiBUaGUg VGVybSANClRydXN0IEFuY2hvciAobm93IHdpZGVseSBpbiB1c2UgaW4gU2VjdXJlIEROUykgd2Fz IGNvaW5lZCBpbiBQS0lYIA0Kc2V2ZXJhbCB5ZWFycyBhZ28gYnV0IGlzIGNyaXRpY2FsbHkgdmFs dWFibGUgbm93IGluIG90aGVyIGFyZWFzIGFuZCB3ZSANCnNob3VsZCBlbWJyYWNlIGJvdGggaXQg YW5kIHRoZSBpZGVhIG9mIHRoZSBQcm9vZiBTb3VyY2UgUHJvdmlkZXIgYW5kIHRoZSANClByb29m IFNvdXJjZSB0aGV5IHVzZSB0byBjZXJhdGUgYWRtaXNzaWJpbGl0eSBmb3IgdGhlIGV2aWRlbmNl Lg0KDQpJdCAoUFNQKSAgcGVydGFpbnMgdGhlbiB0byBhdWRpdGluZyB0cnVzdCByZWxhdGlvbnNo aXBzIGFuZCB0aGVpciANCmFiaWxpdHkgdG8gY29udmV5IHBvbGljeSBhbmQgY29udHJvbCBvdmVy IGEgbGFyZ2VyIG1ldGhvZG9sb2d5IGFuZCBpcyBhIA0Ka2V5IHBhcnQgb2YgcmVsYXRpb25hbCB0 cnVzdCBtb2RlbHMgd2hpY2ggYXJlIHByb3BhZ2F0ZWQgYWNyb3NzIG11bHRpcGxlIA0KdGVjaG5v bG9naWVzIGFuZCB3b3VsZCBiZSB1c2VkIGluIExUQU5TIFNlY3VyaXR5IGFuZCBvdGhlciBrZXkg cHJvY2Vzc2VzLg0KDQpXaHkgdGhpcyBpcyBpbXBvcnRhbnQgaXMgdGhhdCBzeXN0ZW1zIGFuZCBw cm9jZXNzZXMgd2hpY2ggd2Ugd291bGQgYnVpbGQgDQpmcm9tIHRoZXNlIHRlY2hub2xvZ2llcyB3 b3VsZCBhbHNvIHBlcmZvcm0gZnVuY3Rpb25zIGluIHRoZSByZWFsIHdvcmxkIA0Kd2hpY2ggd291 bGQgaGF2ZSBsZWdhbCBpbXBsaWNhdGlvbnMgYW5kIHNvIHRoZSBhYmlsaXR5IHRvIHJlcHJlc2Vu dCANCnRydXN0LWFuY2hvciBwcm9jZXNzZXMgaW4gdGhlIHJlY29yZHMgY3JlYXRlZCB3b3VsZCBh ZG1pc3NpYmxlIGluIGdsb2JhbCANCmNvdXJ0cy4gVGhpcyBub21lbmNsYXR1cmUgcHJvdmlkZXMg YSByZXNvdXJjZSBmb3IgdGhpcyBhbmQgb3RoZXIgdXNlcy4NCg0KVG9kZCBHbGFzc2V5DQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmx0YW5zIG1h aWxpbmcgbGlzdA0KbHRhbnNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHRhbnMNCg0KDQo= From tglassey@earthlink.net Tue Sep 15 09:32:54 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB6063A6B4A for ; Tue, 15 Sep 2009 09:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.372 X-Spam-Level: X-Spam-Status: No, score=-4.372 tagged_above=-999 required=5 tests=[AWL=1.674, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKlyEKzEVXen for ; Tue, 15 Sep 2009 09:32:53 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id C46FC3A6A4D for ; Tue, 15 Sep 2009 09:32:53 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FGLBj3007999 for ; Tue, 15 Sep 2009 09:21:20 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KOe1fjm5rmu2Bg54kklgW7/zUxUEmvLO6emtQBH43ZDJJ2zd1bjXRkEHwdUIaPRp; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MnamD-000339-7L; Tue, 15 Sep 2009 12:21:09 -0400 Message-ID: <4AAFBEF3.8060607@earthlink.net> Date: Tue, 15 Sep 2009 09:21:07 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bill Russell References: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> In-Reply-To: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79875fae9da7f30e86c87abcdcf81467ab350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 Cc: "ietf-ltans@imc.org" Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 16:32:54 -0000 Bill Russell wrote: > We (Pericore) already use that term to express digitally signed authorizations. Bummer - its copyrighted and not currently under any license. > Also, Corestreet uses that term in one of their products. I think the term is overloaded and should not be used as you propose. > The term was used by me officially in print 10 years ago and it was (c)'d on those works... your general counsel may get a kick out of that and I can provide those documents to anyone that wants them. My proposal here was to file that term with the IETF to make it available to the public which IT IS NOT NOW. The term pertains to trust-anchors in timestamps for evidence promulgation through digital networks and this was done in the 1999 through 2001 time frame on my CertifiedTime startup. So Bill, any comments? Todd Glassey > -----Original Message----- > From: "Todd Glassey" > To: "ietf-ltans@imc.org" > Sent: 9/15/09 11:17 AM > Subject: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies > > Folks - > I want to propose a new term for describing certain relationships in a > network model. The term is "Proof Source Provider" or PSP and it means > some service which is providing a trust-anchor for some other process or > the like. The PSP is the party or system which provides the oversight > and process control for an TRUST-ANCHOR - the component of the trust > element which ties the specific content to that trust element. The Term > Trust Anchor (now widely in use in Secure DNS) was coined in PKIX > several years ago but is critically valuable now in other areas and we > should embrace both it and the idea of the Proof Source Provider and the > Proof Source they use to cerate admissibility for the evidence. > > It (PSP) pertains then to auditing trust relationships and their > ability to convey policy and control over a larger methodology and is a > key part of relational trust models which are propagated across multiple > technologies and would be used in LTANS Security and other key processes. > > Why this is important is that systems and processes which we would build > from these technologies would also perform functions in the real world > which would have legal implications and so the ability to represent > trust-anchor processes in the records created would admissible in global > courts. This nomenclature provides a resource for this and other uses. > > Todd Glassey > > > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.99/2372 - Release Date: 09/15/09 05:59:00 > > From remo@t-bizcom.com Tue Sep 15 10:06:03 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A923F28C129 for ; Tue, 15 Sep 2009 10:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8kjI56KAeq7 for ; Tue, 15 Sep 2009 10:06:02 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id AF95C3A6AAE for ; Tue, 15 Sep 2009 10:06:02 -0700 (PDT) Received: from ns2.t-bizcom.com (adsl-14-159.38-151.net24.it [151.38.159.14]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FH6eGf011489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Sep 2009 10:06:48 -0700 (MST) (envelope-from remo@t-bizcom.com) Received: from ns2.t-bizcom.com (localhost [127.0.0.1]) by ns2.t-bizcom.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id n8FH6XZX014267; Tue, 15 Sep 2009 19:06:36 +0200 Received: from 93.41.185.139 (SquirrelMail authenticated user remo) by ns2.t-bizcom.com with HTTP; Tue, 15 Sep 2009 19:06:36 +0200 (CEST) Message-ID: <24910.93.41.185.139.1253034396.squirrel@ns2.t-bizcom.com> In-Reply-To: <4AAFBEF3.8060607@earthlink.net> References: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> <4AAFBEF3.8060607@earthlink.net> Date: Tue, 15 Sep 2009 19:06:36 +0200 (CEST) From: "Remo Tabanelli" To: "Todd Glassey" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ietf-ltans@imc.org" , Bill Russell Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: remo@t-bizcom.com List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 17:06:03 -0000 On Mar, 15 Settembre 2009 6:21 pm, Todd Glassey wrote: > Bill Russell wrote: >> We (Pericore) already use that term to express digitally signed >> authorizations. > Bummer - its copyrighted and not currently under any license. >> Also, Corestreet uses that term in one of their products. I think the >> term is overloaded and should not be used as you propose. >> > The term was used by me officially in print 10 years ago and it was > (c)'d on those works... your general counsel may get a kick out of that > and I can provide those documents to anyone that wants them. Bill & Todd Until now... and for more than two years I was silent on this list. and... today I'm very sad. IMHO a discussion in a IETF WG about copyrighted terms (or any other so called I.P. "wapor issue") is misplaced here. I'm not interested in hearing from anyone of us who was the first that used a plain english expression like "Proof Source Provider" because the first source of these terms is the common language... and I suppose you can find anyone of these word on a common dictionary! IMHO a phrase (in any language) is (or must be) without a specific and *explained contest* uncopyrightable. I'ts not realistic pretend to have a copyright on a term (or phrase) without the accluded (and this can be eventually copyrigthed not the single term or phrase) document/work. So if the WG think that using this terms is useful (IMHO) can decide to use it, if not we will not use it. Simply as that. Tank you all folks! Remo Tabanelli From cwallace@cygnacom.com Tue Sep 15 10:33:00 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54D793A6AAE for ; Tue, 15 Sep 2009 10:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.322 X-Spam-Level: X-Spam-Status: No, score=-4.322 tagged_above=-999 required=5 tests=[AWL=1.724, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7trL2lYKEkvV for ; Tue, 15 Sep 2009 10:32:59 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2EBC53A6A24 for ; Tue, 15 Sep 2009 10:32:58 -0700 (PDT) Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FHP6nE012997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Sep 2009 10:25:11 -0700 (MST) (envelope-from cwallace@cygnacom.com) Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 7fdcfaa4.2679081904.20321.00-023.p03c11o141.symantecmail.net (envelope-from ); Tue, 15 Sep 2009 11:25:11 -0600 (MDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 15 Sep 2009 13:25:02 -0400 Message-ID: In-Reply-To: <4AAFAFEE.9090201@earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies Thread-Index: Aco2F57h5g5xOY64SE6ww5Eim0S1wwAEKbwQ References: <4AAFAFEE.9090201@earthlink.net> From: "Carl Wallace" To: "Todd Glassey" , X-Spam: [F=0.2000000000; S=0.200(2009090401)] X-MAIL-FROM: X-SOURCE-IP: [65.242.48.5] Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 17:33:00 -0000 It's not clear to me what you are proposing, i.e., alteration of existing specs to use the new terminology, preparation of auditing guidelines, specification of protocols for distributing trust anchors, definition of structures for binding trust anchors to document hierarchies, or something else. A draft may help establish context. Depending on the nature of the work, LTANS may not be the best place to pursue it, but if pursued here re-chartering would be required.=20 > -----Original Message----- > From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf > Of Todd Glassey > Sent: Tuesday, September 15, 2009 11:17 AM > To: ietf-ltans@imc.org > Subject: [ltans] "Proof Source Provider" - new term for use in > describing trust chains in document hierarchies >=20 > Folks - > I want to propose a new term for describing certain relationships in a > network model. The term is "Proof Source Provider" or PSP and it means > some service which is providing a trust-anchor for some other process > or > the like. The PSP is the party or system which provides the oversight > and process control for an TRUST-ANCHOR - the component of the trust > element which ties the specific content to that trust element. The Term > Trust Anchor (now widely in use in Secure DNS) was coined in PKIX > several years ago but is critically valuable now in other areas and we > should embrace both it and the idea of the Proof Source Provider and > the > Proof Source they use to cerate admissibility for the evidence. >=20 > It (PSP) pertains then to auditing trust relationships and their > ability to convey policy and control over a larger methodology and is a > key part of relational trust models which are propagated across > multiple > technologies and would be used in LTANS Security and other key > processes. >=20 > Why this is important is that systems and processes which we would > build > from these technologies would also perform functions in the real world > which would have legal implications and so the ability to represent > trust-anchor processes in the records created would admissible in > global > courts. This nomenclature provides a resource for this and other uses. >=20 > Todd Glassey >=20 >=20 > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans From brussell@pericore.com Tue Sep 15 10:52:19 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF0863A6A9A for ; Tue, 15 Sep 2009 10:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.581 X-Spam-Level: X-Spam-Status: No, score=-4.581 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bKFPwAT43KM for ; Tue, 15 Sep 2009 10:52:18 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id A01A33A6A84 for ; Tue, 15 Sep 2009 10:52:18 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FHr54u014822 for ; Tue, 15 Sep 2009 10:53:05 -0700 (MST) (envelope-from brussell@pericore.com) Received: from BE127.mail.lan ([10.109.208.127]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 13:53:04 -0400 Received: from HUB015.mail.lan ([10.110.17.15]) by BE127.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Sep 2009 13:53:04 -0400 Received: from MAILR003.mail.lan ([10.110.18.20]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Tue, 15 Sep 2009 13:53:03 -0400 From: Bill Russell To: "remo@t-bizcom.com" , Todd Glassey Date: Tue, 15 Sep 2009 13:53:14 -0400 Thread-Topic: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies Thread-Index: Aco2JvoOsVYLvbb4Srq4gDtnqKQquwABaS/g Message-ID: <9DCCF5807745F9438462F1F6A66CADA403202E158F@MAILR003.mail.lan> References: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> <4AAFBEF3.8060607@earthlink.net> <24910.93.41.185.139.1253034396.squirrel@ns2.t-bizcom.com> In-Reply-To: <24910.93.41.185.139.1253034396.squirrel@ns2.t-bizcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Sep 2009 17:53:04.0349 (UTC) FILETIME=[5FE100D0:01CA362D] Cc: "ietf-ltans@imc.org" Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 17:52:19 -0000 Hi Todd & Remo, If the term Proof is in fact copyrighted, I would guess that any legal righ= ts were lost long ago by failing to enforce it properly, as it is used by m= ultiple companies and with multiple products. That notwithstanding, the emp= hasis of my email was not on copyrighted terminology, but rather on the fac= t that the term might be confused in usage. Carl's comment is perhaps the m= ore important though, does this topic even warrant discussion as part of th= is group? I apologize for any confusion I may have introduced by my email, = as I was merely trying to suggest that the term is overloaded. I think your= email continues to make the point that it is in fact not the best for this= group to incorporate.=20 Take care, Bill -----Original Message----- From: Remo Tabanelli [mailto:remo@t-bizcom.com]=20 Sent: Tuesday, September 15, 2009 1:07 PM To: Todd Glassey Cc: Bill Russell; ietf-ltans@imc.org Subject: Re: [ltans] "Proof Source Provider" - new term for use in describi= ng trust chains in document hierarchies On Mar, 15 Settembre 2009 6:21 pm, Todd Glassey wrote: > Bill Russell wrote: >> We (Pericore) already use that term to express digitally signed >> authorizations. > Bummer - its copyrighted and not currently under any license. >> Also, Corestreet uses that term in one of their products. I think the >> term is overloaded and should not be used as you propose. >> > The term was used by me officially in print 10 years ago and it was > (c)'d on those works... your general counsel may get a kick out of that > and I can provide those documents to anyone that wants them. Bill & Todd Until now... and for more than two years I was silent on this list. and... today I'm very sad. IMHO a discussion in a IETF WG about copyrighted terms (or any other so called I.P. "wapor issue") is misplaced here. I'm not interested in hearing from anyone of us who was the first that used a plain english expression like "Proof Source Provider" because the first source of these terms is the common language... and I suppose you can find anyone of these word on a common dictionary! IMHO a phrase (in any language) is (or must be) without a specific and *explained contest* uncopyrightable. I'ts not realistic pretend to have a copyright on a term (or phrase) without the accluded (and this can be eventually copyrigthed not the single term or phrase) document/work. So if the WG think that using this terms is useful (IMHO) can decide to use it, if not we will not use it. Simply as that. Tank you all folks! Remo Tabanelli From tglassey@earthlink.net Tue Sep 15 10:52:35 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3803A6858 for ; Tue, 15 Sep 2009 10:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.524 X-Spam-Level: X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=1.522, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWEAJ7ZRoUfl for ; Tue, 15 Sep 2009 10:52:33 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CE6863A6B54 for ; Tue, 15 Sep 2009 10:52:33 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FHrFpJ014842 for ; Tue, 15 Sep 2009 10:53:20 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ne0na3DEeFonbcqCrtMNPrCD70vkKIqq24MKVaGQW4MPyZM42ncbCt0zFvzJwSyf; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MncDL-0007ob-Jf; Tue, 15 Sep 2009 13:53:15 -0400 Message-ID: <4AAFD488.1020709@earthlink.net> Date: Tue, 15 Sep 2009 10:53:12 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Carl Wallace References: <4AAFAFEE.9090201@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7922e4f40f3a98083839b7be293f30d04f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 Cc: ietf-ltans@imc.org Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 17:52:35 -0000 Carl Wallace wrote: > It's not clear to me what you are proposing, i.e., alteration of > existing specs to use the new terminology, preparation of auditing > guidelines, Hey Carl how goes it. Hope all is well with you! In answer to your question - "Specifically the preparation of auditing guidelines to use for evaluating LTANS systems so we can get their operational tools into production in evidence management as soon as possible". Which is to say we have a prototype system we are starting to test which uses NTP as the core of the time-management practice and an integrated LTANS model for managing the DRM and Object Controls on the Documents. I have been professionally working on this since the mid 1990's when I left Coastek (1996) and approached Datum to build my secured clock for my email and document controls. Now its time to roll that NTP-based LTANS-type Management solution out. An effort which lead to the US Patent filing for "Controlling Access to Stored Information" (issued as US 6370629). Todd > specification of protocols for distributing trust anchors, > definition of structures for binding trust anchors to document > hierarchies, or something else. A draft may help establish context. > Depending on the nature of the work, LTANS may not be the best place to > pursue it, but if pursued here re-chartering would be required. > > >> -----Original Message----- >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf >> Of Todd Glassey >> Sent: Tuesday, September 15, 2009 11:17 AM >> To: ietf-ltans@imc.org >> Subject: [ltans] "Proof Source Provider" - new term for use in >> describing trust chains in document hierarchies >> >> Folks - >> I want to propose a new term for describing certain relationships in a >> network model. The term is "Proof Source Provider" or PSP and it >> > means > >> some service which is providing a trust-anchor for some other process >> or >> the like. The PSP is the party or system which provides the oversight >> and process control for an TRUST-ANCHOR - the component of the trust >> element which ties the specific content to that trust element. The >> > Term > >> Trust Anchor (now widely in use in Secure DNS) was coined in PKIX >> several years ago but is critically valuable now in other areas and we >> should embrace both it and the idea of the Proof Source Provider and >> the >> Proof Source they use to cerate admissibility for the evidence. >> >> It (PSP) pertains then to auditing trust relationships and their >> ability to convey policy and control over a larger methodology and is >> > a > >> key part of relational trust models which are propagated across >> multiple >> technologies and would be used in LTANS Security and other key >> processes. >> >> Why this is important is that systems and processes which we would >> build >> from these technologies would also perform functions in the real world >> which would have legal implications and so the ability to represent >> trust-anchor processes in the records created would admissible in >> global >> courts. This nomenclature provides a resource for this and other uses. >> >> Todd Glassey >> >> >> _______________________________________________ >> ltans mailing list >> ltans@ietf.org >> https://www.ietf.org/mailman/listinfo/ltans >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.99/2372 - Release Date: 09/15/09 05:59:00 >> >> From tglassey@earthlink.net Tue Sep 15 11:08:13 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E423A6A92 for ; Tue, 15 Sep 2009 11:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.351 X-Spam-Level: X-Spam-Status: No, score=-4.351 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZW7fbVtp3WA for ; Tue, 15 Sep 2009 11:08:12 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 3ED573A6B5E for ; Tue, 15 Sep 2009 11:08:12 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FI8rNU015879 for ; Tue, 15 Sep 2009 11:08:59 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=m87mNQ3kApfjOERqbsUSQIcU0y8PWe/KZdIR+4KwbvTBz7ZJ2dXdbYBVCqWaAUXg; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MncSS-000100-3a; Tue, 15 Sep 2009 14:08:52 -0400 Message-ID: <4AAFD832.4090206@earthlink.net> Date: Tue, 15 Sep 2009 11:08:50 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Bill Russell References: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> <4AAFBEF3.8060607@earthlink.net> <24910.93.41.185.139.1253034396.squirrel@ns2.t-bizcom.com> <9DCCF5807745F9438462F1F6A66CADA403202E158F@MAILR003.mail.lan> In-Reply-To: <9DCCF5807745F9438462F1F6A66CADA403202E158F@MAILR003.mail.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79197bd56ac7ed524ee1829ccd493555be350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 Cc: "ietf-ltans@imc.org" Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 18:08:13 -0000 Bill Russell wrote: > Hi Todd & Remo, > > If the term Proof is in fact copyrighted, yep... > I would guess that any legal rights were lost long ago by failing to enforce it properly, Since the entity who copywrite'd it is involved in litigation the rights are not clear from my perspective - but hey that's a different story. I was intending to surrender my rights on it and make it IETF property (scary thought that eh?) but if you folks want to push back against that I will withdraw the offer. > as it is used by multiple companies and with multiple products. That notwithstanding, the emphasis of my email was not on copyrighted terminology, but rather on the fact that the term might be confused in usage. OK - how so? My intent is to get a CMS type solution based on this technology into production here in the US. > Carl's comment is perhaps the more important though, does this topic even warrant discussion as part of this group? That's specifically what I was trying to figure out. If LTANS doesnt want it I am totally cool with that. > I apologize for any confusion I may have introduced by my email, as I was merely trying to suggest that the term is overloaded. I think your email continues to make the point that it is in fact not the best for this group to incorporate. > Me as well ! Todd > Take care, > Bill > > -----Original Message----- > From: Remo Tabanelli [mailto:remo@t-bizcom.com] > Sent: Tuesday, September 15, 2009 1:07 PM > To: Todd Glassey > Cc: Bill Russell; ietf-ltans@imc.org > Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies > > On Mar, 15 Settembre 2009 6:21 pm, Todd Glassey wrote: > >> Bill Russell wrote: >> >>> We (Pericore) already use that term to express digitally signed >>> authorizations. >>> >> Bummer - its copyrighted and not currently under any license. >> >>> Also, Corestreet uses that term in one of their products. I think the >>> term is overloaded and should not be used as you propose. >>> >>> >> The term was used by me officially in print 10 years ago and it was >> (c)'d on those works... your general counsel may get a kick out of that >> and I can provide those documents to anyone that wants them. >> > > Bill & Todd > > Until now... and for more than two years I was silent on this list. > and... today I'm very sad. > > IMHO a discussion in a IETF WG about copyrighted terms (or any other so > called I.P. "wapor issue") is misplaced here. > > I'm not interested in hearing from anyone of us who was the first that > used a plain english expression like "Proof Source Provider" because the > first source of these terms is the common language... and I suppose you > can find anyone of these word on a common dictionary! > > IMHO a phrase (in any language) is (or must be) without a specific and > *explained contest* uncopyrightable. > I'ts not realistic pretend to have a copyright on a term (or phrase) > without the accluded (and this can be eventually copyrigthed not the > single term or phrase) document/work. > > So if the WG think that using this terms is useful (IMHO) can decide to > use it, if not we will not use it. > > Simply as that. > > Tank you all folks! > > Remo Tabanelli > > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.99/2372 - Release Date: 09/15/09 05:59:00 > > From remo@t-bizcom.com Tue Sep 15 12:07:21 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597D828C221 for ; Tue, 15 Sep 2009 12:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.239 X-Spam-Level: X-Spam-Status: No, score=-4.239 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzJ9uxAVI9hs for ; Tue, 15 Sep 2009 12:07:20 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0230628C220 for ; Tue, 15 Sep 2009 12:07:19 -0700 (PDT) Received: from ns2.t-bizcom.com (adsl-14-159.38-151.net24.it [151.38.159.14]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FJ84I1019375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Sep 2009 12:08:06 -0700 (MST) (envelope-from remo@t-bizcom.com) Received: from ns2.t-bizcom.com (localhost [127.0.0.1]) by ns2.t-bizcom.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id n8FJ7pfH016877; Tue, 15 Sep 2009 21:07:53 +0200 Received: from 93.41.185.139 (SquirrelMail authenticated user remo) by ns2.t-bizcom.com with HTTP; Tue, 15 Sep 2009 21:07:54 +0200 (CEST) Message-ID: <25507.93.41.185.139.1253041674.squirrel@ns2.t-bizcom.com> In-Reply-To: <9DCCF5807745F9438462F1F6A66CADA403202E158F@MAILR003.mail.lan> References: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> <4AAFBEF3.8060607@earthlink.net> <24910.93.41.185.139.1253034396.squirrel@ns2.t-bizcom.com> <9DCCF5807745F9438462F1F6A66CADA403202E158F@MAILR003.mail.lan> Date: Tue, 15 Sep 2009 21:07:54 +0200 (CEST) From: "Remo Tabanelli" To: "Bill Russell" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ietf-ltans@imc.org" Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: remo@t-bizcom.com List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 19:07:21 -0000 On Mar, 15 Settembre 2009 7:53 pm, Bill Russell wrote: > Hi Todd & Remo, > > If the term Proof is in fact copyrighted, I would guess that any legal > rights were lost long ago by failing to enforce it properly, as it is used > by multiple companies and with multiple products. That notwithstanding, > the emphasis of my email was not on copyrighted terminology, but rather on > the fact that the term might be confused in usage. Carl's comment is > perhaps the more important though, does this topic even warrant discussion > as part of this group? I apologize for any confusion I may have introduced > by my email, as I was merely trying to suggest that the term is > overloaded. I think your email continues to make the point that it is in > fact not the best for this group to incorporate. > > Take care, > Bill Bill I fully understand your warning and (at least in part) I agree with you... but this is not what I am worried about. I have not expressed an opinion about the fact that using the term proposed by Todd is appropriate or not. My opinion was simply about the fact that we (the WG) can or cannot use the proposed term! And clearly I have a very firm opinion about the fact that we can use it and... let me reinforce te concept... IMHO if we want (if we, all the folks here, agree on it) we can use *any* term we like! Disregarding totally the **miserable** "topic" about the pretended "copyrighted" term. "Proof" you said?... In the real life be sure that I will challenge in any court any allegation (to me or any of my interest) about the use of a single english word (or any language) or common phrase/term like "Proof".... if you (or any other) pretend the exclusive use of the term (without the entire document or context of the *really copyrigthed work*) ... I will ack on any copyrigthed work but not (repeat not) on any "decontestualized" term or word included in the copyrigthed work! Pretending the exclusive use of a term or single phrase (without a contex or case specification) is absurd in any *legal system* of this (real) world! This is *not legal* and not fair! And.. yes... maybe I'm wrong but I'm pretty sure that (in the case) I will be the winner! Just to explain are you sustaining that because I can read (in many RFC) the following: "Copyright (C) The Internet Society (xxxx)" And, in the same document, terms like "Must" "shall" "Must be" etc.. I cannot freely use it (the same terms in any different document) as I want? As example I can use the term "windows" as I want and where I want. I only must take care of it only (and only if) I talk about a specific O.S. or Product(s). And last (but not least) are we a IETF WG made solely of *individuals* or a lobby of employes of some corporation claiming some vague "wapor IP" on some product/document/implementation? This is what made me sad! Remo Tabanelli > > -----Original Message----- > From: Remo Tabanelli [mailto:remo@t-bizcom.com] > Sent: Tuesday, September 15, 2009 1:07 PM > To: Todd Glassey > Cc: Bill Russell; ietf-ltans@imc.org > Subject: Re: [ltans] "Proof Source Provider" - new term for use in > describing trust chains in document hierarchies > > On Mar, 15 Settembre 2009 6:21 pm, Todd Glassey wrote: >> Bill Russell wrote: >>> We (Pericore) already use that term to express digitally signed >>> authorizations. >> Bummer - its copyrighted and not currently under any license. >>> Also, Corestreet uses that term in one of their products. I think the >>> term is overloaded and should not be used as you propose. >>> >> The term was used by me officially in print 10 years ago and it was >> (c)'d on those works... your general counsel may get a kick out of that >> and I can provide those documents to anyone that wants them. > > Bill & Todd > > Until now... and for more than two years I was silent on this list. > and... today I'm very sad. > > IMHO a discussion in a IETF WG about copyrighted terms (or any other so > called I.P. "wapor issue") is misplaced here. > > I'm not interested in hearing from anyone of us who was the first that > used a plain english expression like "Proof Source Provider" because the > first source of these terms is the common language... and I suppose you > can find anyone of these word on a common dictionary! > > IMHO a phrase (in any language) is (or must be) without a specific and > *explained contest* uncopyrightable. > I'ts not realistic pretend to have a copyright on a term (or phrase) > without the accluded (and this can be eventually copyrigthed not the > single term or phrase) document/work. > > So if the WG think that using this terms is useful (IMHO) can decide to > use it, if not we will not use it. > > Simply as that. > > Tank you all folks! > > Remo Tabanelli > > > > From tglassey@earthlink.net Tue Sep 15 13:03:00 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89F828C267 for ; Tue, 15 Sep 2009 13:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJceAiMTDBv1 for ; Tue, 15 Sep 2009 13:02:59 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 48DD828C266 for ; Tue, 15 Sep 2009 13:02:59 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FJlkeN022192 for ; Tue, 15 Sep 2009 12:47:51 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qFguDJFo5fflaoLSCVCZz7nRZ7ZxTCbMbXe6Vp63IIQNPWK4VDVxFappro9YwdBm; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Mne07-0007d0-08; Tue, 15 Sep 2009 15:47:43 -0400 Message-ID: <4AAFEF5C.6070604@earthlink.net> Date: Tue, 15 Sep 2009 12:47:40 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: remo@t-bizcom.com References: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> <4AAFBEF3.8060607@earthlink.net> <24910.93.41.185.139.1253034396.squirrel@ns2.t-bizcom.com> <9DCCF5807745F9438462F1F6A66CADA403202E158F@MAILR003.mail.lan> <25507.93.41.185.139.1253041674.squirrel@ns2.t-bizcom.com> In-Reply-To: <25507.93.41.185.139.1253041674.squirrel@ns2.t-bizcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79297de0f69b0eea9b2d3b2baef69a5695350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 Cc: "ietf-ltans@imc.org" Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 20:03:00 -0000 Remo Tabanelli wrote: > On Mar, 15 Settembre 2009 7:53 pm, Bill Russell wrote: > >> Hi Todd & Remo, >> Remo having personally taken a matter to the US Supreme Court (case #08-01088) , it aint anywhere as easy as we think it should be. And to reinforce this, I am saying a 100 Page publication for the Supreme Court will cost about $10K to publish including the $40/Page typesetting fees for the final copy and the building of the various Tables at $100 a page or more for the typesetting alone. The figure in the binding cost and cost of submit to the Court ($300 + courier fees), and since I speak from first hand experience arguing this is pointless. That aside, the IETF relies on its research exemption under section 107 of the DCMA to allow it to talk about anything it likes - and that's the problem here since the users of the IETF standards are not legally allowed to use that code or IP in the real world just because the IETF told them they could reprint the standards-effort paperwork and content. It's one of the flaws in the logic the IETF puts forward. The IETF's license is not about anything other than the publication for the standards process and whether the people using those to implement code or not realize it the IETF cannot provide a right-to-use status on copyrighted work they dont own no matter what. Representing that they would or could do so may also be a criminal act of electronic fraud in this case in my opinion. So in bringing that term fully inside the IETF as a NoteWell work-product I was trying to make that pain go away... But hey I get your concern so if the IETF isnt worried about that I totally understand and we can just withdraw the offer. Have a great day, Todd Glassey >> If the term Proof is in fact copyrighted, I would guess that any legal >> rights were lost long ago by failing to enforce it properly, as it is used >> by multiple companies and with multiple products. That notwithstanding, >> the emphasis of my email was not on copyrighted terminology, but rather on >> the fact that the term might be confused in usage. Carl's comment is >> perhaps the more important though, does this topic even warrant discussion >> as part of this group? I apologize for any confusion I may have introduced >> by my email, as I was merely trying to suggest that the term is >> overloaded. I think your email continues to make the point that it is in >> fact not the best for this group to incorporate. >> >> Take care, >> Bill >> > > Bill I fully understand your warning and (at least in part) I agree with > you... but this is not what I am worried about. > > I have not expressed an opinion about the fact that using the term > proposed by Todd is appropriate or not. > > My opinion was simply about the fact that we (the WG) can or cannot use > the proposed term! > And clearly I have a very firm opinion about the fact that we can use it > and... let me reinforce te concept... IMHO if we want (if we, all the > folks here, agree on it) we can use *any* term we like! > Disregarding totally the **miserable** "topic" about the pretended > "copyrighted" term. > > "Proof" you said?... > > In the real life be sure that I will challenge in any court any allegation > (to me or any of my interest) about the use of a single english word (or > any language) or common phrase/term like "Proof".... if you (or any other) > pretend the exclusive use of the term (without the entire document or > context of the *really copyrigthed work*) ... > > I will ack on any copyrigthed work but not (repeat not) on any > "decontestualized" term or word included in the copyrigthed work! > > Pretending the exclusive use of a term or single phrase (without a contex > or case specification) is absurd in any *legal system* of this (real) > world! > This is *not legal* and not fair! > And.. yes... maybe I'm wrong but I'm pretty sure that (in the case) I will > be the winner! > > Just to explain are you sustaining that because I can read (in many RFC) > the following: > "Copyright (C) The Internet Society (xxxx)" > And, in the same document, terms like "Must" "shall" "Must be" etc.. I > cannot freely use it (the same terms in any different document) as I want? > > As example I can use the term "windows" as I want and where I want. > > I only must take care of it only (and only if) I talk about a specific > O.S. or Product(s). > > And last (but not least) are we a IETF WG made solely of *individuals* or > a lobby of employes of some corporation claiming some vague "wapor IP" on > some product/document/implementation? > > This is what made me sad! > > Remo Tabanelli > > >> -----Original Message----- >> From: Remo Tabanelli [mailto:remo@t-bizcom.com] >> Sent: Tuesday, September 15, 2009 1:07 PM >> To: Todd Glassey >> Cc: Bill Russell; ietf-ltans@imc.org >> Subject: Re: [ltans] "Proof Source Provider" - new term for use in >> describing trust chains in document hierarchies >> >> On Mar, 15 Settembre 2009 6:21 pm, Todd Glassey wrote: >> >>> Bill Russell wrote: >>> >>>> We (Pericore) already use that term to express digitally signed >>>> authorizations. >>>> >>> Bummer - its copyrighted and not currently under any license. >>> >>>> Also, Corestreet uses that term in one of their products. I think the >>>> term is overloaded and should not be used as you propose. >>>> >>>> >>> The term was used by me officially in print 10 years ago and it was >>> (c)'d on those works... your general counsel may get a kick out of that >>> and I can provide those documents to anyone that wants them. >>> >> Bill & Todd >> >> Until now... and for more than two years I was silent on this list. >> and... today I'm very sad. >> >> IMHO a discussion in a IETF WG about copyrighted terms (or any other so >> called I.P. "wapor issue") is misplaced here. >> >> I'm not interested in hearing from anyone of us who was the first that >> used a plain english expression like "Proof Source Provider" because the >> first source of these terms is the common language... and I suppose you >> can find anyone of these word on a common dictionary! >> >> IMHO a phrase (in any language) is (or must be) without a specific and >> *explained contest* uncopyrightable. >> I'ts not realistic pretend to have a copyright on a term (or phrase) >> without the accluded (and this can be eventually copyrigthed not the >> single term or phrase) document/work. >> >> So if the WG think that using this terms is useful (IMHO) can decide to >> use it, if not we will not use it. >> >> Simply as that. >> >> Tank you all folks! >> >> Remo Tabanelli >> >> >> >> >> > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.99/2372 - Release Date: 09/15/09 05:59:00 > > From remo@t-bizcom.com Tue Sep 15 14:02:55 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C8228C167 for ; Tue, 15 Sep 2009 14:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.843 X-Spam-Level: X-Spam-Status: No, score=-4.843 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrhnMa3Y1tVv for ; Tue, 15 Sep 2009 14:02:54 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id F2F2E3A6BE9 for ; Tue, 15 Sep 2009 14:02:53 -0700 (PDT) Received: from ns2.t-bizcom.com (adsl-14-159.38-151.net24.it [151.38.159.14]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FKoX0N026064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Sep 2009 13:50:40 -0700 (MST) (envelope-from remo@t-bizcom.com) Received: from ns2.t-bizcom.com (localhost [127.0.0.1]) by ns2.t-bizcom.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id n8FKoITw019081; Tue, 15 Sep 2009 22:50:20 +0200 Received: from 93.41.185.139 (SquirrelMail authenticated user remo) by ns2.t-bizcom.com with HTTP; Tue, 15 Sep 2009 22:50:21 +0200 (CEST) Message-ID: <25891.93.41.185.139.1253047821.squirrel@ns2.t-bizcom.com> In-Reply-To: <4AAFEF5C.6070604@earthlink.net> References: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> <4AAFBEF3.8060607@earthlink.net> <24910.93.41.185.139.1253034396.squirrel@ns2.t-bizcom.com> <9DCCF5807745F9438462F1F6A66CADA403202E158F@MAILR003.mail.lan> <25507.93.41.185.139.1253041674.squirrel@ns2.t-bizcom.com> <4AAFEF5C.6070604@earthlink.net> Date: Tue, 15 Sep 2009 22:50:21 +0200 (CEST) From: "Remo Tabanelli" To: "Todd Glassey" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ietf-ltans@imc.org" Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: remo@t-bizcom.com List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 21:02:55 -0000 On Mar, 15 Settembre 2009 9:47 pm, Todd Glassey wrote: > Remo Tabanelli wrote: >> On Mar, 15 Settembre 2009 7:53 pm, Bill Russell wrote: >> >>> Hi Todd & Remo, >>> > Remo > having personally taken a matter to the US Supreme Court (case > #08-01088) , it aint anywhere as easy as we think it should be. And to > reinforce this, I am saying a 100 Page publication for the Supreme Court > will cost about $10K to publish including the $40/Page typesetting fees > for the final copy and the building of the various Tables at $100 a page > or more for the typesetting alone. The figure in the binding cost and > cost of submit to the Court ($300 + courier fees), and since I speak > from first hand experience arguing this is pointless. > > That aside, the IETF relies on its research exemption under section 107 > of the DCMA to allow it to talk about anything it likes - and that's the > problem here since the users of the IETF standards are not legally > allowed to use that code or IP in the real world just because the IETF > told them they could reprint the standards-effort paperwork and content. > > It's one of the flaws in the logic the IETF puts forward. The IETF's > license is not about anything other than the publication for the > standards process and whether the people using those to implement code > or not realize it the IETF cannot provide a right-to-use status on > copyrighted work they dont own no matter what. Representing that they > would or could do so may also be a criminal act of electronic fraud in > this case in my opinion. No Todd! Let me say (friendly) that the flaw is in your side not on the IETF side! Your flaw is argue that a single phrase in *plain language* or term is a or can be a copyrigthed work "in se"! 1) As matter of fact you can made a "copyrigthed mark" with a common word or phrase but this unaffect my freedom or right of using the term (or the freedom of anyone in this world) except the fact that I cannot made a product or a company with this name. 2) As matter of fact you can have used a term or phrase in copyrigthted document or work or implementation but this unaffect my freedom to use the same term in any other *different* (and... why not...also copyrighted work). The word "copy" before "right" have a "magic" sense here. To be in "violation" I must not only use a single phrase or word. I must "copy" significant parts of the context of the entire work and apply it at the same case or implementation. If *any* of these conditions does not match there is no violation! That's the law my friend and international agreements have made and produced similar criteria and laws in my country in your contry and so on.... And (I repeat to be clear) I will challenge any allegation in any court, in any country of this world about the sole use of the the term " Proof Source Provider" or similar. I and any other person in this world will be free (despite the fact that the term is used or not used in a copyrigthed work) to use the term "Proof Source Provider" and even to use it in another copyrigthed work! But I want no more discuss this topic because i feel that I'm annoyng the other folks in the WG In short if you are cool with your opininion I am cool too with mine :) Remo Tabanelli P.S. I have also (me too) a first hand experience here on an Italian court about the usability of the term "PKI Infrastructure"... (litteraly from Italian language to English). Someone (in Italy) was (in a very past time) attempting to affirm/claim a copyrigth on this! > > So in bringing that term fully inside the IETF as a NoteWell > work-product I was trying to make that pain go away... But hey I get > your concern so if the IETF isnt worried about that I totally > understand and we can just withdraw the offer. > > Have a great day, > Todd Glassey >>> If the term Proof is in fact copyrighted, I would guess that any legal >>> rights were lost long ago by failing to enforce it properly, as it is >>> used >>> by multiple companies and with multiple products. That notwithstanding, >>> the emphasis of my email was not on copyrighted terminology, but rather >>> on >>> the fact that the term might be confused in usage. Carl's comment is >>> perhaps the more important though, does this topic even warrant >>> discussion >>> as part of this group? I apologize for any confusion I may have >>> introduced >>> by my email, as I was merely trying to suggest that the term is >>> overloaded. I think your email continues to make the point that it is >>> in >>> fact not the best for this group to incorporate. >>> >>> Take care, >>> Bill >>> >> >> Bill I fully understand your warning and (at least in part) I agree with >> you... but this is not what I am worried about. >> >> I have not expressed an opinion about the fact that using the term >> proposed by Todd is appropriate or not. >> >> My opinion was simply about the fact that we (the WG) can or cannot use >> the proposed term! >> And clearly I have a very firm opinion about the fact that we can use it >> and... let me reinforce te concept... IMHO if we want (if we, all the >> folks here, agree on it) we can use *any* term we like! >> Disregarding totally the **miserable** "topic" about the pretended >> "copyrighted" term. >> >> "Proof" you said?... >> >> In the real life be sure that I will challenge in any court any >> allegation >> (to me or any of my interest) about the use of a single english word (or >> any language) or common phrase/term like "Proof".... if you (or any >> other) >> pretend the exclusive use of the term (without the entire document or >> context of the *really copyrigthed work*) ... >> >> I will ack on any copyrigthed work but not (repeat not) on any >> "decontestualized" term or word included in the copyrigthed work! >> >> Pretending the exclusive use of a term or single phrase (without a >> contex >> or case specification) is absurd in any *legal system* of this (real) >> world! >> This is *not legal* and not fair! >> And.. yes... maybe I'm wrong but I'm pretty sure that (in the case) I >> will >> be the winner! >> >> Just to explain are you sustaining that because I can read (in many RFC) >> the following: >> "Copyright (C) The Internet Society (xxxx)" >> And, in the same document, terms like "Must" "shall" "Must be" etc.. I >> cannot freely use it (the same terms in any different document) as I >> want? >> >> As example I can use the term "windows" as I want and where I want. >> >> I only must take care of it only (and only if) I talk about a specific >> O.S. or Product(s). >> >> And last (but not least) are we a IETF WG made solely of *individuals* >> or >> a lobby of employes of some corporation claiming some vague "wapor IP" >> on >> some product/document/implementation? >> >> This is what made me sad! >> >> Remo Tabanelli >> >> >>> -----Original Message----- >>> From: Remo Tabanelli [mailto:remo@t-bizcom.com] >>> Sent: Tuesday, September 15, 2009 1:07 PM >>> To: Todd Glassey >>> Cc: Bill Russell; ietf-ltans@imc.org >>> Subject: Re: [ltans] "Proof Source Provider" - new term for use in >>> describing trust chains in document hierarchies >>> >>> On Mar, 15 Settembre 2009 6:21 pm, Todd Glassey wrote: >>> >>>> Bill Russell wrote: >>>> >>>>> We (Pericore) already use that term to express digitally signed >>>>> authorizations. >>>>> >>>> Bummer - its copyrighted and not currently under any license. >>>> >>>>> Also, Corestreet uses that term in one of their products. I think >>>>> the >>>>> term is overloaded and should not be used as you propose. >>>>> >>>>> >>>> The term was used by me officially in print 10 years ago and it was >>>> (c)'d on those works... your general counsel may get a kick out of >>>> that >>>> and I can provide those documents to anyone that wants them. >>>> >>> Bill & Todd >>> >>> Until now... and for more than two years I was silent on this list. >>> and... today I'm very sad. >>> >>> IMHO a discussion in a IETF WG about copyrighted terms (or any other >>> so >>> called I.P. "wapor issue") is misplaced here. >>> >>> I'm not interested in hearing from anyone of us who was the first that >>> used a plain english expression like "Proof Source Provider" because >>> the >>> first source of these terms is the common language... and I suppose you >>> can find anyone of these word on a common dictionary! >>> >>> IMHO a phrase (in any language) is (or must be) without a specific and >>> *explained contest* uncopyrightable. >>> I'ts not realistic pretend to have a copyright on a term (or phrase) >>> without the accluded (and this can be eventually copyrigthed not the >>> single term or phrase) document/work. >>> >>> So if the WG think that using this terms is useful (IMHO) can decide to >>> use it, if not we will not use it. >>> >>> Simply as that. >>> >>> Tank you all folks! >>> >>> Remo Tabanelli >>> >>> >>> >>> >>> >> >> >> ------------------------------------------------------------------------ >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.99/2372 - Release Date: >> 09/15/09 05:59:00 >> >> > From tglassey@earthlink.net Tue Sep 15 15:02:55 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043E33A6918 for ; Tue, 15 Sep 2009 15:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.507 X-Spam-Level: X-Spam-Status: No, score=-4.507 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THDeqTsAXHR8 for ; Tue, 15 Sep 2009 15:02:53 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 6B5BC3A6C05 for ; Tue, 15 Sep 2009 15:02:53 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8FLp1Wf031819 for ; Tue, 15 Sep 2009 14:51:07 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RL9LSa43jtQSbCdqdKubhsroURq3jMuyt/48K21i4no/UgCbkHrMnVwF8t6lD8px; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.104.134.74] (helo=[192.168.1.138]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1MnfvQ-0007qV-Gz; Tue, 15 Sep 2009 17:51:00 -0400 Message-ID: <4AB00C42.9090608@earthlink.net> Date: Tue, 15 Sep 2009 14:50:58 -0700 From: Todd Glassey User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: remo@t-bizcom.com References: <9DCCF5807745F9438462F1F6A66CADA403203A35D5@MAILR003.mail.lan> <4AAFBEF3.8060607@earthlink.net> <24910.93.41.185.139.1253034396.squirrel@ns2.t-bizcom.com> <9DCCF5807745F9438462F1F6A66CADA403202E158F@MAILR003.mail.lan> <25507.93.41.185.139.1253041674.squirrel@ns2.t-bizcom.com> <4AAFEF5C.6070604@earthlink.net> <25891.93.41.185.139.1253047821.squirrel@ns2.t-bizcom.com> In-Reply-To: <25891.93.41.185.139.1253047821.squirrel@ns2.t-bizcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b19b6614bb2314ffa4107cbfd4bd2857350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.104.134.74 Cc: "ietf-ltans@imc.org" Subject: Re: [ltans] "Proof Source Provider" - new term for use in describing trust chains in document hierarchies X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 22:02:55 -0000 Remo Tabanelli wrote: > On Mar, 15 Settembre 2009 9:47 pm, Todd Glassey wrote: > >> Remo Tabanelli wrote: >> >>> On Mar, 15 Settembre 2009 7:53 pm, Bill Russell wrote: >>> >>> >>>> Hi Todd & Remo, >>>> >>>> >> Remo >> having personally taken a matter to the US Supreme Court (case >> #08-01088) , it aint anywhere as easy as we think it should be. And to >> reinforce this, I am saying a 100 Page publication for the Supreme Court >> will cost about $10K to publish including the $40/Page typesetting fees >> for the final copy and the building of the various Tables at $100 a page >> or more for the typesetting alone. The figure in the binding cost and >> cost of submit to the Court ($300 + courier fees), and since I speak >> from first hand experience arguing this is pointless. >> >> That aside, the IETF relies on its research exemption under section 107 >> of the DCMA to allow it to talk about anything it likes - and that's the >> problem here since the users of the IETF standards are not legally >> allowed to use that code or IP in the real world just because the IETF >> told them they could reprint the standards-effort paperwork and content. >> >> It's one of the flaws in the logic the IETF puts forward. The IETF's >> license is not about anything other than the publication for the >> standards process and whether the people using those to implement code >> or not realize it the IETF cannot provide a right-to-use status on >> copyrighted work they dont own no matter what. Representing that they >> would or could do so may also be a criminal act of electronic fraud in >> this case in my opinion. >> > > No Todd! > Let me say (friendly) that the flaw is in your side not on the IETF side! > No Remo its not. The flaw here is in your argument. You clearly also want to argue about this and I don't - I made the offer to the IETF to help clean things up but I honestly would rather not waste timing arguing with your opinion. So as I said last time consider the offer withdrawn. Todd Glassey > Your flaw is argue that a single phrase in *plain language* or term is a > or can be a copyrigthed work "in se"! > > 1) As matter of fact you can made a "copyrigthed mark" with a common word > or phrase but this unaffect my freedom or right of using the term (or the > freedom of anyone in this world) except the fact that I cannot made a > product or a company with this name. > > 2) As matter of fact you can have used a term or phrase in copyrigthted > document or work or implementation but this unaffect my freedom to use the > same term in any other *different* (and... why not...also copyrighted > work). > > The word "copy" before "right" have a "magic" sense here. > > To be in "violation" I must not only use a single phrase or word. > I must "copy" significant parts of the context of the entire work and > apply it at the same case or implementation. > If *any* of these conditions does not match there is no violation! > > That's the law my friend and international agreements have made and > produced similar criteria and laws in my country in your contry and so > on.... > > And (I repeat to be clear) I will challenge any allegation in any court, > in any country of this world about the sole use of the the term " Proof > Source Provider" or similar. > > I and any other person in this world will be free (despite the fact that > the term is used or not used in a copyrigthed work) to use the term > "Proof Source Provider" and even to use it in another copyrigthed work! > > But I want no more discuss this topic because i feel that I'm annoyng the > other folks in the WG > > In short if you are cool with your opininion I am cool too with mine :) > > Remo Tabanelli > > P.S. I have also (me too) a first hand experience here on an Italian court > about the usability of the term "PKI Infrastructure"... (litteraly from > Italian language to English). > Someone (in Italy) was (in a very past time) attempting to affirm/claim a > copyrigth on this! > > >> So in bringing that term fully inside the IETF as a NoteWell >> work-product I was trying to make that pain go away... But hey I get >> your concern so if the IETF isnt worried about that I totally >> understand and we can just withdraw the offer. >> >> Have a great day, >> Todd Glassey >> >>>> If the term Proof is in fact copyrighted, I would guess that any legal >>>> rights were lost long ago by failing to enforce it properly, as it is >>>> used >>>> by multiple companies and with multiple products. That notwithstanding, >>>> the emphasis of my email was not on copyrighted terminology, but rather >>>> on >>>> the fact that the term might be confused in usage. Carl's comment is >>>> perhaps the more important though, does this topic even warrant >>>> discussion >>>> as part of this group? I apologize for any confusion I may have >>>> introduced >>>> by my email, as I was merely trying to suggest that the term is >>>> overloaded. I think your email continues to make the point that it is >>>> in >>>> fact not the best for this group to incorporate. >>>> >>>> Take care, >>>> Bill >>>> >>>> >>> Bill I fully understand your warning and (at least in part) I agree with >>> you... but this is not what I am worried about. >>> >>> I have not expressed an opinion about the fact that using the term >>> proposed by Todd is appropriate or not. >>> >>> My opinion was simply about the fact that we (the WG) can or cannot use >>> the proposed term! >>> And clearly I have a very firm opinion about the fact that we can use it >>> and... let me reinforce te concept... IMHO if we want (if we, all the >>> folks here, agree on it) we can use *any* term we like! >>> Disregarding totally the **miserable** "topic" about the pretended >>> "copyrighted" term. >>> >>> "Proof" you said?... >>> >>> In the real life be sure that I will challenge in any court any >>> allegation >>> (to me or any of my interest) about the use of a single english word (or >>> any language) or common phrase/term like "Proof".... if you (or any >>> other) >>> pretend the exclusive use of the term (without the entire document or >>> context of the *really copyrigthed work*) ... >>> >>> I will ack on any copyrigthed work but not (repeat not) on any >>> "decontestualized" term or word included in the copyrigthed work! >>> >>> Pretending the exclusive use of a term or single phrase (without a >>> contex >>> or case specification) is absurd in any *legal system* of this (real) >>> world! >>> This is *not legal* and not fair! >>> And.. yes... maybe I'm wrong but I'm pretty sure that (in the case) I >>> will >>> be the winner! >>> >>> Just to explain are you sustaining that because I can read (in many RFC) >>> the following: >>> "Copyright (C) The Internet Society (xxxx)" >>> And, in the same document, terms like "Must" "shall" "Must be" etc.. I >>> cannot freely use it (the same terms in any different document) as I >>> want? >>> >>> As example I can use the term "windows" as I want and where I want. >>> >>> I only must take care of it only (and only if) I talk about a specific >>> O.S. or Product(s). >>> >>> And last (but not least) are we a IETF WG made solely of *individuals* >>> or >>> a lobby of employes of some corporation claiming some vague "wapor IP" >>> on >>> some product/document/implementation? >>> >>> This is what made me sad! >>> >>> Remo Tabanelli >>> >>> >>> >>>> -----Original Message----- >>>> From: Remo Tabanelli [mailto:remo@t-bizcom.com] >>>> Sent: Tuesday, September 15, 2009 1:07 PM >>>> To: Todd Glassey >>>> Cc: Bill Russell; ietf-ltans@imc.org >>>> Subject: Re: [ltans] "Proof Source Provider" - new term for use in >>>> describing trust chains in document hierarchies >>>> >>>> On Mar, 15 Settembre 2009 6:21 pm, Todd Glassey wrote: >>>> >>>> >>>>> Bill Russell wrote: >>>>> >>>>> >>>>>> We (Pericore) already use that term to express digitally signed >>>>>> authorizations. >>>>>> >>>>>> >>>>> Bummer - its copyrighted and not currently under any license. >>>>> >>>>> >>>>>> Also, Corestreet uses that term in one of their products. I think >>>>>> the >>>>>> term is overloaded and should not be used as you propose. >>>>>> >>>>>> >>>>>> >>>>> The term was used by me officially in print 10 years ago and it was >>>>> (c)'d on those works... your general counsel may get a kick out of >>>>> that >>>>> and I can provide those documents to anyone that wants them. >>>>> >>>>> >>>> Bill & Todd >>>> >>>> Until now... and for more than two years I was silent on this list. >>>> and... today I'm very sad. >>>> >>>> IMHO a discussion in a IETF WG about copyrighted terms (or any other >>>> so >>>> called I.P. "wapor issue") is misplaced here. >>>> >>>> I'm not interested in hearing from anyone of us who was the first that >>>> used a plain english expression like "Proof Source Provider" because >>>> the >>>> first source of these terms is the common language... and I suppose you >>>> can find anyone of these word on a common dictionary! >>>> >>>> IMHO a phrase (in any language) is (or must be) without a specific and >>>> *explained contest* uncopyrightable. >>>> I'ts not realistic pretend to have a copyright on a term (or phrase) >>>> without the accluded (and this can be eventually copyrigthed not the >>>> single term or phrase) document/work. >>>> >>>> So if the WG think that using this terms is useful (IMHO) can decide to >>>> use it, if not we will not use it. >>>> >>>> Simply as that. >>>> >>>> Tank you all folks! >>>> >>>> Remo Tabanelli >>>> >>>> >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 8.5.409 / Virus Database: 270.13.99/2372 - Release Date: >>> 09/15/09 05:59:00 >>> >>> >>> > > > ------------------------------------------------------------------------ > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 8.5.409 / Virus Database: 270.13.99/2372 - Release Date: 09/15/09 05:59:00 > > From root@core3.amsl.com Wed Sep 30 01:00:01 2009 Return-Path: X-Original-To: ltans@ietf.org Delivered-To: ltans@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BFBB73A6A1C; Wed, 30 Sep 2009 01:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090930080001.BFBB73A6A1C@core3.amsl.com> Date: Wed, 30 Sep 2009 01:00:01 -0700 (PDT) X-Mailman-Approved-At: Wed, 30 Sep 2009 03:36:44 -0700 Cc: ltans@ietf.org Subject: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 08:00:01 -0000 --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 : Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) Author(s) : T. Kunz, et al. Filename : draft-ietf-ltans-dssc-12.txt Pages : 48 Date : 2009-09-30 Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time which may be in the past, at the present time or in the future.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ltans-dssc-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-30004748.I-D@ietf.org> --NextPart-- From ErnstG.Giessmann@t-systems.com Wed Sep 30 07:09:45 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1BAE3A67DF for ; Wed, 30 Sep 2009 07:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2X1AwOAghbe for ; Wed, 30 Sep 2009 07:09:44 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id E960F3A676A for ; Wed, 30 Sep 2009 07:09:43 -0700 (PDT) From: Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 30 Sep 2009 16:10:59 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 16:10:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Sep 2009 16:10:57 +0200 Message-ID: <410895869A205548A19FE0746861331C041B5939@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <20090930080001.BFBB73A6A1C@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt Thread-Index: AcpBvNy1JYJ+//k+TGih5sVPz/rGlgAEiLmw References: <20090930080001.BFBB73A6A1C@core3.amsl.com> To: X-OriginalArrivalTime: 30 Sep 2009 14:10:58.0620 (UTC) FILETIME=[D5525FC0:01CA41D7] Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 14:09:45 -0000 Hi all, there are some clashes in the ASN.1 code of the draft that prevents to = use it with e.g. RFC3280/RFC5280. 1. The Draft defines -- Extension ::=3D SEQUENCE { -- extensionType OBJECT IDENTIFIER, -- extension ANY DEFINED BY extensionType -- } which has a (presumably better defined) twin in RFC5280: Extension ::=3D SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID } I suggest to import the type Extension from PKIX1Explicit88. Please take = into account that already since 1997 the ASN.1 types ANY/ANY DEFINED BY = are deprecated = (http://www.itu.int/ITU-T/studygroups/com07/changing-ASN.html). 2.=20 The Draft defines -- Validity ::=3D SEQUENCE { -- start [0] GeneralizedTime OPTIONAL, -- end [1] GeneralizedTime OPTIONAL -- } which clashes also with a twin in RFC3280/RFC5280: Validity ::=3D SEQUENCE { notBefore Time, notAfter Time } It seems to me that this is based on a misunderstanding already in = section 1.1 (Motivation) Cryptographic algorithms that are used in signatures shall be selected to resist such attacks during their period of use. For signature keys included in public key certificates, it is the validity period of the certificate. Cryptographic algorithms that are used for encryption shall resist during the time during which it is planned to keep the information confidential. The validity period of a certificate is primarily *not* a period where = resistance against attacks is assured but "is the time interval during = which the CA warrants that it will maintain information about the status = of the certificate". If the signatures are made in a authentication = context, then the validity is almost the same as the usage time. But if = the signatures are related to a non-repudiation context then the = documented in the certificate validity time may be longer then predicted = at time of certificate generation. If the algorithm becomes weaker then = the certificate can be easily revoked, which reduces the "usage time" = immediately, leaving the "warranty time" unchanged. If on the other side = it turned out that the algorithm is harder than predicted, it is not = necessary to revoke the certificate based on a still secure algorithm. Just another thought: For a certificate the dates notBefore and notAfter = make sense. But how we understand the notBefore date for algorithm = resistance? A certificate may become valid later, but how a weak = algorithm may become hard after a while? I would suggest to remove the Validity type and replace it by a single = notAfter date. Regards, Ernst. -- Ernst G Giessmann T-Systems Enterprise Services GmbH ICT Operations Security and Smart Card Solutions Goslarer Ufer 35, D-10589 Berlin tel:+49-30-3497-4342 Legal Notice T-Systems Enterprise Services GmbH Supervisory Board: Ren=E9 Obermann (Chairman) Executive Committee: Reinhard Clemens (Chairman),=20 Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack,=20 Dr. Matthias Schuster, Klaus Werner Commercial Register: Amtsgericht Frankfurt am Main, HRB 55933 Registered Office: Frankfurt am Main WEEE-Reg.-No. DE87523644 Importante Notice:=20 If you received this transmittal in error, please notify us=20 immediately, and delete this message and its attachments.=20 Thank you. =20 > -----Urspr=FCngliche Nachricht----- > Von: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org]=20 > Im Auftrag von Internet-Drafts@ietf.org > Gesendet: Mittwoch, 30. September 2009 10:00 > An: i-d-announce@ietf.org > Cc: ltans@ietf.org > Betreff: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Long-Term Archive and Notary=20 > Services Working Group of the IETF. >=20 >=20 > Title : Data Structure for the Security=20 > Suitability of Cryptographic Algorithms (DSSC) > Author(s) : T. Kunz, et al. > Filename : draft-ietf-ltans-dssc-12.txt > Pages : 48 > Date : 2009-09-30 >=20 > Since cryptographic algorithms can become weak over the=20 > years, it is necessary to evaluate their security=20 > suitability. When signing or verifying data, or when=20 > encrypting or decrypting data, these evaluations must be=20 > considered. This document specifies a data structure that=20 > enables an automated analysis of the security suitability of=20 > a given cryptographic algorithm at a given point of time=20 > which may be in the past, at the present time or in the=20 > future.Conventions used in this document ... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-12.txt ... From brussell@pericore.com Wed Sep 30 08:37:54 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82BDB3A6898 for ; Wed, 30 Sep 2009 08:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.802 X-Spam-Level: X-Spam-Status: No, score=-3.802 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQVq3qCnz3fE for ; Wed, 30 Sep 2009 08:37:53 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 1A2E23A67BD for ; Wed, 30 Sep 2009 08:37:52 -0700 (PDT) Received: from BH001.mail.lan ([10.110.21.101]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 11:39:15 -0400 Received: from HUB010.mail.lan ([10.110.17.10]) by BH001.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 11:39:06 -0400 Received: from HUB014.mail.lan (10.110.17.14) by HUB010.mail.lan (10.110.17.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 30 Sep 2009 11:39:06 -0400 Received: from MAILR003.mail.lan ([10.110.18.20]) by HUB014.mail.lan ([10.110.17.14]) with mapi; Wed, 30 Sep 2009 11:39:05 -0400 From: Bill Russell To: "ErnstG.Giessmann@t-systems.com" , "ltans@ietf.org" Date: Wed, 30 Sep 2009 11:39:11 -0400 Thread-Topic: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt Thread-Index: AcpBvNy1JYJ+//k+TGih5sVPz/rGlgAEiLmwAAUm2LA= Message-ID: <9DCCF5807745F9438462F1F6A66CADA4032059B465@MAILR003.mail.lan> References: <20090930080001.BFBB73A6A1C@core3.amsl.com> <410895869A205548A19FE0746861331C041B5939@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <410895869A205548A19FE0746861331C041B5939@S4DE9JSAAIG.ost.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Sep 2009 15:39:06.0253 (UTC) FILETIME=[24FF23D0:01CA41E4] Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 15:37:54 -0000 I propose that we just change the name in our draft but keep the new defini= tions. For the Validity, GeneralizedTime IMHO is better than Time, since th= e current year would still code as UTCTime as part of that def (making it a= two digit year rather than four until something like 2050). And, if there = is no use for a criticality field, there is no sense in reusing that defini= tion for extensions. -----Original Message----- From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf Of E= rnstG.Giessmann@t-systems.com Sent: Wednesday, September 30, 2009 10:11 AM To: ltans@ietf.org Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt Hi all, there are some clashes in the ASN.1 code of the draft that prevents to use = it with e.g. RFC3280/RFC5280. 1. The Draft defines -- Extension ::=3D SEQUENCE { -- extensionType OBJECT IDENTIFIER, -- extension ANY DEFINED BY extensionType -- } which has a (presumably better defined) twin in RFC5280: Extension ::=3D SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING -- contains the DER encoding of an ASN.1 value -- corresponding to the extension type identified -- by extnID } I suggest to import the type Extension from PKIX1Explicit88. Please take in= to account that already since 1997 the ASN.1 types ANY/ANY DEFINED BY are d= eprecated (http://www.itu.int/ITU-T/studygroups/com07/changing-ASN.html). 2.=20 The Draft defines -- Validity ::=3D SEQUENCE { -- start [0] GeneralizedTime OPTIONAL, -- end [1] GeneralizedTime OPTIONAL -- } which clashes also with a twin in RFC3280/RFC5280: Validity ::=3D SEQUENCE { notBefore Time, notAfter Time } It seems to me that this is based on a misunderstanding already in section = 1.1 (Motivation) Cryptographic algorithms that are used in signatures shall be selected to resist such attacks during their period of use. For signature keys included in public key certificates, it is the validity period of the certificate. Cryptographic algorithms that are used for encryption shall resist during the time during which it is planned to keep the information confidential. The validity period of a certificate is primarily *not* a period where resi= stance against attacks is assured but "is the time interval during which th= e CA warrants that it will maintain information about the status of the cer= tificate". If the signatures are made in a authentication context, then the= validity is almost the same as the usage time. But if the signatures are r= elated to a non-repudiation context then the documented in the certificate = validity time may be longer then predicted at time of certificate generatio= n. If the algorithm becomes weaker then the certificate can be easily revok= ed, which reduces the "usage time" immediately, leaving the "warranty time"= unchanged. If on the other side it turned out that the algorithm is harder= than predicted, it is not necessary to revoke the certificate based on a s= till secure algorithm. Just another thought: For a certificate the dates notBefore and notAfter ma= ke sense. But how we understand the notBefore date for algorithm resistance= ? A certificate may become valid later, but how a weak algorithm may become= hard after a while? I would suggest to remove the Validity type and replace it by a single notA= fter date. Regards, Ernst. -- Ernst G Giessmann T-Systems Enterprise Services GmbH ICT Operations Security and Smart Card Solutions Goslarer Ufer 35, D-10589 Berlin tel:+49-30-3497-4342 Legal Notice T-Systems Enterprise Services GmbH Supervisory Board: Ren=E9 Obermann (Chairman) Executive Committee: Reinhard Clemens (Chairman),=20 Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack,=20 Dr. Matthias Schuster, Klaus Werner Commercial Register: Amtsgericht Frankfurt am Main, HRB 55933 Registered Office: Frankfurt am Main WEEE-Reg.-No. DE87523644 Importante Notice:=20 If you received this transmittal in error, please notify us=20 immediately, and delete this message and its attachments.=20 Thank you. =20 > -----Urspr=FCngliche Nachricht----- > Von: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org]=20 > Im Auftrag von Internet-Drafts@ietf.org > Gesendet: Mittwoch, 30. September 2009 10:00 > An: i-d-announce@ietf.org > Cc: ltans@ietf.org > Betreff: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Long-Term Archive and Notary=20 > Services Working Group of the IETF. >=20 >=20 > Title : Data Structure for the Security=20 > Suitability of Cryptographic Algorithms (DSSC) > Author(s) : T. Kunz, et al. > Filename : draft-ietf-ltans-dssc-12.txt > Pages : 48 > Date : 2009-09-30 >=20 > Since cryptographic algorithms can become weak over the=20 > years, it is necessary to evaluate their security=20 > suitability. When signing or verifying data, or when=20 > encrypting or decrypting data, these evaluations must be=20 > considered. This document specifies a data structure that=20 > enables an automated analysis of the security suitability of=20 > a given cryptographic algorithm at a given point of time=20 > which may be in the past, at the present time or in the=20 > future.Conventions used in this document ... > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-12.txt ... _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans From wwwrun@core3.amsl.com Wed Sep 30 12:51:46 2009 Return-Path: X-Original-To: ltans@ietf.org Delivered-To: ltans@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id C6FA63A69DA; Wed, 30 Sep 2009 12:51:46 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090930195146.C6FA63A69DA@core3.amsl.com> Date: Wed, 30 Sep 2009 12:51:46 -0700 (PDT) Cc: ltans chair , Internet Architecture Board , ltans mailing list , RFC Editor Subject: [ltans] Protocol Action: 'Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)' to Proposed Standard X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 19:51:46 -0000 The IESG has approved the following document: - 'Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) ' as a Proposed Standard This document is the product of the Long-Term Archive and Notary Services Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-12.txt Technical Summary Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time which may be in the past, at the present time or in the future. Working Group Summary This document is a product of the ltans working group. There was little controversy regarding this draft.  There were some structural changes to the schema following an earlier working group last call but no significant comments recently. Document Quality There is one known current implementation. The implementation is part of the long-term archiving solution ‘ArchiSoft’ (http://www.sit.fraunhofer.de/EN/forschungsbereich/tad/archisoft.jsp). There was another implementation of an earlier version: https://demo.pkipreserver.com/index.html.  This may be updated and released as part of a related open source library: http://www.pkiframework.com/.  Plans of other vendors to implement the specification are not known. There were no reviewers, Media Types or other expert reviews. Personnel Carl Wallace is the Document Shepherd for this document. The Responsible Area Director is Tim Polk. From cwallace@cygnacom.com Wed Sep 30 13:20:19 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2F83A6840 for ; Wed, 30 Sep 2009 13:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHNzyUegPX6x for ; Wed, 30 Sep 2009 13:20:17 -0700 (PDT) Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by core3.amsl.com (Postfix) with ESMTP id 477043A6992 for ; Wed, 30 Sep 2009 13:20:17 -0700 (PDT) Received: from unknown [65.242.48.5] (EHLO p03c11o141.symantecmail.net) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 5ddb3ca4.2688514992.5763.00-505.p03c11o141.symantecmail.net (envelope-from ); Wed, 30 Sep 2009 14:21:41 -0600 (MDT) Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 2ddb3ca4.2247941040.5739.00-017.p03c11o141.symantecmail.net (envelope-from ); Wed, 30 Sep 2009 14:21:38 -0600 (MDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 30 Sep 2009 16:21:35 -0400 Message-ID: In-Reply-To: <9DCCF5807745F9438462F1F6A66CADA4032059B465@MAILR003.mail.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt Thread-Index: AcpBvNy1JYJ+//k+TGih5sVPz/rGlgAEiLmwAAUm2LAACfU2EA== References: <20090930080001.BFBB73A6A1C@core3.amsl.com><410895869A205548A19FE0746861331C041B5939@S4DE9JSAAIG.ost.t-com.de> <9DCCF5807745F9438462F1F6A66CADA4032059B465@MAILR003.mail.lan> From: "Carl Wallace" To: "Bill Russell" , , X-Spam: [F=0.2000000000; S=0.200(2009092101)] X-MAIL-FROM: X-SOURCE-IP: [65.242.48.5] Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 20:20:19 -0000 I think the name change suggestion is fine. This can be handled during = the AUTH48 period for this draft, which cleared IESG review today as = this draft addressed the last of the issues. > -----Original Message----- > From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf > Of Bill Russell > Sent: Wednesday, September 30, 2009 11:39 AM > To: ErnstG.Giessmann@t-systems.com; ltans@ietf.org > Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >=20 > I propose that we just change the name in our draft but keep the new > definitions. For the Validity, GeneralizedTime IMHO is better than > Time, since the current year would still code as UTCTime as part of > that def (making it a two digit year rather than four until something > like 2050). And, if there is no use for a criticality field, there is > no sense in reusing that definition for extensions. >=20 > -----Original Message----- > From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf > Of ErnstG.Giessmann@t-systems.com > Sent: Wednesday, September 30, 2009 10:11 AM > To: ltans@ietf.org > Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >=20 > Hi all, > there are some clashes in the ASN.1 code of the draft that prevents to > use it with e.g. RFC3280/RFC5280. >=20 > 1. > The Draft defines > -- Extension ::=3D SEQUENCE { > -- extensionType OBJECT IDENTIFIER, > -- extension ANY DEFINED BY extensionType > -- } >=20 > which has a (presumably better defined) twin in RFC5280: > Extension ::=3D SEQUENCE { > extnID OBJECT IDENTIFIER, > critical BOOLEAN DEFAULT FALSE, > extnValue OCTET STRING > -- contains the DER encoding of an ASN.1 value > -- corresponding to the extension type identified > -- by extnID > } >=20 > I suggest to import the type Extension from PKIX1Explicit88. Please > take into account that already since 1997 the ASN.1 types ANY/ANY > DEFINED BY are deprecated (http://www.itu.int/ITU- > T/studygroups/com07/changing-ASN.html). >=20 >=20 > 2. > The Draft defines > -- Validity ::=3D SEQUENCE { > -- start [0] GeneralizedTime OPTIONAL, > -- end [1] GeneralizedTime OPTIONAL > -- } >=20 > which clashes also with a twin in RFC3280/RFC5280: >=20 > Validity ::=3D SEQUENCE { > notBefore Time, > notAfter Time } >=20 > It seems to me that this is based on a misunderstanding already in > section 1.1 (Motivation) >=20 > Cryptographic algorithms that are used in signatures shall be > selected to resist such attacks during their period of use. For > signature keys included in public key certificates, it is the > validity period of the certificate. Cryptographic algorithms that > are used for encryption shall resist during the time during which = it > is planned to keep the information confidential. >=20 > The validity period of a certificate is primarily *not* a period where > resistance against attacks is assured but "is the time interval during > which the CA warrants that it will maintain information about the > status of the certificate". If the signatures are made in a > authentication context, then the validity is almost the same as the > usage time. But if the signatures are related to a non-repudiation > context then the documented in the certificate validity time may be > longer then predicted at time of certificate generation. If the > algorithm becomes weaker then the certificate can be easily revoked, > which reduces the "usage time" immediately, leaving the "warranty = time" > unchanged. If on the other side it turned out that the algorithm is > harder than predicted, it is not necessary to revoke the certificate > based on a still secure algorithm. >=20 > Just another thought: For a certificate the dates notBefore and > notAfter make sense. But how we understand the notBefore date for > algorithm resistance? A certificate may become valid later, but how a > weak algorithm may become hard after a while? >=20 > I would suggest to remove the Validity type and replace it by a single > notAfter date. >=20 > Regards, > Ernst. > -- > Ernst G Giessmann > T-Systems Enterprise Services GmbH > ICT Operations > Security and Smart Card Solutions > Goslarer Ufer 35, D-10589 Berlin > tel:+49-30-3497-4342 >=20 > Legal Notice > T-Systems Enterprise Services GmbH > Supervisory Board: Ren=E9 Obermann (Chairman) > Executive Committee: Reinhard Clemens (Chairman), > Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack, > Dr. Matthias Schuster, Klaus Werner >=20 > Commercial Register: Amtsgericht Frankfurt am Main, HRB 55933 > Registered Office: Frankfurt am Main > WEEE-Reg.-No. DE87523644 >=20 > Importante Notice: > If you received this transmittal in error, please notify us > immediately, and delete this message and its attachments. > Thank you. >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] > > Im Auftrag von Internet-Drafts@ietf.org > > Gesendet: Mittwoch, 30. September 2009 10:00 > > An: i-d-announce@ietf.org > > Cc: ltans@ietf.org > > Betreff: [ltans] I-D Action:draft-ietf-ltans-dssc-12.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 : Data Structure for the Security > > Suitability of Cryptographic Algorithms (DSSC) > > Author(s) : T. Kunz, et al. > > Filename : draft-ietf-ltans-dssc-12.txt > > Pages : 48 > > Date : 2009-09-30 > > > > Since cryptographic algorithms can become weak over the > > years, it is necessary to evaluate their security > > suitability. When signing or verifying data, or when > > encrypting or decrypting data, these evaluations must be > > considered. This document specifies a data structure that > > enables an automated analysis of the security suitability of > > a given cryptographic algorithm at a given point of time > > which may be in the past, at the present time or in the > > future.Conventions used in this document >=20 > ... > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-12.txt > ... > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans