From owner-ietf-ltans@mail.imc.org Mon Dec 03 19:51:26 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzM0U-00013V-TY for ltans-archive-ba2WohFa@lists.ietf.org; Mon, 03 Dec 2007 19:51:26 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzM0T-0007Fo-AW for ltans-archive-ba2WohFa@lists.ietf.org; Mon, 03 Dec 2007 19:51:26 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB40e4Vf033291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 17:40:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB40e457033290; Mon, 3 Dec 2007 17:40:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB40e2Pb033281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Dec 2007 17:40:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 497A332928; Tue, 4 Dec 2007 00:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzLpS-00086j-5Y; Mon, 03 Dec 2007 19:40:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ltans-xmlers-01.txt Message-Id: Date: Mon, 03 Dec 2007 19:40:02 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --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 : Extensible Markup Language Evidence Record Syntax Author(s) : A. Blazic, et al. Filename : draft-ietf-ltans-xmlers-01.txt Pages : 36 Date : 2007-12-03 In many scenarios, users must be able to demonstrate the (time) existence, integrity and validity of data including signed data for long or undetermined period of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence of data. ERS-XML incorporates alternative syntax and processing rules to ASN.1 ERS syntax by using XML language. 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-xmlers-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-xmlers-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-xmlers-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-03193448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-xmlers-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-xmlers-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-03193448.I-D\@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ltans@mail.imc.org Tue Dec 04 21:49:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzkKf-0008Qb-H9 for ltans-archive-ba2WohFa@lists.ietf.org; Tue, 04 Dec 2007 21:49:53 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzkKe-0001Zx-0E for ltans-archive-ba2WohFa@lists.ietf.org; Tue, 04 Dec 2007 21:49:53 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB52b6vX067975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 19:37:06 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB52b6wj067974; Tue, 4 Dec 2007 19:37:06 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp104.biz.mail.mud.yahoo.com (smtp104.biz.mail.mud.yahoo.com [68.142.200.252]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB52b5Ij067968 for ; Tue, 4 Dec 2007 19:37:05 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 18027 invoked from network); 5 Dec 2007 02:36:59 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.18.223 with login) by smtp104.biz.mail.mud.yahoo.com with SMTP; 5 Dec 2007 02:36:59 -0000 X-YMail-OSG: IerVI18VM1ktPhv1k_u13zb68Y7dkJ4DT66EniZncgCTa1TNoqf5VxJodKkqlCvfvbRnYTPjuw-- From: "Turner, Sean P." To: Subject: comment on draft-ietf-ltans-dssc-01.txt Date: Tue, 4 Dec 2007 18:32:46 -0800 Organization: IECA, Inc. Message-ID: <001201c836e7$1f82a4e0$df128182@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg25x6PW88UK/8NRKWtWCH61Adr+A== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da I'm only commenting on the Parameter structure in the ASN.1. I think that it might be better to change Algorithm to be a sequence of algorithmIdentifier, validity, and information - call it AlgorithmValidityInfo. I suggest this for two reasons: 1. The AlgorithmIdentifier structure that is used to assign an algorithm's object identifier also define the parameters. So it probably makes sense to reuse this structure. 2. The parameters structures for some of the newer algorithms is quite complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs [RFC3279] aren't just an OID they are nested structure. (not sure how to do it in XML) Replace: Algorithm ::= SEQUENCE { algorithmIdentifier AlgID, parameters [0] SEQUENCE OF Parameter OPTIONAL, validity [1] Validity, information [2] SEQUENCE OF UTF8String OPTIONAL } AlgID ::= SEQUENCE { name UTF8String, oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, uri [1] SEQUENCE OF IA5String OPTIONAL } Parameter ::= SEQUENCE { name UTF8String, constraint CHOICE { exact [0] OCTET STRING, min [1] OCTET STRING, max [2] OCTET STRING, range [3] Range, other [4] OtherConstraints } } With: AlgorithmValidityInfo ::= SEQUENCE { identifier AlgorithmIdentifier, validity Validity OPTIONAL, information Information OPTIONAL } Validity ::= SEQUENCE { start [0] GeneralizedTime OPTIONAL, end [1] GeneralizedTime OPTIONAL } Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String -- From RFC3280 AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } -- contains a value of the type -- registered for use with the -- algorithm object identifier value spt From owner-ietf-ltans@mail.imc.org Wed Dec 05 08:56:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izujl-0000AQ-JT for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 08:56:29 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izujj-0006UZ-R7 for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 08:56:29 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5DfI2m018945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 06:41:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5DfIbs018944; Wed, 5 Dec 2007 06:41:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from fortress.oss.com (fortress.oss.com [66.146.12.63]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5DfHWf018937 for ; Wed, 5 Dec 2007 06:41:17 -0700 (MST) (envelope-from thorpe@oss.com) Received: from fortress (fortress [192.168.2.1]) by fortress.oss.com (8.13.8+Sun/8.13.8) with ESMTP id lB5Df9kE001072; Wed, 5 Dec 2007 05:41:14 -0800 (PST) Date: Wed, 5 Dec 2007 05:41:09 -0800 (PST) From: Paul Thorpe To: "Turner, Sean P." cc: ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt In-Reply-To: <001201c836e7$1f82a4e0$df128182@Wylie> Message-ID: References: <001201c836e7$1f82a4e0$df128182@Wylie> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 On Tue, 4 Dec 2007, Turner, Sean P. wrote: > > I'm only commenting on the Parameter structure in the ASN.1. I think that it > might be better to change Algorithm to be a sequence of algorithmIdentifier, > validity, and information - call it AlgorithmValidityInfo. I suggest this > for two reasons: > > 1. The AlgorithmIdentifier structure that is used to assign an algorithm's > object identifier also define the parameters. So it probably makes sense to > reuse this structure. > > 2. The parameters structures for some of the newer algorithms is quite > complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs [RFC3279] > aren't just an OID they are nested structure. > > (not sure how to do it in XML) > > Replace: > > Algorithm ::= SEQUENCE { > algorithmIdentifier AlgID, > parameters [0] SEQUENCE OF Parameter OPTIONAL, > validity [1] Validity, > information [2] SEQUENCE OF UTF8String OPTIONAL > } > > AlgID ::= SEQUENCE { > name UTF8String, > oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > uri [1] SEQUENCE OF IA5String OPTIONAL > } > > Parameter ::= SEQUENCE { > name UTF8String, > constraint CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints > } > } > > With: > > AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > validity Validity OPTIONAL, > information Information OPTIONAL } > > Validity ::= SEQUENCE { > start [0] GeneralizedTime OPTIONAL, > end [1] GeneralizedTime OPTIONAL } > > Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > > -- From RFC3280 > AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > -- contains a value of the type > -- registered for use with the > -- algorithm object identifier value > > spt > The ASN.1 type "ANY DEFINED BY" was withdrawn from ASN.1 in 1994 and replaced with the "open type" which allows ASN.1 compilers to explicitly link the contents of the "open type" field with the object identifier. For example try the following: SOMECLASS ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type } AlgorithmIdentifier ::= SEQUENCE { algorithm SOMECLASS.&id ({SomeTable}), parameters SOMECLASS.&Type ({SomeTable}{@algorithm}) } SomeTable SOMECLASS ::= { { &id oid1, &Type TypeForOid1 } | { &id oid2, &Type TypeForOid2 }, ... } The bits on the wire will be identical to the old ANY DEFINED BY, but you can explicitly list the types that particular oids correspond to. An ASN.1 Tool can automatically handle this for you rather than every implementer needing to hand code the table linking the list of object identifiers to a specific ASN.1 type for the parameter. Again, the key is that the bits on the wire are identical, but good ASN.1 Tools can take advantage of the table to make programmers tasks easier and less error prone. Note that "SomeTable" can be either completely specific in the specification, or it can have rows added or removed dynamically at runtime if desired. I recommend using the "open type" instead of the "ANY DEFINED BY" which was withdrawn from ASN.1 in 1994. Paul Thorpe thorpe@oss.com From owner-ietf-ltans@mail.imc.org Wed Dec 05 09:42:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzvRp-0003qD-IG for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 09:42:01 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzvRn-0007TF-Ly for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 09:42:01 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5ETnAD022688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 07:29:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5ETn8Q022687; Wed, 5 Dec 2007 07:29:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5ETmLT022679 for ; Wed, 5 Dec 2007 07:29:49 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 25E3C57; Wed, 5 Dec 2007 15:29:47 +0100 (CET) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14056-05; Wed, 5 Dec 2007 15:29:44 +0100 (CET) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id ACA9556; Wed, 5 Dec 2007 15:29:44 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007120515294382:153348 ; Wed, 5 Dec 2007 15:29:43 +0100 Message-ID: <4756B5D7.7010407@edelweb.fr> Date: Wed, 05 Dec 2007 15:29:43 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Paul Thorpe Cc: "Turner, Sean P." , ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 12/05/2007 03:29:44 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 12/05/2007 03:29:44 PM, Serialize complete at 12/05/2007 03:29:44 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030304060301000707060009" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 2.1 (++) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 This is a cryptographically signed message in MIME format. --------------ms030304060301000707060009 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > in 1994 and > replaced with the "open type" which allows ASN.1 compilers to explicitly > link the contents of the "open type" field with the object identifier. > > In other LTANS specifications the following approach is used: One module is specified in 'CURRENT' ASN.1 syntax. An alternative module is done for 'old' compilers with is an almost 88 syntax Which one is normative is still a debate (as in another group). In some specs also an XSD schema is defined. For LTAP at least the XSD is automatically generated from the ASN.1 and produces the same encodings and an XER encoding of the ASN.1 Besides that and in response to Sean. Although a module can reuse a name that is defined in another module, I agree that this may be confusing. Peter -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorite'; die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch. --------------ms030304060301000707060009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NzEyMDUxNDI5NDNaMCMGCSqGSIb3DQEJBDEWBBR6Rr9l1IjkScdg8jh2nhEbkscw+zBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYC12rJugwEGRIouWZ3irNpyT74s+d/nqt3fKX3Qs98PH0sswO58eWZzV/g3 IclC2PbZ42edzfpqFHFmIEju7OIeHdAWtN1zwr8bzT0k4ctsu2R5kDAeoPrp943a4SXJ2iNa 7Zlyv7pV63Qe3NVPNHyeEXG40OnQmXptn9DKF6CM9AAAAAAAAA== --------------ms030304060301000707060009-- From owner-ietf-ltans@mail.imc.org Wed Dec 05 10:34:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzwGc-0000U7-Dx for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 10:34:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzwGb-0003xr-Uv for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 10:34:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5FL7QB027485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 08:21:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5FL7In027484; Wed, 5 Dec 2007 08:21:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB5FL5WE027475 for ; Wed, 5 Dec 2007 08:21:06 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 33517 invoked from network); 5 Dec 2007 15:21:05 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@216.18.3.1 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 5 Dec 2007 15:21:03 -0000 X-YMail-OSG: sasS60YVM1nA_JFCQKycG9.QG0l6DzeQJa3PhGNA3lqTIAxKIMWKYMM8TPrb26DXtbTFoyDkEg-- From: "Turner, Sean P." To: "'Peter Sylvester'" , "'Paul Thorpe'" Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756B5D7.7010407@edelweb.fr> Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Wed, 5 Dec 2007 07:16:41 -0800 Organization: IECA, Inc. Message-ID: <009701c83751$dd369680$e8f9a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4756B5D7.7010407@edelweb.fr> Thread-Index: Acg3S0pgiz5lHlfCSEOf5QUbXBxltQABTdhQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa >-----Original Message----- >From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] >Sent: Wednesday, December 05, 2007 6:30 AM >To: Paul Thorpe >Cc: Turner, Sean P.; ietf-ltans@imc.org >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > >> in 1994 and >> replaced with the "open type" which allows ASN.1 compilers to >> explicitly link the contents of the "open type" field with >the object identifier. >> >> >In other LTANS specifications the following approach is used: > >One module is specified in 'CURRENT' ASN.1 syntax. >An alternative module is done for 'old' compilers with is an >almost 88 syntax Which one is normative is still a debate (as >in another group). > >In some specs also an XSD schema is defined. For LTAP at least >the XSD is automatically generated from the ASN.1 and produces >the same encodings and an XER encoding of the ASN.1 > >Besides that and in response to Sean. > >Although a module can reuse a name that is defined in another >module, I agree that this may be confusing. > I like the idea of moving to the later ASN.1. The reason we've been stopped in the past was the lack of an open source compiler. We basically have one now with the a2c compiler. Peter - are you saying you don't want to import code, you'd rather grow your own? If you do I'd like to see how the current syntax would break out if I specified an elliptic curve and all it's parameters. It would be an long sequence of 'stuff' that you'd have to write up some verbiage about the 1st element of the sequence was this, the next this, and so on. That seems like an unworkable solution to me. spt From owner-ietf-ltans@mail.imc.org Wed Dec 05 11:12:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izwqz-0003jl-0e for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 11:12:05 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izwqw-00083k-IC for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 11:12:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5FuLBk029991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 08:56:21 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5FuL8W029990; Wed, 5 Dec 2007 08:56:21 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5FuJ0T029983 for ; Wed, 5 Dec 2007 08:56:20 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id B64E346; Wed, 5 Dec 2007 16:56:18 +0100 (CET) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18287-01; Wed, 5 Dec 2007 16:56:16 +0100 (CET) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 13CA113; Wed, 5 Dec 2007 16:56:16 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007120516561465:153528 ; Wed, 5 Dec 2007 16:56:14 +0100 Message-ID: <4756CA1F.9080202@edelweb.fr> Date: Wed, 05 Dec 2007 16:56:15 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "Turner, Sean P." Cc: "'Paul Thorpe'" , ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756B5D7.7010407@edelweb.fr> <009701c83751$dd369680$e8f9a8c0@Wylie> In-Reply-To: <009701c83751$dd369680$e8f9a8c0@Wylie> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 12/05/2007 04:56:14 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 12/05/2007 04:56:15 PM, Serialize complete at 12/05/2007 04:56:15 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050504080200010300090206" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 2.1 (++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a cryptographically signed message in MIME format. --------------ms050504080200010300090206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > I like the idea of moving to the later ASN.1. The reason we've been stopped > in the past was the lack of an open source compiler. We basically have one > now with the a2c compiler. > I disagree that we were stopped by that. But that's an old story I hope > Peter - are you saying you don't want to import code, you'd rather grow your > own? If you do I'd like to see how the current syntax would break out if I > specified an elliptic curve and all it's parameters. It would be an long > sequence of 'stuff' that you'd have to write up some verbiage about the 1st > element of the sequence was this, the next this, and so on. That seems like > an unworkable solution to me. > I have made no comment about the structure of the information that this document is proposing. I just mentioned that reusing a particular name 'Algorithm' to define another but similar structure as in some other module is not a good idea, and indeed defining another thing like AlgorithmValidityInfo is better. I think you refer to some older message from me? Following your comment: Before really entering into concrete syntax, it would be good to describe what abstract information needs to be encoded and how a validator (an automatic tool!!) is supposed to operate. An important requirement to me seems that when adding something to the structure, the core validator doesn't change. Does that makes sense? P -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorite'; die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch. --------------ms050504080200010300090206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NzEyMDUxNTU2MTVaMCMGCSqGSIb3DQEJBDEWBBRcKp0lQlHpBb+YRNxtGf4CPbpewTBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYBkJZpewpR24U2PRJJthpqLVnXpEHSLDlZXTaNNLPpgXGjImJ+1EpS/VsqJ cQWVh/OQatUD/W73j0OJtBQfPX/TL042HAyMwubt4ctn3h4kDti/WwHiZjuFrzl0ymok3ThF Qg7l3txKWUgcbjtHed8OYij+LQjltFsgBuddpNKr8wAAAAAAAA== --------------ms050504080200010300090206-- From owner-ietf-ltans@mail.imc.org Wed Dec 05 11:21:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izx08-00033S-07 for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 11:21:32 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izx07-0000Z5-Be for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 11:21:31 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5G206g030570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 09:02:00 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5G206v030568; Wed, 5 Dec 2007 09:02:00 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5G1vHC030561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Dec 2007 09:01:59 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.89.208] (sitp1_212.sit.fraunhofer.de [141.12.68.212]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id lB5G1qnK025562; Wed, 5 Dec 2007 17:01:52 +0100 Message-ID: <4756CB6A.4030504@sit.fraunhofer.de> Date: Wed, 05 Dec 2007 17:01:46 +0100 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Turner, Sean P." CC: ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> In-Reply-To: <001201c836e7$1f82a4e0$df128182@Wylie> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030004040002090306050507" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 This is a cryptographically signed message in MIME format. --------------ms030004040002090306050507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The problem with your suggested syntax is the definition of the our constraints. If we used the RFC3280 AlgorithmIdentifier structure, we would integrate the constraints as follows: AlgorithmValidityInfo ::= SEQUENCE { identifier AlgorithmIdentifier, constraint CHOICE { exact [0] OCTET STRING, min [1] OCTET STRING, max [2] OCTET STRING, range [3] Range, other [4] OtherConstraints validity Validity OPTIONAL, information Information OPTIONAL } It's not possible to determine constraints for more than one parameter (e.g. p > 1024 and q > 160 in case of DSA). Additionally defining ranges is impossible (e.g. modulus < 2048 and modulus > 1024). so & tk Turner, Sean P. schrieb: > I'm only commenting on the Parameter structure in the ASN.1. I think that it > might be better to change Algorithm to be a sequence of algorithmIdentifier, > validity, and information - call it AlgorithmValidityInfo. I suggest this > for two reasons: > > 1. The AlgorithmIdentifier structure that is used to assign an algorithm's > object identifier also define the parameters. So it probably makes sense to > reuse this structure. > > 2. The parameters structures for some of the newer algorithms is quite > complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs [RFC3279] > aren't just an OID they are nested structure. > > (not sure how to do it in XML) > > Replace: > > Algorithm ::= SEQUENCE { > algorithmIdentifier AlgID, > parameters [0] SEQUENCE OF Parameter OPTIONAL, > validity [1] Validity, > information [2] SEQUENCE OF UTF8String OPTIONAL > } > > AlgID ::= SEQUENCE { > name UTF8String, > oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > uri [1] SEQUENCE OF IA5String OPTIONAL > } > > Parameter ::= SEQUENCE { > name UTF8String, > constraint CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints > } > } > > With: > > AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > validity Validity OPTIONAL, > information Information OPTIONAL } > > Validity ::= SEQUENCE { > start [0] GeneralizedTime OPTIONAL, > end [1] GeneralizedTime OPTIONAL } > > Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > > -- From RFC3280 > AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > -- contains a value of the type > -- registered for use with the > -- algorithm object identifier value > > spt > > --------------ms030004040002090306050507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9 6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47 IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN +6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh 6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1 bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6 DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMDUxNjAxNDZaMCMGCSqGSIb3 DQEJBDEWBBQ2P7zNfrr0j3/upIjvYwz0/4r+BDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAG2Q30eVHpfmfXmCsFqfBlGcGhWePxY4+0YqMEECAny+3focOpLAvwa0 OXQFbp8yLAtvG/76krfuyPXTxQIQcJTOn7PSwTkPkzMD0XEiIGUG5fll2D243bBljzPJtEP3 SMdC1pdxTIJN3o+0sp1dBC6I1/sc+mio7SI/qtmMRExb/6wuzYdxuujolHi39fVTvIeaT+qf fBGbxpKwd5zgo9KmCCbFlAl1woRKcPC+hg0AphUZT90EKnRnrstTahus5te1xk9kcGGLGpJ/ J/WDM1KbELmaSeCfbE6LyRV94iaGuj656RjNQ/yD6WXw9giibswyS8cR0jOnsoGK13HloHQA AAAAAAA= --------------ms030004040002090306050507-- From owner-ietf-ltans@mail.imc.org Wed Dec 05 11:44:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzxMM-0007Lv-Ja for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 11:44:30 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzxMM-0002sL-1X for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 11:44:30 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5GPh7M032885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 09:25:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5GPh0B032884; Wed, 5 Dec 2007 09:25:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB5GPfTs032876 for ; Wed, 5 Dec 2007 09:25:42 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 37485 invoked from network); 5 Dec 2007 16:25:41 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@216.18.3.1 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 5 Dec 2007 16:25:40 -0000 X-YMail-OSG: d__moJMVM1lQEVbcr0bCPoG2LZT2sQR04zJY0puvkXp4RHY7O5ytuVPWimYlBATrY3VQ.Yx2ug-- From: "Turner, Sean P." To: "'Thomas Kunz'" Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Wed, 5 Dec 2007 08:21:25 -0800 Organization: IECA, Inc. Message-ID: <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4756CB6A.4030504@sit.fraunhofer.de> Thread-Index: Acg3WCi6c4cGEkitQ12REqMINMbYlAAAp67Q Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This would work for me. spt >-----Original Message----- >From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >Sent: Wednesday, December 05, 2007 8:02 AM >To: Turner, Sean P. >Cc: ietf-ltans@imc.org >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >The problem with your suggested syntax is the definition of >the our constraints. If we used the RFC3280 >AlgorithmIdentifier structure, we would integrate the >constraints as follows: > >AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > constraint CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints > validity Validity OPTIONAL, > information Information OPTIONAL } > >It's not possible to determine constraints for more than one >parameter (e.g. p > 1024 and q > 160 in case of DSA). >Additionally defining ranges is impossible (e.g. modulus < >2048 and modulus > 1024). > > >so & tk > > >Turner, Sean P. schrieb: >> I'm only commenting on the Parameter structure in the ASN.1. I think >> that it might be better to change Algorithm to be a sequence of >> algorithmIdentifier, validity, and information - call it >> AlgorithmValidityInfo. I suggest this for two reasons: >> >> 1. The AlgorithmIdentifier structure that is used to assign an >> algorithm's object identifier also define the parameters. So it >> probably makes sense to reuse this structure. >> >> 2. The parameters structures for some of the newer >algorithms is quite >> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >[RFC3279] >> aren't just an OID they are nested structure. >> >> (not sure how to do it in XML) >> >> Replace: >> >> Algorithm ::= SEQUENCE { >> algorithmIdentifier AlgID, >> parameters [0] SEQUENCE OF Parameter OPTIONAL, >> validity [1] Validity, >> information [2] SEQUENCE OF UTF8String OPTIONAL >> } >> >> AlgID ::= SEQUENCE { >> name UTF8String, >> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >> uri [1] SEQUENCE OF IA5String OPTIONAL >> } >> >> Parameter ::= SEQUENCE { >> name UTF8String, >> constraint CHOICE { >> exact [0] OCTET STRING, >> min [1] OCTET STRING, >> max [2] OCTET STRING, >> range [3] Range, >> other [4] OtherConstraints >> } >> } >> >> With: >> >> AlgorithmValidityInfo ::= SEQUENCE { >> identifier AlgorithmIdentifier, >> validity Validity OPTIONAL, >> information Information OPTIONAL } >> >> Validity ::= SEQUENCE { >> start [0] GeneralizedTime OPTIONAL, >> end [1] GeneralizedTime OPTIONAL } >> >> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >> >> -- From RFC3280 >> AlgorithmIdentifier ::= SEQUENCE { >> algorithm OBJECT IDENTIFIER, >> parameters ANY DEFINED BY algorithm OPTIONAL } >> -- contains a value of the type >> -- registered for use with the >> -- algorithm object identifier value >> >> spt >> >> > From owner-ietf-ltans@mail.imc.org Wed Dec 05 11:48:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzxPs-0000nT-GN for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 11:48:08 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzxPs-0003Eq-0p for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 11:48:08 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5GSJXV033046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 09:28:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5GSJSo033045; Wed, 5 Dec 2007 09:28:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB5GSHsj033037 for ; Wed, 5 Dec 2007 09:28:18 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 36553 invoked from network); 5 Dec 2007 16:28:17 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@216.18.3.1 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 5 Dec 2007 16:28:17 -0000 X-YMail-OSG: Oaro.qEVM1m__zx.j.N6KByUgy7ir9poRBpFbEn641bmFkIERtaGOhdhPkXpxn5siN8cgzkH82yjTYRtSCHJk4CP_dSZx_6h2hBDutOiYA0xKu8VYWiRPYBtCMwvs2BDTNbyl..vIh3yKDY- From: "Turner, Sean P." To: "'Peter Sylvester'" Cc: "'Paul Thorpe'" , References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756B5D7.7010407@edelweb.fr> <009701c83751$dd369680$e8f9a8c0@Wylie> <4756CA1F.9080202@edelweb.fr> Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Wed, 5 Dec 2007 08:24:03 -0800 Organization: IECA, Inc. Message-ID: <010801c8375b$4105a620$e8f9a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4756CA1F.9080202@edelweb.fr> Thread-Index: Acg3V2EN8w1QKvlOR5iahCnkFNO2WQAA47Xw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 >> I like the idea of moving to the later ASN.1. The reason we've been >> stopped in the past was the lack of an open source compiler. We >> basically have one now with the a2c compiler. >> >I disagree that we were stopped by that. But that's an old story I hope >> Peter - are you saying you don't want to import code, you'd rather >> grow your own? If you do I'd like to see how the current >syntax would >> break out if I specified an elliptic curve and all it's >parameters. It >> would be an long sequence of 'stuff' that you'd have to >write up some >> verbiage about the 1st element of the sequence was this, the next >> this, and so on. That seems like an unworkable solution to me. >> >I have made no comment about the structure of the information >that this document is proposing. I just mentioned that reusing >a particular name 'Algorithm' >to define >another but similar structure as in some other module is not a >good idea, and indeed defining another thing like >AlgorithmValidityInfo is better. > >I think you refer to some older message from me? >Following your comment: Before really entering into concrete >syntax, it would be good to describe what abstract information >needs to be encoded and how a validator (an automatic tool!!) >is supposed to operate. >An important requirement to me seems that when adding >something to the structure, the core validator doesn't change. > >Does that makes sense? >P I guess I was reacting to the thoughts of algorithm spec writers have to have to different formats for representing their algorithms. One which is used in most ASN.1 based security protocols and another for this. I think picking another syntax would sink this proposal. Thomas has solved my concern though. spt From owner-ietf-ltans@mail.imc.org Wed Dec 05 13:43:08 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzD9-0005aW-Vf for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 13:43:07 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzzD9-00068T-8g for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 13:43:07 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5IVAMJ045739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 11:31:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5IVAFr045738; Wed, 5 Dec 2007 11:31:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB5IV9NS045732 for ; Wed, 5 Dec 2007 11:31:09 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 27714 invoked from network); 5 Dec 2007 18:25:27 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;05 Dec 2007 18:25:27 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 5 Dec 2007 18:25:26 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Dec 2007 13:31:07 -0500 Message-ID: From: Carl Wallace To: Thomas Kunz , "Turner, Sean P." Cc: ietf-ltans@imc.org Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Wed, 5 Dec 2007 13:30:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A6_01C83743.0D4F5AA0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 This is a multi-part message in MIME format. ------=_NextPart_000_00A6_01C83743.0D4F5AA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit How about something like the following to avoid multiple instances of an alg ID: > AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > constraints SEQUENCE OF Constraint } Constraint::= SEQUENCE { parameter CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints} > validity Validity OPTIONAL, > information Information OPTIONAL } > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > Sent: Wednesday, December 05, 2007 11:02 AM > To: Turner, Sean P. > Cc: ietf-ltans@imc.org > Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > The problem with your suggested syntax is the definition of > the our constraints. If we used the RFC3280 > AlgorithmIdentifier structure, we would integrate the > constraints as follows: > > AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > constraint CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints > validity Validity OPTIONAL, > information Information OPTIONAL } > > It's not possible to determine constraints for more than one > parameter (e.g. p > 1024 and q > 160 in case of DSA). > Additionally defining ranges is impossible (e.g. modulus < > 2048 and modulus > 1024). > > > so & tk > > > Turner, Sean P. schrieb: > > I'm only commenting on the Parameter structure in the > ASN.1. I think > > that it might be better to change Algorithm to be a sequence of > > algorithmIdentifier, validity, and information - call it > > AlgorithmValidityInfo. I suggest this for two reasons: > > > > 1. The AlgorithmIdentifier structure that is used to assign an > > algorithm's object identifier also define the parameters. So it > > probably makes sense to reuse this structure. > > > > 2. The parameters structures for some of the newer > algorithms is quite > > complicated. For example, RSASSA-PSS [RFC4055] and ECC > Algs [RFC3279] > > aren't just an OID they are nested structure. > > > > (not sure how to do it in XML) > > > > Replace: > > > > Algorithm ::= SEQUENCE { > > algorithmIdentifier AlgID, > > parameters [0] SEQUENCE OF Parameter OPTIONAL, > > validity [1] Validity, > > information [2] SEQUENCE OF UTF8String OPTIONAL > > } > > > > AlgID ::= SEQUENCE { > > name UTF8String, > > oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > > uri [1] SEQUENCE OF IA5String OPTIONAL > > } > > > > Parameter ::= SEQUENCE { > > name UTF8String, > > constraint CHOICE { > > exact [0] OCTET STRING, > > min [1] OCTET STRING, > > max [2] OCTET STRING, > > range [3] Range, > > other [4] OtherConstraints > > } > > } > > > > With: > > > > AlgorithmValidityInfo ::= SEQUENCE { > > identifier AlgorithmIdentifier, > > validity Validity OPTIONAL, > > information Information OPTIONAL } > > > > Validity ::= SEQUENCE { > > start [0] GeneralizedTime OPTIONAL, > > end [1] GeneralizedTime OPTIONAL } > > > > Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > > > > -- From RFC3280 > > AlgorithmIdentifier ::= SEQUENCE { > > algorithm OBJECT IDENTIFIER, > > parameters ANY DEFINED BY algorithm OPTIONAL } > > -- contains a value of the type > > -- registered for use with the > > -- algorithm object identifier value > > > > spt > > > > > ------=_NextPart_000_00A6_01C83743.0D4F5AA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILpjCCA60w ggKVoAMCAQICBECEF1YwDQYJKoZIhvcNAQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5 Z25hY29tMB4XDTA0MDQxOTE3NDYwMVoXDTI0MDQxOTE4MTYwMVowIDELMAkGA1UEBhMCdXMxETAP BgNVBAoTCGN5Z25hY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuw8jjNSH/3qx UShITC4+vYJG8TZsE2f4pbGUhcXe+v0PChxtWvVpOAVqXm/7y1hdBKKMjdg98Xo/jmVtFPGlKXhV v9FYyK1zxydN1YgEjRzmuSd9RNNm9YL2rgg2Q/TtT3hDwDiT4rj62ukIKYTlZHNLm1t7uYa8K/44 F5jJvo6zPkWtRqrKBFJfBblKFaPteEXU5JIKX8cbwIF3HJx9+P15S0wRngCKb0+1/d9pIuwS4Frg 1R98hG+jRXiS8klB6TncucWH2w1OqYouzUGSncb+o+EVx4PHwsE7kKxIMAsQC6zbHsAS0CAOb6hw JW7P+dtaR/9Gi8NdKsgkFlQjbQIDAQABo4HuMIHrMEIGA1UdHwQ7MDkwN6A1oDOkMTAvMQswCQYD VQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMjAw NDA0MTkxNzQ2MDFagQ8yMDI0MDQxOTE4MTYwMVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFHqT o3DI3p2/kOS+O6DeN/DUalp5MB0GA1UdDgQWBBR6k6NwyN6dv5Dkvjug3jfw1GpaeTAMBgNVHRME BTADAQH/MB0GCSqGSIb2fQdBAAQQMA4bCFY3LjA6NC4wAwIEkDANBgkqhkiG9w0BAQUFAAOCAQEA aHtrFA6rDnATj2GxfNuRLFVrsWBLSCYUdMs6YbssKI2f/Fh/o382eAnvvcpI76koLijn4Cbj482A tkWgw6hOhgESamFWaY951O0nUrk43KG5Nv4KQjXiNArFwf1ATEtB6KTeiaffh2vVbUWodZ+uwnTh X6ZlPmVooWFcB9NH+9GteR7zIJA/Eq0p0CHiCozIhOp1QGJ2cXTtHQk4Cq+sYh8du6ry0xRB3b5Z Jw/iewtxAoge2e/vh0f46mgrSdmCuPzjVLvyLg63ktN9hJe8Iiy4JiKqplnsMGizW2lxKwl/Ys0L alsltxYuLF1jytrzGJEit+5acGcjhdhijL0IojCCA98wggLHoAMCAQICBECEWOUwDQYJKoZIhvcN AQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMB4XDTA2MDkyNzExNDcxN1oX DTA5MDkyNzEyMTcxN1owRzELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMSUwDgYDVQQF EwcyRUNSVzAyMBMGA1UEAxMMQ2FybCBXYWxsYWNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAwVtX5z3+WT31t1J6qYHb6CsFBl6NLFq+cnJjpuxMAiFfMoifHSreDtDfJMUJcUMqOG1o 0JdBUI4nakhAo8nPNMkzatmF0cxyryagaWWnILjPJKz5LCzM/LNQnMhUFGoRPDMnkaJp82pAW/Me cjUSS1w2MMFnjxjZ9t8DHvQ3FEY2nU5yKolnLrbmx07qVCT2KNEyetQKTR5iCsA7YiYPTFIsXHPr TiqUsbIETHIWJqh8hRZt3Mf1jg4ayrGKmcOvpjphit7HCOPxtM/u9tajt705LzcAk/6YN3yXtc/c 88Sw48YtKrba1m5IwBq6MNBp0K9tSq7j0Mpm0bIkyL8bMwIDAQABo4H5MIH2MCAGA1UdEQQZMBeB FWN3YWxsYWNlQGN5Z25hY29tLmNvbTAbBgNVHQkEFDASMBAGCSqGSIb2fQdEHTEDAgEKMEIGA1Ud HwQ7MDkwN6A1oDOkMTAvMQswCQYDVQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTALBgNVBAMT BENSTDEwCwYDVR0PBAQDAgUgMB8GA1UdIwQYMBaAFHqTo3DI3p2/kOS+O6DeN/DUalp5MB0GA1Ud DgQWBBSTgaWOBxA4oFp5yDWk+ZSoowxj0zAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3 LjADAgSQMA0GCSqGSIb3DQEBBQUAA4IBAQCAPGGb5f6vwUpGtEaX0UbWzcCn0g5l72s82rsQjiBF rXYpRO62c2rcnqrSp6EVa2Qk62h+DXmxnLzF+zjJ6roRnAW9LW28UYxPi9cpLGxmRkRe+d62K7QU LM7G5vU64jfW641ykblwQaf/dVzcTpXg7mU7n7qO46YWAAVaTyq3gdKYZxtXInZEWvnxzH3dJjcD 7Q1KSrH/ztsbwgW/rFq29iorSjVZNG4ROB7QAG85GVy5GkDSLEjOnEU+3dVgqjEjxODyCP+owkzO k2JKsyqaewHPnbNs4NV7OGCJx+BJsLK2Ef0MBYdt7Ebe1efxNIK8IyeuFBJPjJRLQItdBiVnMIIE DjCCAvagAwIBAgIEQIRY+zANBgkqhkiG9w0BAQUFADAgMQswCQYDVQQGEwJ1czERMA8GA1UEChMI Y3lnbmFjb20wHhcNMDYwOTI4MTY0NjMxWhcNMDkwOTI4MTcxNjMxWjBHMQswCQYDVQQGEwJ1czER MA8GA1UEChMIY3lnbmFjb20xJTAOBgNVBAUTBzJFQ1JXMDIwEwYDVQQDEwxDYXJsIFdhbGxhY2Uw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTeGLLD5qbBCFsqR9R+3UTCxdJKetGhH7z UVgI2cfdzArj3uXkR7r2bpVS80GRVKaC/0t8EYaxW4Ls8ZfdwWutaFfzbbIB2E+TAzF+ldT01Vdv gy3Rws+BhZWudk5blrakYfKeUffzWiYHrJGHtOTOnyucHdE6gahikPDQ8lsDEbtxt+hzymOXZKVY VAk2u5eBj/uxtAk/PMbIUcQLqvMf01AiZs6kNvHuhaWheAxGa4+cHM5nFUpSZpC49r4BuoBA2Rw2 ES2a+OqhMIKlsdE9MM7G9YQf4jREcf4cfnT+cMd57lc8TijkKJOMoXyMtLRK+UByDtQ1FbCNHAz4 hnRxAgMBAAGjggEnMIIBIzALBgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwNjA5MjgxNjQ2MzFa gQ8yMDA4MTEwMzIxMTYzMVowIAYDVR0RBBkwF4EVY3dhbGxhY2VAY3lnbmFjb20uY29tMBsGA1Ud CQQUMBIwEAYJKoZIhvZ9B0QdMQMCAQowQgYDVR0fBDswOTA3oDWgM6QxMC8xCzAJBgNVBAYTAnVz MREwDwYDVQQKEwhjeWduYWNvbTENMAsGA1UEAxMEQ1JMMTAfBgNVHSMEGDAWgBR6k6NwyN6dv5Dk vjug3jfw1GpaeTAdBgNVHQ4EFgQU/GqeRUaoI5dNtUm3CGFNyYv1k64wCQYDVR0TBAIwADAZBgkq hkiG9n0HQQAEDDAKGwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAOOP2IoptDkJugTF+3euz rC8N5aO392HDa3y2cf7XL9uVGJ9YT2DUMmaxZBS9hpKa9yxeU+Vcoho6p/7QhLtDhHR4LlXg1CXd EuMTlEdL2aA0CYJjAbCQsPACCm7+MFvfdTKwrD6NEx+3eInppPTgXm3HuZEamKPQN69tZ3wr7TMe qBBWRUrS2GfnfpGGRneI7yhA+HJ0PDOEMA31C877efxHOqnRsojU4f9+F7EPw8y6Ipovf0GFJ0ZV a4gMaouSzNwmOHhsZfgzM8lpmUN8CkYXTdHEwDedKjzJ3mltindxDYml6tFl0A4kAv/rD68dGgbz kPNQAkbrT9dijO2yNTGCAo0wggKJAgEBMCgwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25h Y29tAgRAhFj7MAkGBSsOAwIaBQCgggE6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA3MTIwNTE4MzA1MFowIwYJKoZIhvcNAQkEMRYEFEXOgtQqINZd7Ig/IB1PQmE8 jdCcMDcGCSsGAQQBgjcQBDEqMCgwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tAgRA hFjlMDkGCyqGSIb3DQEJEAILMSqgKDAgMQswCQYDVQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20C BECEWOUwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwDQYJ KoZIhvcNAQEBBQAEggEAwNln1PpwdzEBU/mY4FlOO8ILHMjiwytvwVX2Vu8nP8DZyqY/gBwZ27nJ zk5BpGSSKR+Zq0lo5lMiwlRj2cPm4HNaoi2zx1Q3Un9tlGFBsrtgOJx5Qco1F75yprJljwDzBkUg xyMlgB/O9Fnug1gqW72BNMWTWRNaHPLQEIpVv16TA3Z+xJkmZSutRPlfhUKL0PbU6KPDMqcY1SRb gsMZkUqDmPN9HqyiqOAIAdeSEhugwf+na4MoVVlZlBoQF8ZDS36LHTv1gdcwsiUlkUmYtiajcDze ihqPCzbevxNNKaslUPUFKEMsPc+WaqXwU+iXBDpDagfTt/TN1QN/Muv0TwAAAAAAAA== ------=_NextPart_000_00A6_01C83743.0D4F5AA0-- From owner-ietf-ltans@mail.imc.org Wed Dec 05 17:00:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02Ib-0007Xn-6R for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 17:00:57 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J02Ia-0008S3-1E for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 17:00:57 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5Lm2fx066661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 14:48:02 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5Lm2ZR066660; Wed, 5 Dec 2007 14:48:02 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5Lm0Rf066653 for ; Wed, 5 Dec 2007 14:48:01 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lB5Llx1N015603 for ; Wed, 5 Dec 2007 22:47:59 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lB5Llwtq002628 for ; Wed, 5 Dec 2007 16:47:58 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83788.7FE685CE" Subject: LTANS meeting minutes and slides from 70th IETF are available online Date: Wed, 5 Dec 2007 22:47:55 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F19FF8@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS meeting minutes and slides from 70th IETF are available online Thread-Index: Acg3iH6dhrygCMn6TPyoyxdFlrVMhw== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: X-Archived: msg.B5kQjxX:2007-12-05:mucpm02.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 This is a multi-part message in MIME format. ------_=_NextPart_001_01C83788.7FE685CE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 just FYI: the minutes and presentation slides are available on the = Meetings Material web page:=20 https://datatracker.ietf.org/meeting/70/materials.html and an audio archive of the meeting is also available (audio file = combined with forces and smime): http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf70/ietf70-ch3-tue= -afnoon-forces-ltans-smime.mp3 cheers, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler This email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C83788.7FE685CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS meeting minutes and slides from 70th IETF are available = online

Hi all, =

just = FYI: the minutes and presentation slides are available on the Meetings Material web page:

https://datatracker.ietf.org/meeting/70/materials.html

and an audio archive of the meeting is also available = (audio file = combined with forces and smime):

http://limestone.uoregon.edu/ftp/= pub/videolab/media/ietf70/ietf70-ch3-tue-afnoon-forces-ltans-smime.mp3

cheers, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open = Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler

This = email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized = Recipient") for the purpose for which it was sent by OTC. All other = rights and licenses to this email are fully reserved to OTC. If you are = not an Authorized Recipient, you are required to immediately delete this = email in its entirety without printing, copying, using, and/or = re-transmitting this email, either in whole or in part. The transmission = of this email by OTC is not to be construed as a waiver by OTC and/or = the individual sending this email on behalf of OTC of any of their = respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C83788.7FE685CE-- From owner-ietf-ltans@mail.imc.org Wed Dec 05 17:05:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02ND-0001yk-VK for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 17:05:43 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J02NC-0000RJ-PG for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 17:05:43 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5LucVa067267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 14:56:38 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5LucPs067266; Wed, 5 Dec 2007 14:56:38 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5LuaYT067259 for ; Wed, 5 Dec 2007 14:56:37 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lB5LuZed016209 for ; Wed, 5 Dec 2007 22:56:35 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lB5LuY52017590 for ; Wed, 5 Dec 2007 16:56:35 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83789.B3BF4795" Subject: closing of WG LC for ERS/SCVP next week on Dec-11 Date: Wed, 5 Dec 2007 22:56:32 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F19FF9@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: closing of WG LC for ERS/SCVP next week on Dec-11 Thread-Index: Acg3ibLJL12m2KX9QMKMYkc3qdf95w== From: "Tobias Gondrom" To: X-Archived: msg.A7HuQrg:2007-12-05:mucpm01.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 This is a multi-part message in MIME format. ------_=_NextPart_001_01C83789.B3BF4795 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, just a last reminder: I initiated WG LC on ERS/SCVP = (draft-ietf-ltans-ers-scvp) several weeks ago.=20 Carl included the feedback he received during LC (mostly editorial = changes and one minor change of bit-on-the-wire)) in the revisions 04 = and 05.=20 As discussed yesterday at the meeting, I feel the draft is in good shape = and will close WG LC for this document next week (Dec-11) and proceed it = to AD/IESG review and IETF LC. So if you have any last comments or = discusses for the ERS/SCVP, please submit them until this deadline.=20 .=20 Greetings, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler This email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C83789.B3BF4795 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable closing of WG LC for ERS/SCVP next week on Dec-11

Hello = all,

just = a last reminder: I = initiated WG LC on ERS/SCVP (draft-ietf-ltans-ers-scvp) several weeks ago.

Carl = included the feedback he received during LC (mostly editorial changes and one minor change of = bit-on-the-wire)) in the revisions 04 and 05.

As = discussed yesterday at the meeting, I feel the draft is in good shape = and will close WG LC for this = document next week (Dec-11) and proceed it to AD/IESG review and IETF LC. So if you have any last comments or discusses = for the ERS/SCVP, please submit them until this = deadline.

.

Greetings, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open = Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler

This = email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized = Recipient") for the purpose for which it was sent by OTC. All other = rights and licenses to this email are fully reserved to OTC. If you are = not an Authorized Recipient, you are required to immediately delete this = email in its entirety without printing, copying, using, and/or = re-transmitting this email, either in whole or in part. The transmission = of this email by OTC is not to be construed as a waiver by OTC and/or = the individual sending this email on behalf of OTC of any of their = respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C83789.B3BF4795-- From owner-ietf-ltans@mail.imc.org Wed Dec 05 17:43:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02y1-0002b5-1k for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 17:43:45 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J02xw-0004d2-LL for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 17:43:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5MVU4g070747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 15:31:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5MVUv5070746; Wed, 5 Dec 2007 15:31:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5MVSBD070736 for ; Wed, 5 Dec 2007 15:31:29 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lB5MVP5C018762; Wed, 5 Dec 2007 23:31:26 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lB5MVPO9007194; Wed, 5 Dec 2007 17:31:25 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8378E.91BA4D78" Subject: FYI: FW: [saag] Summary of LTANS WG meeting at IETF 70th in Vancouver Date: Wed, 5 Dec 2007 23:31:23 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F19FFF@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: FW: [saag] Summary of LTANS WG meeting at IETF 70th in Vancouver Thread-Index: Acg3jigIqLZ2p8AHTI2xqzq3Ft+gFwAAAUog X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Cc: "Carl Wallace" X-Archived: msg.BjLxIHo:2007-12-05:mucpm02.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 This is a multi-part message in MIME format. ------_=_NextPart_001_01C8378E.91BA4D78 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just FYI. This is just a shortened summary about the meeting yesterday. = For the full minutes please go to the meeting materials page:=20 https://datatracker.ietf.org/meeting/70/materials.html - Tobias _____________________________________________ From: Tobias Gondrom=20 Sent: Wednesday, December 05, 2007 2:28 PM To: saag@mit.edu Cc: 'Carl Wallace' Subject: [saag] Summary of LTANS WG meeting at IETF 70th in Vancouver Summary of LTANS WG meeting 12/4/2007 - 70th IETF - Vancouver:=20 (Detailed minutes have been published on the meeting materials page.) Current work of LTANS WG focuses on finishing existing drafts to bring = them to IETF LC.=20 There are currently five I-Ds in progress:=20 - ERS/SCVP is closing WG LC right after 70th IETF and will proceed to = IETF LC.=20 - DSSC (info about algorithm lifetimes) will go into WG LC soon - XMLERS (had a larger revision and may go into WG LC in Jan/Feb) - validate has been revised and may go to WG LC in Jan/Feb) - LTAP: WG plans to move from planned status "proposed standard" to = "experimental" as we do not see sufficient number of implementations - = planned WG LC in Feb Further comments:=20 - as SCVP has now moved to RFC, ERS/SCVP will continue to proceed as = well. Sample ERS/SCVP artifacts will be made available shortly after the = IETF meeting and a responder may be made available in January for = interop testing. - XMLERS has be revised and its XML structure now closely matches ERS = ASN.1 - invitation for additional XMLERS implementations to run interop tests - search for government authorities (that provide info on suitability of = algorithms and their pararmeters) who want to use and provide data in = the dssc format.=20 - LTAP will change status to "experimental" - currently tbd whether LTANS shall re-continue work on architecture I-D = to explain how the standards work together and outline the architecture = of an overall system Cheers, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler ------_=_NextPart_001_01C8378E.91BA4D78 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI: FW: [saag] Summary of LTANS WG meeting at IETF 70th in = Vancouver

Just FYI. This is just a shortened summary about the meeting = yesterday. For the full minutes please go to the meeting materials page: =

https://datatracker.ietf.org/meeting/70/materials.html

- Tobias


_____________________________________________
From: = Tobias Gondrom
Sent: = Wednesday, December 05, 2007 2:28 PM
To: saag@mit.edu
Cc: = 'Carl Wallace'
Subject: = [saag] Summary of LTANS WG meeting at IETF 70th in = Vancouver

Summary of LTANS WG meeting 12/4/2007 - 70th IETF – = Vancouver:

(Detailed minutes have been published on the meeting = materials page.)

Current work of LTANS WG focuses on finishing existing = drafts to bring them to IETF LC.

There = are currently five I-Ds in progress:

- = ERS/SCVP is closing WG LC right after 70th = IETF and will proceed to IETF LC.

- = DSSC (info about algorithm lifetimes) will go into WG LC = soon

- = XMLERS (had a larger revision and may go into WG LC in = Jan/Feb)

- = validate has been revised and may go to WG LC in = Jan/Feb)

- = LTAP: WG plans to move from planned status “proposed = standard” to “experimental” as we do not see = sufficient number of implementations – planned WG LC in = Feb

Further comments:

- as = SCVP has now moved to RFC, ERS/SCVP will continue to proceed as well. = Sample ERS/SCVP artifacts will be made available shortly after the IETF = meeting and a responder may be made available in January for interop = testing.

- = XMLERS has be revised and its XML structure now closely matches ERS = ASN.1

- = invitation for additional XMLERS implementations to run interop = tests

- = search for government authorities (that provide info on suitability of = algorithms and their pararmeters) who want to use and provide data in = the dssc format.

- = LTAP will change status to “experimental”

- = currently tbd whether LTANS shall re-continue work on architecture I-D = to explain how the standards work together and outline the architecture = of an overall system

Cheers, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open = Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentext.com
Internet: http://www.opentext.com/ 

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler

------_=_NextPart_001_01C8378E.91BA4D78-- From owner-ietf-ltans@mail.imc.org Wed Dec 05 18:31:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03hm-00025S-BA for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 18:31:02 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J03hl-00014l-PS for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 18:31:02 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5NDgpB073316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 16:13:42 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5NDgDM073315; Wed, 5 Dec 2007 16:13:42 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5NDewE073307 for ; Wed, 5 Dec 2007 16:13:40 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lB5NDERl020408; Thu, 6 Dec 2007 00:13:14 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lB5NDBYF024444; Wed, 5 Dec 2007 18:13:14 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Thu, 6 Dec 2007 00:13:09 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F1A002@MUCXGC2.opentext.net> In-Reply-To: <009701c83751$dd369680$e8f9a8c0@Wylie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment on draft-ietf-ltans-dssc-01.txt Thread-Index: Acg3S0pgiz5lHlfCSEOf5QUbXBxltQABTdhQABC0CHA= From: "Tobias Gondrom" To: "Turner, Sean P." , "Peter Sylvester" , "Paul Thorpe" Cc: X-Archived: msg.Agfvwuv:2007-12-05:mucpm01.smtp.dmz.opentext.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB5NDfwE073310 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Hello all, in the past the fact that we did not have a comprehensive free ASN.1-compiler for 1997 or 2002 available has been keeping us to at least provide 1988-ASN.1 as one of the modules with every RFC. Thanks to the good and by the IETF well recognized progress on free ASN.1 compilers for 2002-ASN.1 we can now freely use this more recent ASN.1 version. So please consider the new version of ASN.1 to be recommended for your drafts and it no longer to be required to provide a module in 1988-ASN.1 in parallel. Compiler I am referring to is a2c. Regards, Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Turner, Sean P. > Sent: Wednesday, December 05, 2007 7:17 AM > To: 'Peter Sylvester'; 'Paul Thorpe' > Cc: ietf-ltans@imc.org > Subject: RE: comment on draft-ietf-ltans-dssc-01.txt > > > >-----Original Message----- > >From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] > >Sent: Wednesday, December 05, 2007 6:30 AM > >To: Paul Thorpe > >Cc: Turner, Sean P.; ietf-ltans@imc.org > >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > > > > > >> in 1994 and > >> replaced with the "open type" which allows ASN.1 compilers to > >> explicitly link the contents of the "open type" field with > >the object identifier. > >> > >> > >In other LTANS specifications the following approach is used: > > > >One module is specified in 'CURRENT' ASN.1 syntax. > >An alternative module is done for 'old' compilers with is an > >almost 88 syntax Which one is normative is still a debate (as > >in another group). > > > >In some specs also an XSD schema is defined. For LTAP at least > >the XSD is automatically generated from the ASN.1 and produces > >the same encodings and an XER encoding of the ASN.1 > > > >Besides that and in response to Sean. > > > >Although a module can reuse a name that is defined in another > >module, I agree that this may be confusing. > > > > I like the idea of moving to the later ASN.1. The reason we've been > stopped > in the past was the lack of an open source compiler. We basically have one > now with the a2c compiler. > > Peter - are you saying you don't want to import code, you'd rather grow > your > own? If you do I'd like to see how the current syntax would break out if I > specified an elliptic curve and all it's parameters. It would be an long > sequence of 'stuff' that you'd have to write up some verbiage about the > 1st > element of the sequence was this, the next this, and so on. That seems > like > an unworkable solution to me. > > spt From owner-ietf-ltans@mail.imc.org Wed Dec 05 18:33:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03jp-0002ZR-By for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 18:33:09 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J03jm-0001Hb-OW for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 05 Dec 2007 18:33:09 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5NJtRr073786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 16:19:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5NJtKl073785; Wed, 5 Dec 2007 16:19:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5NJrxj073775 for ; Wed, 5 Dec 2007 16:19:53 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=geXWlKNPgjxKImDAyku8E5WrKud4U4CIuQJiFHX9XgsWU6a8ORgsnRAoElthYeU9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J03Wy-0007ZF-OF; Wed, 05 Dec 2007 18:19:52 -0500 Message-ID: <00c001c83795$5ec4f500$174f7d40@home.glassey.com> From: "todd glassey" To: "Tobias Gondrom" , References: <2666EB2A846BAC4BB2D7F593301A786801F19FF9@MUCXGC2.opentext.net> Subject: Re: closing of WG LC for ERS/SCVP next week on Dec-11 Date: Wed, 5 Dec 2007 15:20:03 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BD_01C83752.4F3C3190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c45d0e1ee808f30990c65cf0ff9ecdf1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad This is a multi-part message in MIME format. ------=_NextPart_000_00BD_01C83752.4F3C3190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable closing of WG LC for ERS/SCVP next week on Dec-11Tobias, the problem is = that here in the US there are new and very formal hurdles for Long Term = Document Storage and these are per the US Court Standard set in a case = called "Lorraine v. Markel", and these now constrain the use of any = "electronic media" storage technology, and whether ANY of us like this = or not, this standard is IN FORCE and will be in force for the = foreseeable future making the design of a protocol to support long term = document archiving a key piece of any and all such public companies = operations.=20 The reality here is that LTANS was given a guarantee on its deployment = if it will embrace and meet these standards, and if not the adoption of = LTANS will become a pariah in my opinion since company's will not be = able to rely on protocols which do not allow them to meet their new = digital evidence needs. It is for that reason I suggest adding another I-D on Digital Evidence = Compliance to the WG's Deliverables. I will be filing a prototype for this if the WG is interested sometime = early next week but I want to know up front that this is not a wasted = effort as I am pretty busy now. Todd Glassey CISM CIFI CTO Wireless-Time.COM ----- Original Message -----=20 From: Tobias Gondrom=20 To: ietf-ltans@imc.org=20 Sent: Wednesday, December 05, 2007 1:56 PM Subject: closing of WG LC for ERS/SCVP next week on Dec-11 Hello all, just a last reminder: I initiated WG LC on ERS/SCVP = (draft-ietf-ltans-ers-scvp) several weeks ago.=20 Carl included the feedback he received during LC (mostly editorial = changes and one minor change of bit-on-the-wire)) in the revisions 04 = and 05.=20 As discussed yesterday at the meeting, I feel the draft is in good = shape and will close WG LC for this document next week (Dec-11) and = proceed it to AD/IESG review and IETF LC. So if you have any last = comments or discusses for the ERS/SCVP, please submit them until this = deadline.=20 .=20 Greetings, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler This email is protected by domestic and international copyright laws = and treaties and is the property of Open Text Corporation, it may = contain confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------=_NextPart_000_00BD_01C83752.4F3C3190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable closing of WG LC for ERS/SCVP next week on = Dec-11
Tobias, the problem is that = here in the=20 US there are new and very formal hurdles for Long Term Document Storage = and=20 these are per the US Court Standard set in a case called "Lorraine v. = Markel",=20 and these now constrain the use of any "electronic media" storage = technology,=20 and whether ANY of us like this or not, this standard is IN FORCE and = will be in=20 force for the foreseeable future making the design of a protocol to = support long=20 term document archiving a key piece of any and all such public companies = operations.
 
The reality here is that = LTANS was=20 given a guarantee on its deployment if it will embrace and meet these = standards,=20 and if not the adoption of LTANS will become a pariah in my opinion = since=20 company's will not be able to rely on protocols which do not allow them = to meet=20 their new digital evidence needs.

It is for that reason I suggest adding another I-D on Digital = Evidence=20 Compliance to the WG's Deliverables.
 
I will be filing a prototype for this if the WG is interested = sometime=20 early next week but I want to know up front that this is not a wasted = effort as=20 I am pretty busy now.

Todd Glassey CISM CIFI
CTO Wireless-Time.COM
 ------=_NextPart_000_00BD_01C83752.4F3C3190-- From owner-ietf-ltans@mail.imc.org Thu Dec 06 08:19:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0GdH-00085k-1u for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 06 Dec 2007 08:19:15 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0GdD-0005sB-8c for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 06 Dec 2007 08:19:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6Cq1Nh032204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2007 05:52:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6Cq1Vs032203; Thu, 6 Dec 2007 05:52:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6Cpvb0032190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Dec 2007 05:51:59 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.89.208] (sitp2_133.sit.fraunhofer.de [141.12.69.133]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id lB6CpmUO022197; Thu, 6 Dec 2007 13:51:48 +0100 Message-ID: <4757F05F.6080604@sit.fraunhofer.de> Date: Thu, 06 Dec 2007 13:51:43 +0100 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Turner, Sean P." CC: ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> In-Reply-To: <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020703090304090908030601" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 This is a cryptographically signed message in MIME format. --------------ms020703090304090908030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We think, You misunderstood our last post. With the mentioned structure (AlgorithmValidityInfo) we wanted to show that we CANNOT use the AlgorithmIdentifier. The reason is, we cannot model the following cases: 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in case of DSA). 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) The main problem is that AlgorithmIdentifier describes entirely one algorithm with all its parameters. Therefor it is not possible to set different constraints for the parameters. so & tk Turner, Sean P. schrieb: > This would work for me. > > spt > >> -----Original Message----- >> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >> Sent: Wednesday, December 05, 2007 8:02 AM >> To: Turner, Sean P. >> Cc: ietf-ltans@imc.org >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >> The problem with your suggested syntax is the definition of >> the our constraints. If we used the RFC3280 >> AlgorithmIdentifier structure, we would integrate the >> constraints as follows: >> >> AlgorithmValidityInfo ::= SEQUENCE { >> identifier AlgorithmIdentifier, >> constraint CHOICE { >> exact [0] OCTET STRING, >> min [1] OCTET STRING, >> max [2] OCTET STRING, >> range [3] Range, >> other [4] OtherConstraints >> validity Validity OPTIONAL, >> information Information OPTIONAL } >> >> It's not possible to determine constraints for more than one >> parameter (e.g. p > 1024 and q > 160 in case of DSA). >> Additionally defining ranges is impossible (e.g. modulus < >> 2048 and modulus > 1024). >> >> >> so & tk >> >> >> Turner, Sean P. schrieb: >>> I'm only commenting on the Parameter structure in the ASN.1. I think >>> that it might be better to change Algorithm to be a sequence of >>> algorithmIdentifier, validity, and information - call it >>> AlgorithmValidityInfo. I suggest this for two reasons: >>> >>> 1. The AlgorithmIdentifier structure that is used to assign an >>> algorithm's object identifier also define the parameters. So it >>> probably makes sense to reuse this structure. >>> >>> 2. The parameters structures for some of the newer >> algorithms is quite >>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >> [RFC3279] >>> aren't just an OID they are nested structure. >>> >>> (not sure how to do it in XML) >>> >>> Replace: >>> >>> Algorithm ::= SEQUENCE { >>> algorithmIdentifier AlgID, >>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>> validity [1] Validity, >>> information [2] SEQUENCE OF UTF8String OPTIONAL >>> } >>> >>> AlgID ::= SEQUENCE { >>> name UTF8String, >>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>> uri [1] SEQUENCE OF IA5String OPTIONAL >>> } >>> >>> Parameter ::= SEQUENCE { >>> name UTF8String, >>> constraint CHOICE { >>> exact [0] OCTET STRING, >>> min [1] OCTET STRING, >>> max [2] OCTET STRING, >>> range [3] Range, >>> other [4] OtherConstraints >>> } >>> } >>> >>> With: >>> >>> AlgorithmValidityInfo ::= SEQUENCE { >>> identifier AlgorithmIdentifier, >>> validity Validity OPTIONAL, >>> information Information OPTIONAL } >>> >>> Validity ::= SEQUENCE { >>> start [0] GeneralizedTime OPTIONAL, >>> end [1] GeneralizedTime OPTIONAL } >>> >>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>> >>> -- From RFC3280 >>> AlgorithmIdentifier ::= SEQUENCE { >>> algorithm OBJECT IDENTIFIER, >>> parameters ANY DEFINED BY algorithm OPTIONAL } >>> -- contains a value of the type >>> -- registered for use with the >>> -- algorithm object identifier value >>> >>> spt >>> >>> > > --------------ms020703090304090908030601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9 6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47 IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN +6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh 6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1 bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6 DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMDYxMjUxNDNaMCMGCSqGSIb3 DQEJBDEWBBR49lOjDD4NDSMsr8w1cf5CRq6rnDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAHdXrgpUwdZJSPbIeb+LPyH/W82zqbymqfxqxw91bLSg/wE9zq7IvJZK aghNA86rnvrpWwLtsj3ZOK/yhRx4hjdTbyC3q12lIU58Yf1EkuGciRfY60Cs4suJ0BtMLk7P 27BIWF6xj31D5cLdTTjxYqa5olvQbuVguLP1+GF12OEouWRb+ikMAsa/ON3KaLkL9GhoHQuu wsHcB5KoRIa3BwlrsY0n2ivMLpxOxx3M4h9o45j/wVkzrl6C5rpDRT7y3HNzqtM1ZFoOHxCR CPHwak5wirp7dYrt1S6EHPzwRJyb0ny3ArwMw5hPhFvryi+DHjOq8v0P7a8ZgR+dT0xAU5MA AAAAAAA= --------------ms020703090304090908030601-- From owner-ietf-ltans@mail.imc.org Thu Dec 06 12:44:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KlZ-0007in-40 for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 06 Dec 2007 12:44:05 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0KlY-0001OF-4c for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 06 Dec 2007 12:44:05 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HWARY059510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2007 10:32:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6HWAk2059509; Thu, 6 Dec 2007 10:32:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB6HW8Jq059501 for ; Thu, 6 Dec 2007 10:32:09 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 54193 invoked from network); 6 Dec 2007 17:32:08 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@216.18.3.1 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 6 Dec 2007 17:32:07 -0000 X-YMail-OSG: cOVgrfwVM1mZhXMM3cyftIrz5S2Hep2iOpEmNk6rQkS3XvfhTOI.6xDVfFj7kCDxBk8jC10_nvV_00yMKlPO9qGn7edKp2QAM1y8eowMTJZBM3KlDpEoaQ-- From: "Turner, Sean P." To: "'Thomas Kunz'" Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Thu, 6 Dec 2007 09:27:53 -0800 Organization: IECA, Inc. Message-ID: <00e601c8382d$560103d0$e8f9a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg4CH0cbP0CPmbjT7yyMmAM0/thrwAJBj/A In-Reply-To: <4757F05F.6080604@sit.fraunhofer.de> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Yes I did misunderstand. With algorithms like DSA where there are few parameters your structure might work but for EC algorithms (I attached some of the ASN.1 for their parameters) I don't think the flat sequence of will work. ECParameters ::= CHOICE { namedCurve CURVE.&id({NamedCurve}), specifiedCuve SpecifiedCurve, implicitCurve NULL } CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { ID &id } NamedCurve CURVE ::= { { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | ... -- Extensible } SpecifiedCurve ::= SEQUENCE { version SpecifiedCurveVersion ( ecpVer1 | ecpVer2 | ecpVer3 ), fieldID FieldID {{FieldTypes}}, curve Curve, -- Curve E base ECPoint, -- Base point P order INTEGER, -- Order n of the base point cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n hash HashAlgorithm OPTIONAL, ... -- Extensible } SpecifiedCurveVersion ::= INTEGER { ecpVer1(1), ecpVer2(2), ecpVer3(3), ... -- Extensible } FIELD-ID ::= TYPE-IDENTIFIER FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType FIELD-ID.&id({IOSet}), parameters FIELD-ID.&Type({IOSet}{@fieldType}) } FieldTypes FIELD-ID ::= { { Prime-p IDENTIFIED BY prime-field } | { Characteristic-two IDENTIFIED BY characteristic-two-field } | ... -- Extensible } prime-field OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } Prime-p ::= INTEGER characteristic-two-field OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } Characteristic-two ::= SEQUENCE { m INTEGER, -- Field size 2^m basis CHARACTERISTIC-TWO.&id({BasisTypes}), parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) } CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER BasisTypes CHARACTERISTIC-TWO ::= { { NULL IDENTIFIED BY gnBasis } | { Trinomial IDENTIFIED BY tpBasis } | { Pentanomial IDENTIFIED BY ppBasis } | ... -- Extensible } gnBasis OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) 1 } tpBasis OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) 2 } Trinomial ::= INTEGER ppBasis OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) 3 } Pentanomial ::= SEQUENCE { k1 INTEGER, -- k1 > 0 k2 INTEGER, -- k2 > k1 k3 INTEGER -- k3 > k2 } Curve ::= SEQUENCE { a FieldElement, b FieldElement, seed BIT STRING OPTIONAL -- Shall be present if used in SpecifiedCurve -- with version of ecdpVer2 or ecdpVer3 } FieldElement ::= OCTET STRING ECPoint ::= OCTET STRING >-----Original Message----- >From: owner-ietf-ltans@mail.imc.org >[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >Sent: Thursday, December 06, 2007 4:52 AM >To: Turner, Sean P. >Cc: ietf-ltans@imc.org >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >We think, You misunderstood our last post. >With the mentioned structure (AlgorithmValidityInfo) we wanted >to show that we CANNOT use the AlgorithmIdentifier. > >The reason is, we cannot model the following cases: >1. constraints for more than one parameter (e.g. p > 1024 and >q > 160 in case of DSA). >2. defining ranges is impossible (e.g. 1024 < modulus < 2048) > >The main problem is that AlgorithmIdentifier describes >entirely one algorithm with all its parameters. Therefor it is >not possible to set different constraints for the parameters. > >so & tk > > > >Turner, Sean P. schrieb: >> This would work for me. >> >> spt >> >>> -----Original Message----- >>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>> Sent: Wednesday, December 05, 2007 8:02 AM >>> To: Turner, Sean P. >>> Cc: ietf-ltans@imc.org >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>> >>> The problem with your suggested syntax is the definition of the our >>> constraints. If we used the RFC3280 AlgorithmIdentifier >structure, we >>> would integrate the constraints as follows: >>> >>> AlgorithmValidityInfo ::= SEQUENCE { >>> identifier AlgorithmIdentifier, >>> constraint CHOICE { >>> exact [0] OCTET STRING, >>> min [1] OCTET STRING, >>> max [2] OCTET STRING, >>> range [3] Range, >>> other [4] OtherConstraints >>> validity Validity OPTIONAL, >>> information Information OPTIONAL } >>> >>> It's not possible to determine constraints for more than one >>> parameter (e.g. p > 1024 and q > 160 in case of DSA). >>> Additionally defining ranges is impossible (e.g. modulus < >>> 2048 and modulus > 1024). >>> >>> >>> so & tk >>> >>> >>> Turner, Sean P. schrieb: >>>> I'm only commenting on the Parameter structure in the >ASN.1. I think >>>> that it might be better to change Algorithm to be a sequence of >>>> algorithmIdentifier, validity, and information - call it >>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>> >>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>> algorithm's object identifier also define the parameters. So it >>>> probably makes sense to reuse this structure. >>>> >>>> 2. The parameters structures for some of the newer >>> algorithms is quite >>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>> [RFC3279] >>>> aren't just an OID they are nested structure. >>>> >>>> (not sure how to do it in XML) >>>> >>>> Replace: >>>> >>>> Algorithm ::= SEQUENCE { >>>> algorithmIdentifier AlgID, >>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>> validity [1] Validity, >>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>> } >>>> >>>> AlgID ::= SEQUENCE { >>>> name UTF8String, >>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>> } >>>> >>>> Parameter ::= SEQUENCE { >>>> name UTF8String, >>>> constraint CHOICE { >>>> exact [0] OCTET STRING, >>>> min [1] OCTET STRING, >>>> max [2] OCTET STRING, >>>> range [3] Range, >>>> other [4] OtherConstraints >>>> } >>>> } >>>> >>>> With: >>>> >>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>> AlgorithmIdentifier, >>>> validity Validity OPTIONAL, >>>> information Information OPTIONAL } >>>> >>>> Validity ::= SEQUENCE { >>>> start [0] GeneralizedTime OPTIONAL, >>>> end [1] GeneralizedTime OPTIONAL } >>>> >>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>> >>>> -- From RFC3280 >>>> AlgorithmIdentifier ::= SEQUENCE { >>>> algorithm OBJECT IDENTIFIER, >>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>> -- contains a value of the type >>>> -- registered for use with the >>>> -- algorithm object >identifier value >>>> >>>> spt >>>> >>>> >> >> > From owner-ietf-ltans@mail.imc.org Fri Dec 07 10:20:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0f00-0000uX-GQ for ltans-archive-ba2WohFa@lists.ietf.org; Fri, 07 Dec 2007 10:20:20 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0ezx-00028A-Sk for ltans-archive-ba2WohFa@lists.ietf.org; Fri, 07 Dec 2007 10:20:20 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7F6HHa069200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2007 08:06:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB7F6HdJ069199; Fri, 7 Dec 2007 08:06:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7F6Ba5069188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Dec 2007 08:06:14 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.89.208] (sitp1_72.sit.fraunhofer.de [141.12.68.72]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id lB7F68oT008883; Fri, 7 Dec 2007 16:06:08 +0100 Message-ID: <4759615B.3000508@sit.fraunhofer.de> Date: Fri, 07 Dec 2007 16:06:03 +0100 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Turner, Sean P." CC: ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> In-Reply-To: <00e601c8382d$560103d0$e8f9a8c0@Wylie> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010203000101070907090001" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b This is a cryptographically signed message in MIME format. --------------ms010203000101070907090001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We think, our flat sequence is sufficient. The goal of a policy is to specify a range for specific (safety-critical) parameters of an algorithm. Therefor it's not necessary to define all parameters. In the evaluations of BSI and NIST (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only one value is defined (namely q). By NIST a q_length of 160 is suitable until 2010. In this case, the XML structure would be: EC-DSA 160 ... 160 2010-12-31 so & tk Turner, Sean P. schrieb: > Yes I did misunderstand. With algorithms like DSA where there are few > parameters your structure might work but for EC algorithms (I attached some > of the ASN.1 for their parameters) I don't think the flat sequence of will > work. > > ECParameters ::= CHOICE { > namedCurve CURVE.&id({NamedCurve}), > specifiedCuve SpecifiedCurve, > implicitCurve NULL > } > > CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } > WITH SYNTAX { ID &id } > > NamedCurve CURVE ::= { > { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | > { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | > { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | > { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | > { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | > ... -- Extensible > } > > SpecifiedCurve ::= SEQUENCE { > version SpecifiedCurveVersion > ( ecpVer1 | ecpVer2 | ecpVer3 ), > fieldID FieldID {{FieldTypes}}, > curve Curve, -- Curve E > base ECPoint, -- Base point P > order INTEGER, -- Order n of the base point > cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n > hash HashAlgorithm OPTIONAL, > ... -- Extensible > } > > SpecifiedCurveVersion ::= INTEGER { > ecpVer1(1), > ecpVer2(2), > ecpVer3(3), > ... -- Extensible > } > FIELD-ID ::= TYPE-IDENTIFIER > > FieldID { FIELD-ID:IOSet } ::= SEQUENCE { > fieldType FIELD-ID.&id({IOSet}), > parameters FIELD-ID.&Type({IOSet}{@fieldType}) > } > > FieldTypes FIELD-ID ::= { > { Prime-p IDENTIFIED BY prime-field } | > { Characteristic-two IDENTIFIED BY characteristic-two-field } | > ... -- Extensible > } > > prime-field OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } > > Prime-p ::= INTEGER > > characteristic-two-field OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } > > Characteristic-two ::= SEQUENCE { > m INTEGER, -- Field size 2^m > basis CHARACTERISTIC-TWO.&id({BasisTypes}), > parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) > } > > CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER > > BasisTypes CHARACTERISTIC-TWO ::= { > { NULL IDENTIFIED BY gnBasis } | > { Trinomial IDENTIFIED BY tpBasis } | > { Pentanomial IDENTIFIED BY ppBasis } | > ... -- Extensible > } > > gnBasis OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > characteristic-two-basis(2) 1 } > > tpBasis OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > characteristic-two-basis(2) 2 } > > Trinomial ::= INTEGER > > ppBasis OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > characteristic-two-basis(2) 3 } > > Pentanomial ::= SEQUENCE { > k1 INTEGER, -- k1 > 0 > k2 INTEGER, -- k2 > k1 > k3 INTEGER -- k3 > k2 > } > > Curve ::= SEQUENCE { > a FieldElement, > b FieldElement, > seed BIT STRING OPTIONAL > -- Shall be present if used in SpecifiedCurve > -- with version of ecdpVer2 or ecdpVer3 > } > FieldElement ::= OCTET STRING > > ECPoint ::= OCTET STRING > >> -----Original Message----- >> From: owner-ietf-ltans@mail.imc.org >> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >> Sent: Thursday, December 06, 2007 4:52 AM >> To: Turner, Sean P. >> Cc: ietf-ltans@imc.org >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >> We think, You misunderstood our last post. >> With the mentioned structure (AlgorithmValidityInfo) we wanted >> to show that we CANNOT use the AlgorithmIdentifier. >> >> The reason is, we cannot model the following cases: >> 1. constraints for more than one parameter (e.g. p > 1024 and >> q > 160 in case of DSA). >> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >> >> The main problem is that AlgorithmIdentifier describes >> entirely one algorithm with all its parameters. Therefor it is >> not possible to set different constraints for the parameters. >> >> so & tk >> >> >> >> Turner, Sean P. schrieb: >>> This would work for me. >>> >>> spt >>> >>>> -----Original Message----- >>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>>> Sent: Wednesday, December 05, 2007 8:02 AM >>>> To: Turner, Sean P. >>>> Cc: ietf-ltans@imc.org >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>> >>>> The problem with your suggested syntax is the definition of the our >>>> constraints. If we used the RFC3280 AlgorithmIdentifier >> structure, we >>>> would integrate the constraints as follows: >>>> >>>> AlgorithmValidityInfo ::= SEQUENCE { >>>> identifier AlgorithmIdentifier, >>>> constraint CHOICE { >>>> exact [0] OCTET STRING, >>>> min [1] OCTET STRING, >>>> max [2] OCTET STRING, >>>> range [3] Range, >>>> other [4] OtherConstraints >>>> validity Validity OPTIONAL, >>>> information Information OPTIONAL } >>>> >>>> It's not possible to determine constraints for more than one >>>> parameter (e.g. p > 1024 and q > 160 in case of DSA). >>>> Additionally defining ranges is impossible (e.g. modulus < >>>> 2048 and modulus > 1024). >>>> >>>> >>>> so & tk >>>> >>>> >>>> Turner, Sean P. schrieb: >>>>> I'm only commenting on the Parameter structure in the >> ASN.1. I think >>>>> that it might be better to change Algorithm to be a sequence of >>>>> algorithmIdentifier, validity, and information - call it >>>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>>> >>>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>>> algorithm's object identifier also define the parameters. So it >>>>> probably makes sense to reuse this structure. >>>>> >>>>> 2. The parameters structures for some of the newer >>>> algorithms is quite >>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>>> [RFC3279] >>>>> aren't just an OID they are nested structure. >>>>> >>>>> (not sure how to do it in XML) >>>>> >>>>> Replace: >>>>> >>>>> Algorithm ::= SEQUENCE { >>>>> algorithmIdentifier AlgID, >>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>>> validity [1] Validity, >>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>>> } >>>>> >>>>> AlgID ::= SEQUENCE { >>>>> name UTF8String, >>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>>> } >>>>> >>>>> Parameter ::= SEQUENCE { >>>>> name UTF8String, >>>>> constraint CHOICE { >>>>> exact [0] OCTET STRING, >>>>> min [1] OCTET STRING, >>>>> max [2] OCTET STRING, >>>>> range [3] Range, >>>>> other [4] OtherConstraints >>>>> } >>>>> } >>>>> >>>>> With: >>>>> >>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>>> AlgorithmIdentifier, >>>>> validity Validity OPTIONAL, >>>>> information Information OPTIONAL } >>>>> >>>>> Validity ::= SEQUENCE { >>>>> start [0] GeneralizedTime OPTIONAL, >>>>> end [1] GeneralizedTime OPTIONAL } >>>>> >>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>>> >>>>> -- From RFC3280 >>>>> AlgorithmIdentifier ::= SEQUENCE { >>>>> algorithm OBJECT IDENTIFIER, >>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>>> -- contains a value of the type >>>>> -- registered for use with the >>>>> -- algorithm object >> identifier value >>>>> spt >>>>> >>>>> >>> > > --------------ms010203000101070907090001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9 6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47 IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN +6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh 6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1 bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6 DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMDcxNTA2MDNaMCMGCSqGSIb3 DQEJBDEWBBT/XF1wW+cgTWKlTbWni+nYPEmhkTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAIAp1PTSg7UmnDno2JL/vKIizyn31bRgX2BcT0pwPaV8AYdFDlEZ94ii hsc8B2wWsHeLpFAnsLvidHWo1L56MoK71DjKypCEWdOeqmxZPwZeMsn5z/HInX4vcYzP1opI H+OalEaHKvlF0dyTvv3bNH8M4Jzsl5vIgJ/wOOcCzlkF8AG25tBGgBuHb7W5U62QGddoJ3Cy 8OkW34qchPJnP1GFWh/KdcCwS6/bFlCR8Z0QU2924PrljYEgPuQCIV/gOVTOOpjOkLiWMBDA DPu19k4UGbENep9wUNhMejpL4EwQxzbbmTIqf4Nt+oKXnsuwfnbL3wpNPgGrjlsrqHgHsvgA AAAAAAA= --------------ms010203000101070907090001-- From owner-ietf-ltans@mail.imc.org Sat Dec 08 10:44:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J11r7-0002Q4-PC for ltans-archive-ba2WohFa@lists.ietf.org; Sat, 08 Dec 2007 10:44:41 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J11r6-0007HM-E9 for ltans-archive-ba2WohFa@lists.ietf.org; Sat, 08 Dec 2007 10:44:41 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FT1NE072305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Dec 2007 08:29:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB8FT19i072304; Sat, 8 Dec 2007 08:29:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FT09u072298 for ; Sat, 8 Dec 2007 08:29:00 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tG8kgxK8HTzsS3q1qAmX5pg3p3Z1cBGa7pclR+zGMYtff4FHuNAvKgU9RP3PJUpH; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J11bu-0000lb-6N; Sat, 08 Dec 2007 10:28:58 -0500 Message-ID: <002701c839af$0d1d4060$6401a8c0@tsg1> From: "TS Glassey" To: "Thomas Kunz" , "Turner, Sean P." Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> <4759615B.3000508@sit.fraunhofer.de> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Date: Sat, 8 Dec 2007 06:43:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79615a5274e6de898cac121fcc226ed08c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Maybe not from a control perspective but that is only half of the picture. The key value of LTANS as a 'thing' is that is would need to meet both the legal and emerging document management processes or else those parties who are constrained by those frameworks will not be able to use it, nor will those parties attached to the people so constrained. Todd Glassey ----- Original Message ----- From: "Thomas Kunz" To: "Turner, Sean P." Cc: Sent: Friday, December 07, 2007 7:06 AM Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > We think, our flat sequence is sufficient. > > The goal of a policy is to specify a range for specific (safety-critical) > parameters of an algorithm. Therefor it's not necessary to define all > parameters. > > In the evaluations of BSI and NIST > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only > one value is defined (namely q). By NIST a q_length of 160 is suitable > until 2010. > > In this case, the XML structure would be: > > > > EC-DSA 160 > ... > > 160 > 2010-12-31 > > > > so & tk > > > > > > Turner, Sean P. schrieb: >> Yes I did misunderstand. With algorithms like DSA where there are few >> parameters your structure might work but for EC algorithms (I attached >> some >> of the ASN.1 for their parameters) I don't think the flat sequence of >> will >> work. >> >> ECParameters ::= CHOICE { >> namedCurve CURVE.&id({NamedCurve}), >> specifiedCuve SpecifiedCurve, >> implicitCurve NULL >> } >> >> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >> WITH SYNTAX { ID &id } >> >> NamedCurve CURVE ::= { >> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >> ... -- Extensible >> } >> >> SpecifiedCurve ::= SEQUENCE { >> version SpecifiedCurveVersion >> ( ecpVer1 | ecpVer2 | ecpVer3 ), >> fieldID FieldID {{FieldTypes}}, >> curve Curve, -- Curve E >> base ECPoint, -- Base point P >> order INTEGER, -- Order n of the base point >> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >> hash HashAlgorithm OPTIONAL, >> ... -- Extensible >> } >> >> SpecifiedCurveVersion ::= INTEGER { >> ecpVer1(1), >> ecpVer2(2), >> ecpVer3(3), >> ... -- Extensible >> } >> FIELD-ID ::= TYPE-IDENTIFIER >> >> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >> FIELD-ID.&id({IOSet}), >> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >> } >> >> FieldTypes FIELD-ID ::= { >> { Prime-p IDENTIFIED BY prime-field } | >> { Characteristic-two IDENTIFIED BY characteristic-two-field } | >> ... -- Extensible >> } >> >> prime-field OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } >> >> Prime-p ::= INTEGER >> >> characteristic-two-field OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } >> >> Characteristic-two ::= SEQUENCE { >> m INTEGER, -- Field size 2^m >> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >> } >> >> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >> >> BasisTypes CHARACTERISTIC-TWO ::= { >> { NULL IDENTIFIED BY gnBasis } | >> { Trinomial IDENTIFIED BY tpBasis } | >> { Pentanomial IDENTIFIED BY ppBasis } | >> ... -- Extensible >> } >> >> gnBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 1 } >> >> tpBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 2 } >> >> Trinomial ::= INTEGER >> >> ppBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 3 } >> >> Pentanomial ::= SEQUENCE { >> k1 INTEGER, -- k1 > 0 >> k2 INTEGER, -- k2 > k1 >> k3 INTEGER -- k3 > k2 >> } >> >> Curve ::= SEQUENCE { >> a FieldElement, >> b FieldElement, >> seed BIT STRING OPTIONAL >> -- Shall be present if used in SpecifiedCurve >> -- with version of ecdpVer2 or ecdpVer3 >> } >> FieldElement ::= OCTET STRING >> >> ECPoint ::= OCTET STRING >>> -----Original Message----- >>> From: owner-ietf-ltans@mail.imc.org >>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >>> Sent: Thursday, December 06, 2007 4:52 AM >>> To: Turner, Sean P. >>> Cc: ietf-ltans@imc.org >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>> >>> We think, You misunderstood our last post. >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show >>> that we CANNOT use the AlgorithmIdentifier. >>> >>> The reason is, we cannot model the following cases: >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in >>> case of DSA). >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >>> >>> The main problem is that AlgorithmIdentifier describes entirely one >>> algorithm with all its parameters. Therefor it is not possible to set >>> different constraints for the parameters. >>> >>> so & tk >>> >>> >>> >>> Turner, Sean P. schrieb: >>>> This would work for me. >>>> >>>> spt >>>> >>>>> -----Original Message----- >>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>>>> Sent: Wednesday, December 05, 2007 8:02 AM >>>>> To: Turner, Sean P. >>>>> Cc: ietf-ltans@imc.org >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>>> >>>>> The problem with your suggested syntax is the definition of the our >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >>> structure, we >>>>> would integrate the constraints as follows: >>>>> >>>>> AlgorithmValidityInfo ::= SEQUENCE { >>>>> identifier AlgorithmIdentifier, >>>>> constraint CHOICE { >>>>> exact [0] OCTET STRING, >>>>> min [1] OCTET STRING, >>>>> max [2] OCTET STRING, >>>>> range [3] Range, >>>>> other [4] OtherConstraints >>>>> validity Validity OPTIONAL, >>>>> information Information OPTIONAL } >>>>> >>>>> It's not possible to determine constraints for more than one parameter >>>>> (e.g. p > 1024 and q > 160 in case of DSA). >>>>> Additionally defining ranges is impossible (e.g. modulus < >>>>> 2048 and modulus > 1024). >>>>> >>>>> >>>>> so & tk >>>>> >>>>> >>>>> Turner, Sean P. schrieb: >>>>>> I'm only commenting on the Parameter structure in the >>> ASN.1. I think >>>>>> that it might be better to change Algorithm to be a sequence of >>>>>> algorithmIdentifier, validity, and information - call it >>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>>>> >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>>>> algorithm's object identifier also define the parameters. So it >>>>>> probably makes sense to reuse this structure. >>>>>> >>>>>> 2. The parameters structures for some of the newer >>>>> algorithms is quite >>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>>>> [RFC3279] >>>>>> aren't just an OID they are nested structure. >>>>>> >>>>>> (not sure how to do it in XML) >>>>>> >>>>>> Replace: >>>>>> >>>>>> Algorithm ::= SEQUENCE { >>>>>> algorithmIdentifier AlgID, >>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>>>> validity [1] Validity, >>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>>>> } >>>>>> >>>>>> AlgID ::= SEQUENCE { >>>>>> name UTF8String, >>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>>>> } >>>>>> >>>>>> Parameter ::= SEQUENCE { >>>>>> name UTF8String, >>>>>> constraint CHOICE { >>>>>> exact [0] OCTET STRING, >>>>>> min [1] OCTET STRING, >>>>>> max [2] OCTET STRING, >>>>>> range [3] Range, >>>>>> other [4] OtherConstraints >>>>>> } >>>>>> } >>>>>> >>>>>> With: >>>>>> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>>>> AlgorithmIdentifier, >>>>>> validity Validity OPTIONAL, >>>>>> information Information OPTIONAL } >>>>>> >>>>>> Validity ::= SEQUENCE { >>>>>> start [0] GeneralizedTime OPTIONAL, >>>>>> end [1] GeneralizedTime OPTIONAL } >>>>>> >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>>>> >>>>>> -- From RFC3280 >>>>>> AlgorithmIdentifier ::= SEQUENCE { >>>>>> algorithm OBJECT IDENTIFIER, >>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>>>> -- contains a value of the type >>>>>> -- registered for use with the >>>>>> -- algorithm object >>> identifier value >>>>>> spt >>>>>> >>>>>> >>>> >> >> > From owner-ietf-ltans@mail.imc.org Sat Dec 08 18:50:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J19Qx-0001cX-AM for ltans-archive-ba2WohFa@lists.ietf.org; Sat, 08 Dec 2007 18:50:11 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J19Qu-0001Bv-Pk for ltans-archive-ba2WohFa@lists.ietf.org; Sat, 08 Dec 2007 18:50:11 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8NWHsK004351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Dec 2007 16:32:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB8NWHrt004350; Sat, 8 Dec 2007 16:32:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8NWGMd004343 for ; Sat, 8 Dec 2007 16:32:16 -0700 (MST) (envelope-from jwkckid1@ix.netcom.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=m0wy09eVbWRvVYdIYJ+0Jvt0Y+t6mc1QTZeKoD6dp7ibHwUc4pW7JuzlfEiwDqvB; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J199Z-00033i-Nn; Sat, 08 Dec 2007 18:32:13 -0500 Received: from 4.226.15.142 by webmail.pas.earthlink.net with HTTP; Sat, 8 Dec 2007 18:32:13 -0500 Message-ID: <24797949.1197156733684.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Sat, 8 Dec 2007 18:32:13 -0500 (EST) From: jwkckid1@ix.netcom.com Reply-To: jwkckid1@ix.netcom.com To: TS Glassey Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Cc: ietf-ltans@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688498c9a26aa0701920c3ad97b9eea82b4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Todd and all, I believe Todd has a very good and valid point here. A flat sequence seems very much less than sufficient. Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 -----Original Message----- >From: TS Glassey >Sent: Dec 8, 2007 9:43 AM >To: Thomas Kunz , "Turner, Sean P." >Cc: ietf-ltans@imc.org >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > >Maybe not from a control perspective but that is only half of the picture. >The key value of LTANS as a 'thing' is that is would need to meet both the >legal and emerging document management processes or else those parties who >are constrained by those frameworks will not be able to use it, nor will >those parties attached to the people so constrained. > >Todd Glassey > >----- Original Message ----- >From: "Thomas Kunz" >To: "Turner, Sean P." >Cc: >Sent: Friday, December 07, 2007 7:06 AM >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > >> We think, our flat sequence is sufficient. >> >> The goal of a policy is to specify a range for specific (safety-critical) >> parameters of an algorithm. Therefor it's not necessary to define all >> parameters. >> >> In the evaluations of BSI and NIST >> (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only >> one value is defined (namely q). By NIST a q_length of 160 is suitable >> until 2010. >> >> In this case, the XML structure would be: >> >> >> >> EC-DSA 160 >> ... >> >> 160 >> 2010-12-31 >> >> >> >> so & tk >> >> >> >> >> >> Turner, Sean P. schrieb: >>> Yes I did misunderstand. With algorithms like DSA where there are few >>> parameters your structure might work but for EC algorithms (I attached >>> some >>> of the ASN.1 for their parameters) I don't think the flat sequence of >>> will >>> work. >>> >>> ECParameters ::= CHOICE { >>> namedCurve CURVE.&id({NamedCurve}), >>> specifiedCuve SpecifiedCurve, >>> implicitCurve NULL >>> } >>> >>> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >>> WITH SYNTAX { ID &id } >>> >>> NamedCurve CURVE ::= { >>> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >>> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >>> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >>> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >>> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >>> ... -- Extensible >>> } >>> >>> SpecifiedCurve ::= SEQUENCE { >>> version SpecifiedCurveVersion >>> ( ecpVer1 | ecpVer2 | ecpVer3 ), >>> fieldID FieldID {{FieldTypes}}, >>> curve Curve, -- Curve E >>> base ECPoint, -- Base point P >>> order INTEGER, -- Order n of the base point >>> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >>> hash HashAlgorithm OPTIONAL, >>> ... -- Extensible >>> } >>> >>> SpecifiedCurveVersion ::= INTEGER { >>> ecpVer1(1), >>> ecpVer2(2), >>> ecpVer3(3), >>> ... -- Extensible >>> } >>> FIELD-ID ::= TYPE-IDENTIFIER >>> >>> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >>> FIELD-ID.&id({IOSet}), >>> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >>> } >>> >>> FieldTypes FIELD-ID ::= { >>> { Prime-p IDENTIFIED BY prime-field } | >>> { Characteristic-two IDENTIFIED BY characteristic-two-field } | >>> ... -- Extensible >>> } >>> >>> prime-field OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } >>> >>> Prime-p ::= INTEGER >>> >>> characteristic-two-field OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } >>> >>> Characteristic-two ::= SEQUENCE { >>> m INTEGER, -- Field size 2^m >>> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >>> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >>> } >>> >>> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >>> >>> BasisTypes CHARACTERISTIC-TWO ::= { >>> { NULL IDENTIFIED BY gnBasis } | >>> { Trinomial IDENTIFIED BY tpBasis } | >>> { Pentanomial IDENTIFIED BY ppBasis } | >>> ... -- Extensible >>> } >>> >>> gnBasis OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >>> characteristic-two-basis(2) 1 } >>> >>> tpBasis OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >>> characteristic-two-basis(2) 2 } >>> >>> Trinomial ::= INTEGER >>> >>> ppBasis OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >>> characteristic-two-basis(2) 3 } >>> >>> Pentanomial ::= SEQUENCE { >>> k1 INTEGER, -- k1 > 0 >>> k2 INTEGER, -- k2 > k1 >>> k3 INTEGER -- k3 > k2 >>> } >>> >>> Curve ::= SEQUENCE { >>> a FieldElement, >>> b FieldElement, >>> seed BIT STRING OPTIONAL >>> -- Shall be present if used in SpecifiedCurve >>> -- with version of ecdpVer2 or ecdpVer3 >>> } >>> FieldElement ::= OCTET STRING >>> >>> ECPoint ::= OCTET STRING >>>> -----Original Message----- >>>> From: owner-ietf-ltans@mail.imc.org >>>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >>>> Sent: Thursday, December 06, 2007 4:52 AM >>>> To: Turner, Sean P. >>>> Cc: ietf-ltans@imc.org >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>> >>>> We think, You misunderstood our last post. >>>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show >>>> that we CANNOT use the AlgorithmIdentifier. >>>> >>>> The reason is, we cannot model the following cases: >>>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in >>>> case of DSA). >>>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >>>> >>>> The main problem is that AlgorithmIdentifier describes entirely one >>>> algorithm with all its parameters. Therefor it is not possible to set >>>> different constraints for the parameters. >>>> >>>> so & tk >>>> >>>> >>>> >>>> Turner, Sean P. schrieb: >>>>> This would work for me. >>>>> >>>>> spt >>>>> >>>>>> -----Original Message----- >>>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>>>>> Sent: Wednesday, December 05, 2007 8:02 AM >>>>>> To: Turner, Sean P. >>>>>> Cc: ietf-ltans@imc.org >>>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>>>> >>>>>> The problem with your suggested syntax is the definition of the our >>>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >>>> structure, we >>>>>> would integrate the constraints as follows: >>>>>> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { >>>>>> identifier AlgorithmIdentifier, >>>>>> constraint CHOICE { >>>>>> exact [0] OCTET STRING, >>>>>> min [1] OCTET STRING, >>>>>> max [2] OCTET STRING, >>>>>> range [3] Range, >>>>>> other [4] OtherConstraints >>>>>> validity Validity OPTIONAL, >>>>>> information Information OPTIONAL } >>>>>> >>>>>> It's not possible to determine constraints for more than one parameter >>>>>> (e.g. p > 1024 and q > 160 in case of DSA). >>>>>> Additionally defining ranges is impossible (e.g. modulus < >>>>>> 2048 and modulus > 1024). >>>>>> >>>>>> >>>>>> so & tk >>>>>> >>>>>> >>>>>> Turner, Sean P. schrieb: >>>>>>> I'm only commenting on the Parameter structure in the >>>> ASN.1. I think >>>>>>> that it might be better to change Algorithm to be a sequence of >>>>>>> algorithmIdentifier, validity, and information - call it >>>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>>>>> >>>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>>>>> algorithm's object identifier also define the parameters. So it >>>>>>> probably makes sense to reuse this structure. >>>>>>> >>>>>>> 2. The parameters structures for some of the newer >>>>>> algorithms is quite >>>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>>>>> [RFC3279] >>>>>>> aren't just an OID they are nested structure. >>>>>>> >>>>>>> (not sure how to do it in XML) >>>>>>> >>>>>>> Replace: >>>>>>> >>>>>>> Algorithm ::= SEQUENCE { >>>>>>> algorithmIdentifier AlgID, >>>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>>>>> validity [1] Validity, >>>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>>>>> } >>>>>>> >>>>>>> AlgID ::= SEQUENCE { >>>>>>> name UTF8String, >>>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>>>>> } >>>>>>> >>>>>>> Parameter ::= SEQUENCE { >>>>>>> name UTF8String, >>>>>>> constraint CHOICE { >>>>>>> exact [0] OCTET STRING, >>>>>>> min [1] OCTET STRING, >>>>>>> max [2] OCTET STRING, >>>>>>> range [3] Range, >>>>>>> other [4] OtherConstraints >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> With: >>>>>>> >>>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>>>>> AlgorithmIdentifier, >>>>>>> validity Validity OPTIONAL, >>>>>>> information Information OPTIONAL } >>>>>>> >>>>>>> Validity ::= SEQUENCE { >>>>>>> start [0] GeneralizedTime OPTIONAL, >>>>>>> end [1] GeneralizedTime OPTIONAL } >>>>>>> >>>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>>>>> >>>>>>> -- From RFC3280 >>>>>>> AlgorithmIdentifier ::= SEQUENCE { >>>>>>> algorithm OBJECT IDENTIFIER, >>>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>>>>> -- contains a value of the type >>>>>>> -- registered for use with the >>>>>>> -- algorithm object >>>> identifier value >>>>>>> spt >>>>>>> >>>>>>> >>>>> >>> >>> >> > From owner-ietf-ltans@mail.imc.org Mon Dec 10 13:43:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1nbE-0007wq-Nz for ltans-archive-ba2WohFa@lists.ietf.org; Mon, 10 Dec 2007 13:43:28 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1nbB-0008WB-C9 for ltans-archive-ba2WohFa@lists.ietf.org; Mon, 10 Dec 2007 13:43:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIWBV0028991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 11:32:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBAIWBsW028990; Mon, 10 Dec 2007 11:32:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIWAjY028983 for ; Mon, 10 Dec 2007 11:32:10 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lBAIW68e004870; Mon, 10 Dec 2007 19:32:06 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg03.opentext.net [149.235.128.137]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lBAIW3sR021593; Mon, 10 Dec 2007 13:32:04 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Mon, 10 Dec 2007 19:32:02 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78680201D243@MUCXGC2.opentext.net> In-reply-to: <24797949.1197156733684.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment on draft-ietf-ltans-dssc-01.txt Thread-Index: Acg59WqwzVETIJejRcuInCvYHergQQBZLLDw X-Priority: 5 Importance: low From: "Tobias Gondrom" To: , "TS Glassey" Cc: X-Archived: msg.BGttUkX:2007-12-10:mucpm02.smtp.dmz.opentext.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lBAIWBjY028984 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: df1883a27a831c1ea5e8cfe5eb3ad38e Hi all, hm actually I do not understand the argument or miss the point. Could you please explain a bit more why your argument mandates against a flat or for a non-flat structure of the DSSC format? Thanks, Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of jwkckid1@ix.netcom.com > Sent: Sunday, December 09, 2007 12:32 AM > To: TS Glassey > Cc: ietf-ltans@imc.org > Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > Todd and all, > > I believe Todd has a very good and valid point here. > A flat sequence seems very much less than sufficient. > > Regards, > > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is very > often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. > of > Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail > jwkckid1@ix.netcom.com > Phone: 214-244-4827 > > > -----Original Message----- > >From: TS Glassey > >Sent: Dec 8, 2007 9:43 AM > >To: Thomas Kunz , "Turner, Sean P." > > >Cc: ietf-ltans@imc.org > >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > > > >Maybe not from a control perspective but that is only half of the > picture. > >The key value of LTANS as a 'thing' is that is would need to meet both > the > >legal and emerging document management processes or else those parties > who > >are constrained by those frameworks will not be able to use it, nor will > >those parties attached to the people so constrained. > > > >Todd Glassey > > > >----- Original Message ----- > >From: "Thomas Kunz" > >To: "Turner, Sean P." > >Cc: > >Sent: Friday, December 07, 2007 7:06 AM > >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > > > >> We think, our flat sequence is sufficient. > >> > >> The goal of a policy is to specify a range for specific (safety- > critical) > >> parameters of an algorithm. Therefor it's not necessary to define all > >> parameters. > >> > >> In the evaluations of BSI and NIST > >> (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms > only > >> one value is defined (namely q). By NIST a q_length of 160 is suitable > >> until 2010. > >> > >> In this case, the XML structure would be: > >> > >> > >> > >> EC-DSA 160 > >> ... > >> > >> 160 > >> 2010-12-31 > >> > >> > >> > >> so & tk > >> > >> > >> > >> > >> > >> Turner, Sean P. schrieb: > >>> Yes I did misunderstand. With algorithms like DSA where there are few > >>> parameters your structure might work but for EC algorithms (I attached > >>> some > >>> of the ASN.1 for their parameters) I don't think the flat sequence of > >>> will > >>> work. > >>> > >>> ECParameters ::= CHOICE { > >>> namedCurve CURVE.&id({NamedCurve}), > >>> specifiedCuve SpecifiedCurve, > >>> implicitCurve NULL > >>> } > >>> > >>> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } > >>> WITH SYNTAX { ID &id } > >>> > >>> NamedCurve CURVE ::= { > >>> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | > >>> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | > >>> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | > >>> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | > >>> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | > >>> ... -- Extensible > >>> } > >>> > >>> SpecifiedCurve ::= SEQUENCE { > >>> version SpecifiedCurveVersion > >>> ( ecpVer1 | ecpVer2 | ecpVer3 ), > >>> fieldID FieldID {{FieldTypes}}, > >>> curve Curve, -- Curve E > >>> base ECPoint, -- Base point P > >>> order INTEGER, -- Order n of the base point > >>> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n > >>> hash HashAlgorithm OPTIONAL, > >>> ... -- Extensible > >>> } > >>> > >>> SpecifiedCurveVersion ::= INTEGER { > >>> ecpVer1(1), > >>> ecpVer2(2), > >>> ecpVer3(3), > >>> ... -- Extensible > >>> } > >>> FIELD-ID ::= TYPE-IDENTIFIER > >>> > >>> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType > >>> FIELD-ID.&id({IOSet}), > >>> parameters FIELD-ID.&Type({IOSet}{@fieldType}) > >>> } > >>> > >>> FieldTypes FIELD-ID ::= { > >>> { Prime-p IDENTIFIED BY prime-field } | > >>> { Characteristic-two IDENTIFIED BY characteristic-two-field } | > >>> ... -- Extensible > >>> } > >>> > >>> prime-field OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } > >>> > >>> Prime-p ::= INTEGER > >>> > >>> characteristic-two-field OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } > >>> > >>> Characteristic-two ::= SEQUENCE { > >>> m INTEGER, -- Field size 2^m > >>> basis CHARACTERISTIC-TWO.&id({BasisTypes}), > >>> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) > >>> } > >>> > >>> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER > >>> > >>> BasisTypes CHARACTERISTIC-TWO ::= { > >>> { NULL IDENTIFIED BY gnBasis } | > >>> { Trinomial IDENTIFIED BY tpBasis } | > >>> { Pentanomial IDENTIFIED BY ppBasis } | > >>> ... -- Extensible > >>> } > >>> > >>> gnBasis OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >>> characteristic-two-basis(2) 1 } > >>> > >>> tpBasis OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >>> characteristic-two-basis(2) 2 } > >>> > >>> Trinomial ::= INTEGER > >>> > >>> ppBasis OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >>> characteristic-two-basis(2) 3 } > >>> > >>> Pentanomial ::= SEQUENCE { > >>> k1 INTEGER, -- k1 > 0 > >>> k2 INTEGER, -- k2 > k1 > >>> k3 INTEGER -- k3 > k2 > >>> } > >>> > >>> Curve ::= SEQUENCE { > >>> a FieldElement, > >>> b FieldElement, > >>> seed BIT STRING OPTIONAL > >>> -- Shall be present if used in SpecifiedCurve > >>> -- with version of ecdpVer2 or ecdpVer3 > >>> } > >>> FieldElement ::= OCTET STRING > >>> > >>> ECPoint ::= OCTET STRING > >>>> -----Original Message----- > >>>> From: owner-ietf-ltans@mail.imc.org > >>>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > >>>> Sent: Thursday, December 06, 2007 4:52 AM > >>>> To: Turner, Sean P. > >>>> Cc: ietf-ltans@imc.org > >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>>> > >>>> We think, You misunderstood our last post. > >>>> With the mentioned structure (AlgorithmValidityInfo) we wanted to > show > >>>> that we CANNOT use the AlgorithmIdentifier. > >>>> > >>>> The reason is, we cannot model the following cases: > >>>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 > in > >>>> case of DSA). > >>>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) > >>>> > >>>> The main problem is that AlgorithmIdentifier describes entirely one > >>>> algorithm with all its parameters. Therefor it is not possible to set > >>>> different constraints for the parameters. > >>>> > >>>> so & tk > >>>> > >>>> > >>>> > >>>> Turner, Sean P. schrieb: > >>>>> This would work for me. > >>>>> > >>>>> spt > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] > >>>>>> Sent: Wednesday, December 05, 2007 8:02 AM > >>>>>> To: Turner, Sean P. > >>>>>> Cc: ietf-ltans@imc.org > >>>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>>>>> > >>>>>> The problem with your suggested syntax is the definition of the our > >>>>>> constraints. If we used the RFC3280 AlgorithmIdentifier > >>>> structure, we > >>>>>> would integrate the constraints as follows: > >>>>>> > >>>>>> AlgorithmValidityInfo ::= SEQUENCE { > >>>>>> identifier AlgorithmIdentifier, > >>>>>> constraint CHOICE { > >>>>>> exact [0] OCTET STRING, > >>>>>> min [1] OCTET STRING, > >>>>>> max [2] OCTET STRING, > >>>>>> range [3] Range, > >>>>>> other [4] OtherConstraints > >>>>>> validity Validity OPTIONAL, > >>>>>> information Information OPTIONAL } > >>>>>> > >>>>>> It's not possible to determine constraints for more than one > parameter > >>>>>> (e.g. p > 1024 and q > 160 in case of DSA). > >>>>>> Additionally defining ranges is impossible (e.g. modulus < > >>>>>> 2048 and modulus > 1024). > >>>>>> > >>>>>> > >>>>>> so & tk > >>>>>> > >>>>>> > >>>>>> Turner, Sean P. schrieb: > >>>>>>> I'm only commenting on the Parameter structure in the > >>>> ASN.1. I think > >>>>>>> that it might be better to change Algorithm to be a sequence of > >>>>>>> algorithmIdentifier, validity, and information - call it > >>>>>>> AlgorithmValidityInfo. I suggest this for two reasons: > >>>>>>> > >>>>>>> 1. The AlgorithmIdentifier structure that is used to assign an > >>>>>>> algorithm's object identifier also define the parameters. So it > >>>>>>> probably makes sense to reuse this structure. > >>>>>>> > >>>>>>> 2. The parameters structures for some of the newer > >>>>>> algorithms is quite > >>>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs > >>>>>> [RFC3279] > >>>>>>> aren't just an OID they are nested structure. > >>>>>>> > >>>>>>> (not sure how to do it in XML) > >>>>>>> > >>>>>>> Replace: > >>>>>>> > >>>>>>> Algorithm ::= SEQUENCE { > >>>>>>> algorithmIdentifier AlgID, > >>>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, > >>>>>>> validity [1] Validity, > >>>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL > >>>>>>> } > >>>>>>> > >>>>>>> AlgID ::= SEQUENCE { > >>>>>>> name UTF8String, > >>>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > >>>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL > >>>>>>> } > >>>>>>> > >>>>>>> Parameter ::= SEQUENCE { > >>>>>>> name UTF8String, > >>>>>>> constraint CHOICE { > >>>>>>> exact [0] OCTET STRING, > >>>>>>> min [1] OCTET STRING, > >>>>>>> max [2] OCTET STRING, > >>>>>>> range [3] Range, > >>>>>>> other [4] OtherConstraints > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> With: > >>>>>>> > >>>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier > >>>>>>> AlgorithmIdentifier, > >>>>>>> validity Validity OPTIONAL, > >>>>>>> information Information OPTIONAL } > >>>>>>> > >>>>>>> Validity ::= SEQUENCE { > >>>>>>> start [0] GeneralizedTime OPTIONAL, > >>>>>>> end [1] GeneralizedTime OPTIONAL } > >>>>>>> > >>>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > >>>>>>> > >>>>>>> -- From RFC3280 > >>>>>>> AlgorithmIdentifier ::= SEQUENCE { > >>>>>>> algorithm OBJECT IDENTIFIER, > >>>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } > >>>>>>> -- contains a value of the type > >>>>>>> -- registered for use with the > >>>>>>> -- algorithm object > >>>> identifier value > >>>>>>> spt > >>>>>>> > >>>>>>> > >>>>> > >>> > >>> > >> > > From owner-ietf-ltans@mail.imc.org Mon Dec 10 13:44:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1ncO-0001XZ-UO for ltans-archive-ba2WohFa@lists.ietf.org; Mon, 10 Dec 2007 13:44:40 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1ncN-00006M-Kd for ltans-archive-ba2WohFa@lists.ietf.org; Mon, 10 Dec 2007 13:44:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIW51Y028976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 11:32:05 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBAIW5W1028975; Mon, 10 Dec 2007 11:32:05 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIW1UD028967 for ; Mon, 10 Dec 2007 11:32:04 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lBAIVvuc004841; Mon, 10 Dec 2007 19:31:57 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg03.opentext.net [149.235.128.137]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lBAIVt7r021311; Mon, 10 Dec 2007 13:31:56 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_004E_01C83B63.50B41780"; micalg=SHA1 Date: Mon, 10 Dec 2007 19:31:54 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78680201D242@MUCXGC2.opentext.net> In-reply-to: <4759615B.3000508@sit.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment on draft-ietf-ltans-dssc-01.txt Thread-Index: Acg45PITvIVohAirQSWky3QdKuEu9ACdcNzQ X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Thomas Kunz" , "Turner, Sean P." Cc: X-Archived: msg.Bf3Kebj:2007-12-10:mucpm02.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: efb5d987e2484f3d9a304cc31a003441 This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C83B63.50B41780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hm, I agree with Thomas. Intuitively I feel that a flat structure of parameters will always be sufficient to describe a used algorithm. Simply because every authority publishing such info will most probably always publish this in algorithm name and a simple (1..n) list of its acceptable parameters. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Thomas Kunz > Sent: Friday, December 07, 2007 4:06 PM > To: Turner, Sean P. > Cc: ietf-ltans@imc.org > Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > We think, our flat sequence is sufficient. > > The goal of a policy is to specify a range for specific > (safety-critical) parameters of an algorithm. Therefor it's not > necessary to define all parameters. > > In the evaluations of BSI and NIST > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms > only one value is defined (namely q). By NIST a q_length of 160 is > suitable until 2010. > > In this case, the XML structure would be: > > > > EC-DSA 160 > ... > > 160 > 2010-12-31 > > > > so & tk > > > > > > Turner, Sean P. schrieb: > > Yes I did misunderstand. With algorithms like DSA where there are few > > parameters your structure might work but for EC algorithms (I attached > some > > of the ASN.1 for their parameters) I don't think the flat sequence of > will > > work. > > > > ECParameters ::= CHOICE { > > namedCurve CURVE.&id({NamedCurve}), > > specifiedCuve SpecifiedCurve, > > implicitCurve NULL > > } > > > > CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } > > WITH SYNTAX { ID &id } > > > > NamedCurve CURVE ::= { > > { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | > > { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | > > { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | > > { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | > > { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | > > ... -- Extensible > > } > > > > SpecifiedCurve ::= SEQUENCE { > > version SpecifiedCurveVersion > > ( ecpVer1 | ecpVer2 | ecpVer3 ), > > fieldID FieldID {{FieldTypes}}, > > curve Curve, -- Curve E > > base ECPoint, -- Base point P > > order INTEGER, -- Order n of the base point > > cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n > > hash HashAlgorithm OPTIONAL, > > ... -- Extensible > > } > > > > SpecifiedCurveVersion ::= INTEGER { > > ecpVer1(1), > > ecpVer2(2), > > ecpVer3(3), > > ... -- Extensible > > } > > FIELD-ID ::= TYPE-IDENTIFIER > > > > FieldID { FIELD-ID:IOSet } ::= SEQUENCE { > > fieldType FIELD-ID.&id({IOSet}), > > parameters FIELD-ID.&Type({IOSet}{@fieldType}) > > } > > > > FieldTypes FIELD-ID ::= { > > { Prime-p IDENTIFIED BY prime-field } | > > { Characteristic-two IDENTIFIED BY characteristic-two-field } | > > ... -- Extensible > > } > > > > prime-field OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } > > > > Prime-p ::= INTEGER > > > > characteristic-two-field OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } > > > > Characteristic-two ::= SEQUENCE { > > m INTEGER, -- Field size 2^m > > basis CHARACTERISTIC-TWO.&id({BasisTypes}), > > parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) > > } > > > > CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER > > > > BasisTypes CHARACTERISTIC-TWO ::= { > > { NULL IDENTIFIED BY gnBasis } | > > { Trinomial IDENTIFIED BY tpBasis } | > > { Pentanomial IDENTIFIED BY ppBasis } | > > ... -- Extensible > > } > > > > gnBasis OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > > characteristic-two-basis(2) 1 } > > > > tpBasis OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > > characteristic-two-basis(2) 2 } > > > > Trinomial ::= INTEGER > > > > ppBasis OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > > characteristic-two-basis(2) 3 } > > > > Pentanomial ::= SEQUENCE { > > k1 INTEGER, -- k1 > 0 > > k2 INTEGER, -- k2 > k1 > > k3 INTEGER -- k3 > k2 > > } > > > > Curve ::= SEQUENCE { > > a FieldElement, > > b FieldElement, > > seed BIT STRING OPTIONAL > > -- Shall be present if used in SpecifiedCurve > > -- with version of ecdpVer2 or ecdpVer3 > > } > > FieldElement ::= OCTET STRING > > > > ECPoint ::= OCTET STRING > > > >> -----Original Message----- > >> From: owner-ietf-ltans@mail.imc.org > >> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > >> Sent: Thursday, December 06, 2007 4:52 AM > >> To: Turner, Sean P. > >> Cc: ietf-ltans@imc.org > >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >> > >> We think, You misunderstood our last post. > >> With the mentioned structure (AlgorithmValidityInfo) we wanted > >> to show that we CANNOT use the AlgorithmIdentifier. > >> > >> The reason is, we cannot model the following cases: > >> 1. constraints for more than one parameter (e.g. p > 1024 and > >> q > 160 in case of DSA). > >> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) > >> > >> The main problem is that AlgorithmIdentifier describes > >> entirely one algorithm with all its parameters. Therefor it is > >> not possible to set different constraints for the parameters. > >> > >> so & tk > >> > >> > >> > >> Turner, Sean P. schrieb: > >>> This would work for me. > >>> > >>> spt > >>> > >>>> -----Original Message----- > >>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] > >>>> Sent: Wednesday, December 05, 2007 8:02 AM > >>>> To: Turner, Sean P. > >>>> Cc: ietf-ltans@imc.org > >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>>> > >>>> The problem with your suggested syntax is the definition of the our > >>>> constraints. If we used the RFC3280 AlgorithmIdentifier > >> structure, we > >>>> would integrate the constraints as follows: > >>>> > >>>> AlgorithmValidityInfo ::= SEQUENCE { > >>>> identifier AlgorithmIdentifier, > >>>> constraint CHOICE { > >>>> exact [0] OCTET STRING, > >>>> min [1] OCTET STRING, > >>>> max [2] OCTET STRING, > >>>> range [3] Range, > >>>> other [4] OtherConstraints > >>>> validity Validity OPTIONAL, > >>>> information Information OPTIONAL } > >>>> > >>>> It's not possible to determine constraints for more than one > >>>> parameter (e.g. p > 1024 and q > 160 in case of DSA). > >>>> Additionally defining ranges is impossible (e.g. modulus < > >>>> 2048 and modulus > 1024). > >>>> > >>>> > >>>> so & tk > >>>> > >>>> > >>>> Turner, Sean P. schrieb: > >>>>> I'm only commenting on the Parameter structure in the > >> ASN.1. I think > >>>>> that it might be better to change Algorithm to be a sequence of > >>>>> algorithmIdentifier, validity, and information - call it > >>>>> AlgorithmValidityInfo. I suggest this for two reasons: > >>>>> > >>>>> 1. The AlgorithmIdentifier structure that is used to assign an > >>>>> algorithm's object identifier also define the parameters. So it > >>>>> probably makes sense to reuse this structure. > >>>>> > >>>>> 2. The parameters structures for some of the newer > >>>> algorithms is quite > >>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs > >>>> [RFC3279] > >>>>> aren't just an OID they are nested structure. > >>>>> > >>>>> (not sure how to do it in XML) > >>>>> > >>>>> Replace: > >>>>> > >>>>> Algorithm ::= SEQUENCE { > >>>>> algorithmIdentifier AlgID, > >>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, > >>>>> validity [1] Validity, > >>>>> information [2] SEQUENCE OF UTF8String OPTIONAL > >>>>> } > >>>>> > >>>>> AlgID ::= SEQUENCE { > >>>>> name UTF8String, > >>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > >>>>> uri [1] SEQUENCE OF IA5String OPTIONAL > >>>>> } > >>>>> > >>>>> Parameter ::= SEQUENCE { > >>>>> name UTF8String, > >>>>> constraint CHOICE { > >>>>> exact [0] OCTET STRING, > >>>>> min [1] OCTET STRING, > >>>>> max [2] OCTET STRING, > >>>>> range [3] Range, > >>>>> other [4] OtherConstraints > >>>>> } > >>>>> } > >>>>> > >>>>> With: > >>>>> > >>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier > >>>>> AlgorithmIdentifier, > >>>>> validity Validity OPTIONAL, > >>>>> information Information OPTIONAL } > >>>>> > >>>>> Validity ::= SEQUENCE { > >>>>> start [0] GeneralizedTime OPTIONAL, > >>>>> end [1] GeneralizedTime OPTIONAL } > >>>>> > >>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > >>>>> > >>>>> -- From RFC3280 > >>>>> AlgorithmIdentifier ::= SEQUENCE { > >>>>> algorithm OBJECT IDENTIFIER, > >>>>> parameters ANY DEFINED BY algorithm OPTIONAL } > >>>>> -- contains a value of the type > >>>>> -- registered for use with the > >>>>> -- algorithm object > >> identifier value > >>>>> spt > >>>>> > >>>>> > >>> > > > > ------=_NextPart_000_004E_01C83B63.50B41780 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5 MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3 /OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby /xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9 BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd 6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4 WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2 QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7 H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj 7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2 l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3 Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2 YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0 eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzEyMTAxODMxNTJaMCMGCSqGSIb3DQEJBDEWBBTlnjovdahYxMDxC60L29jt3z9p bTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICAG07yM9s+YdrhUUnqtVezgWIXLw7m/66gbTJ/XrbrxuGK7ImbAVgSWfJ5fy6 B/V03ex7kQNLR0GTzSIfJn8JdP6kgBv2Ax8/+SpKYcWSHqmRhz2a1uaPd6EDEYodu7+W8w8TEOl6 /4fRRBDG4rmyXMGcIbgFEs3NsBi9EH0/A4uOu7MbH6wWYO+QWVNJ2ElnjpImZ3hT4ymvklEYLFbL pYo/dJH6FurYD7ZnAO840FDR4MkPjyYVL+zBnFupQQoBWLpr1+kpLHa348EVdsh2ZxIgphtGrZIz 1k5B0v0yRL2WKRHczYw61tKhxaz/YrcSvH3ya9p8SaNr0GE1Az4NBTNZ/fFCcwaP+BsTZvKHZen1 p86QFJWVxOPo6QzNKD9Zknu6yOlReE3g11/TeRI4qCVQlVkimGeSq1io6ufzyB2R2QENfzEu1lG5 rfrIqdFo1OPOonRGRwP4wTP8benZtifVubb7uxO/H7ioIJBkNiznnHiHmjDeI25nlop8YI/gCPBR JkcCD3zChLmcsYvl1dIKGIb/9vzgPOpVaCwZ/n0td/wcrGP/wKane9EhTviRsfsfAVaMjTXSkzi/ wIdeC+BUjrjqCPcIQqIzmKExcZcRXEIUC1hb55LQ4L7Y6Ta1ojHVJetgiGMaLjMKm3Yg/zm1LGqE pxQXZNF1KlObCDD+AAAAAAAA ------=_NextPart_000_004E_01C83B63.50B41780-- From owner-ietf-ltans@mail.imc.org Mon Dec 10 15:45:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pV6-0006Re-Ut for ltans-archive-ba2WohFa@lists.ietf.org; Mon, 10 Dec 2007 15:45:16 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1pV4-0003jH-UG for ltans-archive-ba2WohFa@lists.ietf.org; Mon, 10 Dec 2007 15:45:16 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAKXMxs041795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 13:33:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBAKXMvW041794; Mon, 10 Dec 2007 13:33:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAKXKfb041786 for ; Mon, 10 Dec 2007 13:33:21 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rqkTG1BBUrXiYh4kefXbhJ/kPhRz5MKErp1g8R4yzZRgGyCzuFU5MZlWeoUbg4uR; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J1pJY-00076a-0g; Mon, 10 Dec 2007 15:33:20 -0500 Message-ID: <006001c83b6b$f4e9c680$174f7d40@home.glassey.com> From: "todd glassey" To: "Tobias Gondrom" , Cc: References: <2666EB2A846BAC4BB2D7F593301A78680201D243@MUCXGC2.opentext.net> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Date: Mon, 10 Dec 2007 11:05:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c30e03c803e84e38dec21b90eda9bb54350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Tobias - I will answer this when I get home tonight. I am only in the office for a little bit today (I have a cold) and need to pull a couple of cat-5 lines from our new Time Servers into the lab. Todd ----- Original Message ----- From: "Tobias Gondrom" To: ; "TS Glassey" Cc: Sent: Monday, December 10, 2007 10:32 AM Subject: RE: comment on draft-ietf-ltans-dssc-01.txt > > Hi all, > > hm actually I do not understand the argument or miss the point. > Could you please explain a bit more why your argument mandates against a > flat or for a non-flat structure of the DSSC format? > > Thanks, Tobias > > > >> -----Original Message----- >> From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] >> On Behalf Of jwkckid1@ix.netcom.com >> Sent: Sunday, December 09, 2007 12:32 AM >> To: TS Glassey >> Cc: ietf-ltans@imc.org >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >> >> Todd and all, >> >> I believe Todd has a very good and valid point here. >> A flat sequence seems very much less than sufficient. >> >> Regards, >> >> Jeffrey A. Williams >> Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) >> "Obedience of the law is the greatest freedom" - >> Abraham Lincoln >> >> "Credit should go with the performance of duty and not with what is > very >> often the accident of glory" - Theodore Roosevelt >> >> "If the probability be called P; the injury, L; and the burden, B; >> liability >> depends upon whether B is less than L multiplied by >> P: i.e., whether B is less than PL." >> United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] >> =============================================================== >> Updated 1/26/04 >> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. >> of >> Information Network Eng. INEG. INC. >> ABA member in good standing member ID 01257402 E-Mail >> jwkckid1@ix.netcom.com >> Phone: 214-244-4827 >> >> >> -----Original Message----- >> >From: TS Glassey >> >Sent: Dec 8, 2007 9:43 AM >> >To: Thomas Kunz , "Turner, Sean P." >> >> >Cc: ietf-ltans@imc.org >> >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> > >> > >> >Maybe not from a control perspective but that is only half of the >> picture. >> >The key value of LTANS as a 'thing' is that is would need to meet > both >> the >> >legal and emerging document management processes or else those > parties >> who >> >are constrained by those frameworks will not be able to use it, nor > will >> >those parties attached to the people so constrained. >> > >> >Todd Glassey >> > >> >----- Original Message ----- >> >From: "Thomas Kunz" >> >To: "Turner, Sean P." >> >Cc: >> >Sent: Friday, December 07, 2007 7:06 AM >> >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> > >> > >> >> We think, our flat sequence is sufficient. >> >> >> >> The goal of a policy is to specify a range for specific (safety- >> critical) >> >> parameters of an algorithm. Therefor it's not necessary to define > all >> >> parameters. >> >> >> >> In the evaluations of BSI and NIST >> >> (e.g.: http://www.keylength.com/en/4/) for elliptic curve > algorithms >> only >> >> one value is defined (namely q). By NIST a q_length of 160 is > suitable >> >> until 2010. >> >> >> >> In this case, the XML structure would be: >> >> >> >> >> >> >> >> EC-DSA 160 >> >> ... >> >> >> >> 160 >> >> 2010-12-31 >> >> >> >> >> >> >> >> so & tk >> >> >> >> >> >> >> >> >> >> >> >> Turner, Sean P. schrieb: >> >>> Yes I did misunderstand. With algorithms like DSA where there are > few >> >>> parameters your structure might work but for EC algorithms (I > attached >> >>> some >> >>> of the ASN.1 for their parameters) I don't think the flat sequence > of >> >>> will >> >>> work. >> >>> >> >>> ECParameters ::= CHOICE { >> >>> namedCurve CURVE.&id({NamedCurve}), >> >>> specifiedCuve SpecifiedCurve, >> >>> implicitCurve NULL >> >>> } >> >>> >> >>> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >> >>> WITH SYNTAX { ID &id } >> >>> >> >>> NamedCurve CURVE ::= { >> >>> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >> >>> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >> >>> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >> >>> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >> >>> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >> >>> ... -- Extensible >> >>> } >> >>> >> >>> SpecifiedCurve ::= SEQUENCE { >> >>> version SpecifiedCurveVersion >> >>> ( ecpVer1 | ecpVer2 | ecpVer3 ), >> >>> fieldID FieldID {{FieldTypes}}, >> >>> curve Curve, -- Curve E >> >>> base ECPoint, -- Base point P >> >>> order INTEGER, -- Order n of the base point >> >>> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >> >>> hash HashAlgorithm OPTIONAL, >> >>> ... -- Extensible >> >>> } >> >>> >> >>> SpecifiedCurveVersion ::= INTEGER { >> >>> ecpVer1(1), >> >>> ecpVer2(2), >> >>> ecpVer3(3), >> >>> ... -- Extensible >> >>> } >> >>> FIELD-ID ::= TYPE-IDENTIFIER >> >>> >> >>> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >> >>> FIELD-ID.&id({IOSet}), >> >>> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >> >>> } >> >>> >> >>> FieldTypes FIELD-ID ::= { >> >>> { Prime-p IDENTIFIED BY prime-field } | >> >>> { Characteristic-two IDENTIFIED BY characteristic-two-field } > | >> >>> ... -- Extensible >> >>> } >> >>> >> >>> prime-field OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 > } >> >>> >> >>> Prime-p ::= INTEGER >> >>> >> >>> characteristic-two-field OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 > } >> >>> >> >>> Characteristic-two ::= SEQUENCE { >> >>> m INTEGER, -- Field size 2^m >> >>> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >> >>> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >> >>> } >> >>> >> >>> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >> >>> >> >>> BasisTypes CHARACTERISTIC-TWO ::= { >> >>> { NULL IDENTIFIED BY gnBasis } | >> >>> { Trinomial IDENTIFIED BY tpBasis } | >> >>> { Pentanomial IDENTIFIED BY ppBasis } | >> >>> ... -- Extensible >> >>> } >> >>> >> >>> gnBasis OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >>> characteristic-two-basis(2) 1 } >> >>> >> >>> tpBasis OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >>> characteristic-two-basis(2) 2 } >> >>> >> >>> Trinomial ::= INTEGER >> >>> >> >>> ppBasis OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >>> characteristic-two-basis(2) 3 } >> >>> >> >>> Pentanomial ::= SEQUENCE { >> >>> k1 INTEGER, -- k1 > 0 >> >>> k2 INTEGER, -- k2 > k1 >> >>> k3 INTEGER -- k3 > k2 >> >>> } >> >>> >> >>> Curve ::= SEQUENCE { >> >>> a FieldElement, >> >>> b FieldElement, >> >>> seed BIT STRING OPTIONAL >> >>> -- Shall be present if used in SpecifiedCurve >> >>> -- with version of ecdpVer2 or ecdpVer3 >> >>> } >> >>> FieldElement ::= OCTET STRING >> >>> >> >>> ECPoint ::= OCTET STRING >> >>>> -----Original Message----- >> >>>> From: owner-ietf-ltans@mail.imc.org >> >>>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >> >>>> Sent: Thursday, December 06, 2007 4:52 AM >> >>>> To: Turner, Sean P. >> >>>> Cc: ietf-ltans@imc.org >> >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >>>> >> >>>> We think, You misunderstood our last post. >> >>>> With the mentioned structure (AlgorithmValidityInfo) we wanted to >> show >> >>>> that we CANNOT use the AlgorithmIdentifier. >> >>>> >> >>>> The reason is, we cannot model the following cases: >> >>>> 1. constraints for more than one parameter (e.g. p > 1024 and q > > 160 >> in >> >>>> case of DSA). >> >>>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >> >>>> >> >>>> The main problem is that AlgorithmIdentifier describes entirely > one >> >>>> algorithm with all its parameters. Therefor it is not possible to > set >> >>>> different constraints for the parameters. >> >>>> >> >>>> so & tk >> >>>> >> >>>> >> >>>> >> >>>> Turner, Sean P. schrieb: >> >>>>> This would work for me. >> >>>>> >> >>>>> spt >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >> >>>>>> Sent: Wednesday, December 05, 2007 8:02 AM >> >>>>>> To: Turner, Sean P. >> >>>>>> Cc: ietf-ltans@imc.org >> >>>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >>>>>> >> >>>>>> The problem with your suggested syntax is the definition of the > our >> >>>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >> >>>> structure, we >> >>>>>> would integrate the constraints as follows: >> >>>>>> >> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { >> >>>>>> identifier AlgorithmIdentifier, >> >>>>>> constraint CHOICE { >> >>>>>> exact [0] OCTET STRING, >> >>>>>> min [1] OCTET STRING, >> >>>>>> max [2] OCTET STRING, >> >>>>>> range [3] Range, >> >>>>>> other [4] OtherConstraints >> >>>>>> validity Validity OPTIONAL, >> >>>>>> information Information OPTIONAL } >> >>>>>> >> >>>>>> It's not possible to determine constraints for more than one >> parameter >> >>>>>> (e.g. p > 1024 and q > 160 in case of DSA). >> >>>>>> Additionally defining ranges is impossible (e.g. modulus < >> >>>>>> 2048 and modulus > 1024). >> >>>>>> >> >>>>>> >> >>>>>> so & tk >> >>>>>> >> >>>>>> >> >>>>>> Turner, Sean P. schrieb: >> >>>>>>> I'm only commenting on the Parameter structure in the >> >>>> ASN.1. I think >> >>>>>>> that it might be better to change Algorithm to be a sequence > of >> >>>>>>> algorithmIdentifier, validity, and information - call it >> >>>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >> >>>>>>> >> >>>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >> >>>>>>> algorithm's object identifier also define the parameters. So > it >> >>>>>>> probably makes sense to reuse this structure. >> >>>>>>> >> >>>>>>> 2. The parameters structures for some of the newer >> >>>>>> algorithms is quite >> >>>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >> >>>>>> [RFC3279] >> >>>>>>> aren't just an OID they are nested structure. >> >>>>>>> >> >>>>>>> (not sure how to do it in XML) >> >>>>>>> >> >>>>>>> Replace: >> >>>>>>> >> >>>>>>> Algorithm ::= SEQUENCE { >> >>>>>>> algorithmIdentifier AlgID, >> >>>>>>> parameters [0] SEQUENCE OF Parameter > OPTIONAL, >> >>>>>>> validity [1] Validity, >> >>>>>>> information [2] SEQUENCE OF UTF8String > OPTIONAL >> >>>>>>> } >> >>>>>>> >> >>>>>>> AlgID ::= SEQUENCE { >> >>>>>>> name UTF8String, >> >>>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >> >>>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >> >>>>>>> } >> >>>>>>> >> >>>>>>> Parameter ::= SEQUENCE { >> >>>>>>> name UTF8String, >> >>>>>>> constraint CHOICE { >> >>>>>>> exact [0] OCTET STRING, >> >>>>>>> min [1] OCTET STRING, >> >>>>>>> max [2] OCTET STRING, >> >>>>>>> range [3] Range, >> >>>>>>> other [4] OtherConstraints >> >>>>>>> } >> >>>>>>> } >> >>>>>>> >> >>>>>>> With: >> >>>>>>> >> >>>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >> >>>>>>> AlgorithmIdentifier, >> >>>>>>> validity Validity OPTIONAL, >> >>>>>>> information Information OPTIONAL } >> >>>>>>> >> >>>>>>> Validity ::= SEQUENCE { >> >>>>>>> start [0] GeneralizedTime OPTIONAL, >> >>>>>>> end [1] GeneralizedTime OPTIONAL } >> >>>>>>> >> >>>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >> >>>>>>> >> >>>>>>> -- From RFC3280 >> >>>>>>> AlgorithmIdentifier ::= SEQUENCE { >> >>>>>>> algorithm OBJECT IDENTIFIER, >> >>>>>>> parameters ANY DEFINED BY algorithm OPTIONAL > } >> >>>>>>> -- contains a value of the > type >> >>>>>>> -- registered for use with the >> >>>>>>> -- algorithm object >> >>>> identifier value >> >>>>>>> spt >> >>>>>>> >> >>>>>>> >> >>>>> >> >>> >> >>> >> >> >> > > > From owner-ietf-ltans@mail.imc.org Wed Dec 26 19:46:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7gtQ-0002Kw-2q for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 26 Dec 2007 19:46:36 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7gtP-0004Tk-FM for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 26 Dec 2007 19:46:36 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR0VMuA034301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Dec 2007 17:31:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBR0VM52034300; Wed, 26 Dec 2007 17:31:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR0VJak034290 for ; Wed, 26 Dec 2007 17:31:19 -0700 (MST) (envelope-from jesusmmp@gmail.com) Received: by wa-out-1112.google.com with SMTP id l24so4622554waf.22 for ; Wed, 26 Dec 2007 16:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=zNYiJz5DoHRYz46j/LKtPgIyQd4Rm01N1xccMXw1kIk=; b=T+9diOJBzYf9Qlge9S9OnxudWFFMKvdbrhCdORYhq6NgQWIziZnTW5EpuBOyidXET9cQ71Lj9R0cnYtYosb2LCM25G5nCzRHJ1WgfzcHvQY60NgUDs6yc1sEkOC5YfFJaH9a2HTb4fADMpEDU40bM9LlLcxYVTk4yN8kiUudiuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=n19HqOcJdi0RNMGuke9WSV70S9G4T9yg1ReBI7DV+arGHQvwzSHQ1YiLVisbOzQ7fOyEgPqR9xAn0jJopGpHpzdnGfC/n+GYHN6kOstT+Cs11aTVJ0R/WLec8UFd5j1nTSHML9rWSGaWp2nWrDJGM2h0rxqS7SAZ7oxeCIWcGSc= Received: by 10.115.60.1 with SMTP id n1mr7045318wak.37.1198715479006; Wed, 26 Dec 2007 16:31:19 -0800 (PST) Received: by 10.114.156.10 with HTTP; Wed, 26 Dec 2007 16:31:18 -0800 (PST) Message-ID: Date: Thu, 27 Dec 2007 01:31:18 +0100 From: "Jesus Maria Mendez Perez" To: "Tobias Gondrom" Subject: Re: ERS - using hash tree? Cc: ietf-ltans@imc.org In-Reply-To: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15263_32524534.1198715479000" References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d ------=_Part_15263_32524534.1198715479000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Tobias, I=B4m Jesus. I have some questions and I hope you can help me. First, about what happen with the gap of time that pass while you send a data object and finally at the evening the ERS-system build the hastree for all documents that were archived during that day?. For example, if you send a data object at 3:00 pm and the ERS-system build the hashtree at 8:00 pm... you have 5 hours during which that data object could lose its integrity. What can we do in this situation? Could be the solution to timestamp every data object separately and inmediately after they are sent by the client and when the ERS-system have to build the hashtree, the hash-tree will built with all these data objects and its timestamps? And now about the ARCHIVE operation. In the LTAP Protocol draft is said LTA= P Protocol is asynchronous by nature. And my question is about then second response (service response). Will a client receive the second response when the TAS hast just received the data object or when the archive operation ha= s just finished (the hashtree has been built)? If the ARCHIVE operation is asynchronous we really need another operation t= o permit a client to check if the full archive operation has finished... Finally about the information called "Complementary data" in the article "Long-term trusted preservation service using service interaction protocol and evidence records", does it include only timestamping certificates?, or does it include timestamps' certificates and user signer=B4s certificates?. Are they obtain by SCVP and save up as complementary data in the archive operation? Thanks and Happy Christmas ------=_Part_15263_32524534.1198715479000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Tobias, I=B4m Jesus.

I have some questions and I hope you can = help me.

First, about what happen with the gap of time that pass whi= le you send a data object and finally at the evening the ERS-system build the hastree for all documents that were archived during that day?. For exam= ple, if you send a data object at 3:00 pm and the ERS-system build the hash= tree at 8:00 pm... you have 5 hours during which that data object could los= e its integrity. What can we do in this situation?
Could be the solution to timestamp every data object separately and inm= ediately after they are sent by the client and when the ERS-system have to = build the hashtree, the hash-tree will built with all these data objects an= d its timestamps?=20

And now about the ARCHIVE operation. In the LTAP Protocol draft is = said LTAP Protocol is asynchronous by nature. And my question is about then= second response (service response). Will a client receive the second respo= nse when the TAS hast just received the data object or when the archive ope= ration has just finished (the hashtree has been built)?
If the ARCHIVE operation is asynchronous we really need another operati= on to permit a client to check if the full archive operation has finished..= .

Finally about the information called "Complementary data"= ; in the article "Long-term trusted preservation service using service= interaction protocol and evidence records", does it include only time= stamping certificates?, or does it include timestamps' certificates
and user signer=B4s certificates?. Are they obtain by SCVP and save up = as complementary data in the archive operation?

Thanks and Happy Ch= ristmas

------=_Part_15263_32524534.1198715479000-- From owner-ietf-ltans@mail.imc.org Wed Dec 26 20:10:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7hGV-0002FP-Kt for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 26 Dec 2007 20:10:27 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7hGU-0004qi-M1 for ltans-archive-ba2WohFa@lists.ietf.org; Wed, 26 Dec 2007 20:10:27 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR0tiWb036130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Dec 2007 17:55:44 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBR0tixT036129; Wed, 26 Dec 2007 17:55:44 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR0thGN036123 for ; Wed, 26 Dec 2007 17:55:43 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VRs4wAu8SLV7mS7D8trKybEdcEO5eIlNSqyJ+nufuD6YPSFeUEGGYlGOdG+1ACuu; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J7h2D-0005gD-G4; Wed, 26 Dec 2007 19:55:41 -0500 Message-ID: <054301c84823$352520a0$174f7d40@home.glassey.com> From: "todd glassey" To: "Jesus Maria Mendez Perez" , "Tobias Gondrom" Cc: References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> Subject: Re: ERS - using hash tree? Date: Wed, 26 Dec 2007 16:55:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_053E_01C847E0.1B1AD990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7944523faf0440546160d0079b48ded95d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 This is a multi-part message in MIME format. ------=_NextPart_000_053E_01C847E0.1B1AD990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Merry Christmas All - Jesus - the phrase you are looking for is the concept of "Data = Spoliation" and its something that offends System's Admins everywhere = because it means we want proof from their systems which is stronger than = their word. That said - if LTANS wants to be used in the world it needs to meet = Legal Control Requirements on Digital Content and if it doesn't it = doesn't matter what we do technology wise if that is not done, since the = records controlled in the LTANS system will not be admissible in a court = of law without extreme cost and extra hearings to authenticate that data = properly... The problem here I think is that this WG doesn't want to hear that. It = also doesn't seem to want to embrace that the Court's are a lot smarter = than they used to be. One of my partner's is actually fighting a data = spoliation case in the Federal Court's in NY so I know this stuff is a = key issue.=20 As to your commentary - Those five hours of data are spoiled and well - = that makes this a real issue I think. Todd=20 ----- Original Message -----=20 From: Jesus Maria Mendez Perez=20 To: Tobias Gondrom=20 Cc: ietf-ltans@imc.org=20 Sent: Wednesday, December 26, 2007 4:31 PM Subject: Re: ERS - using hash tree? Hello Tobias, I=B4m Jesus. I have some questions and I hope you can help me. First, about what happen with the gap of time that pass while you send = a data object and finally at the evening the ERS-system build the hastree for all documents that were archived during that day?. For = example, if you send a data object at 3:00 pm and the ERS-system build = the hashtree at 8:00 pm... you have 5 hours during which that data = object could lose its integrity. What can we do in this situation?=20 Could be the solution to timestamp every data object separately and = inmediately after they are sent by the client and when the ERS-system = have to build the hashtree, the hash-tree will built with all these data = objects and its timestamps?=20 And now about the ARCHIVE operation. In the LTAP Protocol draft is = said LTAP Protocol is asynchronous by nature. And my question is about = then second response (service response). Will a client receive the = second response when the TAS hast just received the data object or when = the archive operation has just finished (the hashtree has been built)?=20 If the ARCHIVE operation is asynchronous we really need another = operation to permit a client to check if the full archive operation has = finished... Finally about the information called "Complementary data" in the = article "Long-term trusted preservation service using service = interaction protocol and evidence records", does it include only = timestamping certificates?, or does it include timestamps' certificates=20 and user signer=B4s certificates?. Are they obtain by SCVP and save up = as complementary data in the archive operation?=20 Thanks and Happy Christmas ------=_NextPart_000_053E_01C847E0.1B1AD990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Merry Christmas All = -
 
Jesus  - the phrase = you are=20 looking for is the concept of "Data Spoliation" and its something that = offends=20 System's Admins everywhere because it means we want proof from their = systems=20 which is stronger than their word.
 
That said - if LTANS wants = to be used=20 in the world it needs to meet Legal Control Requirements on Digital = Content and=20 if it doesn't it doesn't matter what we do technology wise if that is = not done,=20 since the records controlled in the LTANS system will not be admissible = in a=20 court of law without extreme cost and extra hearings to authenticate = that data=20 properly...
 
----- Original Message -----
From:=20 Tobias=20 Gondrom
Sent: Wednesday, December 05, = 2007 1:56=20 PM
Subject: closing of WG LC for = ERS/SCVP=20 next week on Dec-11

Hello=20 all,

just a = last=20 reminder: I = initiated WG LC on ERS/SCVP (draft-ietf-ltans-ers-scvp) several weeks ago. =

Carl = included the=20 feedback he received during LC (mostly editorial changes = and one minor=20 change of bit-on-the-wire)) in the revisions 04 and 05.=20

As = discussed yesterday=20 at the meeting, I feel the draft is in good = shape=20 and=20 will close WG LC for this document next = week (Dec-11)=20 and proceed it to = AD/IESG review = and IETF LC. So if you have any last = comments or=20 discusses for the ERS/SCVP, please submit them until this=20 deadline.

. =

Greetings,=20 Tobias


__________________________________________=
Tobias Gondrom
Head of Open = Text Security=20 Team
Director, Product Security

Open Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630=20 Grasbrunn

Phone:=20 +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 = (0) 89=20 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/ =20

Place = of Incorporation=20 / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, = 85630=20 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 = 1199 |=20 Register Court / Registergericht: M=FCnchen, Germany | Trade Register = Number /=20 HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing = Director /=20 Gesch=E4ftsf=FChrer: John Shackleton, Walter = K=F6hler

This = email is protected=20 by domestic and international copyright laws and treaties and is the = property=20 of Open Text Corporation, it may contain confidential and/or trade = secret=20 information of the Open Text Corporation and/or its subsidiaries = (OTC), and=20 may be subject to legal privilege in favor of OTC. This email may only = be=20 lawfully received, accessed, displayed on a computer screen, printed, = copied,=20 and/or used by the specific addressee(s) named above ("Authorized = Recipient")=20 for the purpose for which it was sent by OTC. All other rights and = licenses to=20 this email are fully reserved to OTC. If you are not an Authorized = Recipient,=20 you are required to immediately delete this email in its entirety = without=20 printing, copying, using, and/or re-transmitting this email, either in = whole=20 or in part. The transmission of this email by OTC is not to be = construed as a=20 waiver by OTC and/or the individual sending this email on behalf of = OTC of any=20 of their respective rights or privileges at law or otherwise, = howsoever=20 arising.

As to your commentary - = Those five=20 hours of data are spoiled and well - that makes this a real issue I=20 think.
 
Todd
----- Original Message -----
From:=20 Jesus = Maria=20 Mendez Perez
Sent: Wednesday, December 26, = 2007 4:31=20 PM
Subject: Re: ERS - using hash = tree?

Hello Tobias, I=B4m Jesus.

I have some questions and I = hope you can=20 help me.

First, about what happen with the gap of time that = pass while=20 you send a data object and finally at the evening the ERS-system = build
the=20 hastree for all documents that were archived during that day?. For = example, if=20 you send a data object at 3:00 pm and the ERS-system build the = hashtree at=20 8:00 pm... you have 5 hours during which that data object could lose = its=20 integrity. What can we do in this situation?
 

Could be the = solution to=20 timestamp every data object separately and inmediately after they are = sent by=20 the client and when the ERS-system have to build the hashtree, the = hash-tree=20 will built with all these data objects and its timestamps?

And = now=20 about the ARCHIVE operation. In the LTAP Protocol draft is said LTAP = Protocol=20 is asynchronous by nature. And my question is about then second = response=20 (service response). Will a client receive the second response when the = TAS=20 hast just received the data object or when the archive operation has = just=20 finished (the hashtree has been built)?
If the ARCHIVE operation = is=20 asynchronous we really need another operation to permit a client to = check if=20 the full archive operation has finished...

Finally about the=20 information called "Complementary data" in the article "Long-term = trusted=20 preservation service using service interaction protocol and evidence = records",=20 does it include only timestamping certificates?, or does it include=20 timestamps' certificates
and user signer=B4s certificates?. Are = they obtain=20 by SCVP and save up as complementary data in the archive operation?=20

Thanks and Happy = Christmas

------=_NextPart_000_053E_01C847E0.1B1AD990-- From owner-ietf-ltans@mail.imc.org Thu Dec 27 05:29:04 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7pz6-000681-SZ for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 27 Dec 2007 05:29:04 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7pz5-0005DJ-Bo for ltans-archive-ba2WohFa@lists.ietf.org; Thu, 27 Dec 2007 05:29:04 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBRADggP089514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Dec 2007 03:13:42 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBRADgkl089511; Thu, 27 Dec 2007 03:13:42 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBRADc6E089500 for ; Thu, 27 Dec 2007 03:13:39 -0700 (MST) (envelope-from jwkckid1@ix.netcom.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=mmh6cdN0iiObXxAcTyQjcqYqXJ9kXfUDgyu93a9vFdL0k5W10iB63Bi//V8mT9Iq; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [4.131.66.216] (helo=ix.netcom.com) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J7pk6-0007Pg-69; Thu, 27 Dec 2007 05:13:37 -0500 Message-ID: <47737ACB.34F606B9@ix.netcom.com> Date: Thu, 27 Dec 2007 02:13:31 -0800 From: "Jeffrey A. Williams" Organization: IDNS X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: todd glassey CC: Jesus Maria Mendez Perez , Tobias Gondrom , ietf-ltans@imc.org Subject: Re: ERS - using hash tree? References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> <054301c84823$352520a0$174f7d40@home.glassey.com> Content-Type: multipart/alternative; boundary="------------9FC701A4A91DE32844BDEB44" X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688856b2f3dbd1eb0fe87996e0d8385d4f2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.131.66.216 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b --------------9FC701A4A91DE32844BDEB44 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by balder-227.proper.com id lBRADggP089514 Todd and all, Jesus and yourself are making some very good points here as to the issues regarding "Data integrity" and the admissibility of archived data in a federal court of law. The relatively new E-Discovery rules are quite vague regarding the verifiable integrity of data and how that is determined. Challenging the admissibility of any archived data is really still wide open, ergo many different Spoliation arguments can be brought forth successfully depending on the history of the original data, and how, where, when, and how many times it was accessed, by whom, and if man in the middle manipulation was possible if said data was archived remotely or to a remote location of media. Media type may also be an issue as well. Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 todd glassey wrote: > Merry Christmas All - Jesus - the phrase you are looking for is the > concept of "Data Spoliation" and its something that offends System's > Admins everywhere because it means we want proof from their systems > which is stronger than their word. That said - if LTANS wants to be > used in the world it needs to meet Legal Control Requirements on > Digital Content and if it doesn't it doesn't matter what we do > technology wise if that is not done, since the records controlled in > the LTANS system will not be admissible in a court of law without > extreme cost and extra hearings to authenticate that data > properly... The problem here I think is that this WG doesn't want to > hear that. It also doesn't seem to want to embrace that the Court's > are a lot smarter than they used to be. One of my partner's is > actually fighting a data spoliation case in the Federal Court's in NY > so I know this stuff is a key issue. > As to your commentary - Those five hours of data are spoiled and well > - that makes this a real issue I think. Todd > > ----- Original Message ----- > From: Jesus Maria Mendez Perez > To: Tobias Gondrom > Cc: ietf-ltans@imc.org > Sent: Wednesday, December 26, 2007 4:31 PM > Subject: Re: ERS - using hash tree? > Hello Tobias, I=B4m Jesus. > > I have some questions and I hope you can help me. > > First, about what happen with the gap of time that pass > while you send a data object and finally at the evening the > ERS-system build > the hastree for all documents that were archived during that > day?. For example, if you send a data object at 3:00 pm and > the ERS-system build the hashtree at 8:00 pm... you have 5 > hours during which that data object could lose its > integrity. What can we do in this situation? > Could be the solution to timestamp every data object > separately and inmediately after they are sent by the client > and when the ERS-system have to build the hashtree, the > hash-tree will built with all these data objects and its > timestamps? > > And now about the ARCHIVE operation. In the LTAP Protocol > draft is said LTAP Protocol is asynchronous by nature. And > my question is about then second response (service > response). Will a client receive the second response when > the TAS hast just received the data object or when the > archive operation has just finished (the hashtree has been > built)? > If the ARCHIVE operation is asynchronous we really need > another operation to permit a client to check if the full > archive operation has finished... > > Finally about the information called "Complementary data" in > the article "Long-term trusted preservation service using > service interaction protocol and evidence records", does it > include only timestamping certificates?, or does it include > timestamps' certificates > and user signer=B4s certificates?. Are they obtain by SCVP and > save up as complementary data in the archive operation? > > Thanks and Happy Christmas > > --------------9FC701A4A91DE32844BDEB44 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Todd and all,

  Jesus and yourself are making some very good points here as to
the issues regarding "Data integrity" and the admissibility of
archived data in a federal court of law.  The relatively new
E-Discovery rules are quite vague regarding the verifiable
integrity of data and how that is determined.  Challenging
the admissibility of any archived data is really still wide open,
ergo many different Spoliation arguments can be brought forth
successfully depending on the history of the original data, and
how, where, when, and how many times it was accessed, by
whom, and if man in the middle manipulation was possible if
said data was archived remotely or to a remote location of
media.  Media type may also be an issue as well.

Regards,

Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
jwkckid1@ix.netcom.com
My Phone: 214-244-4827

todd glassey wrote:

Merry Christmas All - Jesus  - the phrase you are looking for is the concept of "Data Spoliation" and its something that offends System's Admins everywhere because it means we want proof from their systems which is stronger than their word. That said - if LTANS wants to be used in the world it needs to meet Legal Control Requirements on Digital Content and if it doesn't it doesn't matter what we do technology wise if that is not done, since the records controlled in the LTANS system will not be admissible in a court of law without extreme cost and extra hearings to authenticate that data properly... The problem here I think is that this WG doesn't want to hear that. It also doesn't seem to want to embrace that the Court's are a lot smarter than they used to be. One of my partner's is actually fighting a data spoliation case in the Federal Court's in NY so I know this stuff is a key issue. 
As to your commentary - Those five hours of data are spoiled and well - that makes this a real issue I think. Todd
----- Original Message -----
Sent: Wednesday, December 26, 2007 4:31 PM
Subject: Re: ERS - using hash tree?
 Hello Tobias, I´m Jesus.

I have some questions and I hope you can help me.

First, about what happen with the gap of time that pass while you send a data object and finally at the evening the ERS-system build
the hastree for all documents that were archived during that day?. For example, if you send a data object at 3:00 pm and the ERS-system build the hashtree at 8:00 pm... you have 5 hours during which that data object could lose its integrity. What can we do in this situation?  
Could be the solution to timestamp every data object separately and inmediately after they are sent by the client and when the ERS-system have to build the hashtree, the hash-tree will built with all these data objects and its timestamps?

And now about the ARCHIVE operation. In the LTAP Protocol draft is said LTAP Protocol is asynchronous by nature. And my question is about then second response (service response). Will a client receive the second response when the TAS hast just received the data object or when the archive operation has just finished (the hashtree has been built)?
If the ARCHIVE operation is asynchronous we really need another operation to permit a client to check if the full archive operation has finished...

Finally about the information called "Complementary data" in the article "Long-term trusted preservation service using service interaction protocol and evidence records", does it include only timestamping certificates?, or does it include timestamps' certificates
and user signer´s certificates?. Are they obtain by SCVP and save up as complementary data in the archive operation?

Thanks and Happy Christmas
 

--------------9FC701A4A91DE32844BDEB44-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBRADggP089514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Dec 2007 03:13:42 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBRADgkl089511; Thu, 27 Dec 2007 03:13:42 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBRADc6E089500 for ; Thu, 27 Dec 2007 03:13:39 -0700 (MST) (envelope-from jwkckid1@ix.netcom.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=mmh6cdN0iiObXxAcTyQjcqYqXJ9kXfUDgyu93a9vFdL0k5W10iB63Bi//V8mT9Iq; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [4.131.66.216] (helo=ix.netcom.com) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J7pk6-0007Pg-69; Thu, 27 Dec 2007 05:13:37 -0500 Message-ID: <47737ACB.34F606B9@ix.netcom.com> Date: Thu, 27 Dec 2007 02:13:31 -0800 From: "Jeffrey A. Williams" Organization: IDNS X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: todd glassey CC: Jesus Maria Mendez Perez , Tobias Gondrom , ietf-ltans@imc.org Subject: Re: ERS - using hash tree? References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> <054301c84823$352520a0$174f7d40@home.glassey.com> Content-Type: multipart/alternative; boundary="------------9FC701A4A91DE32844BDEB44" X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688856b2f3dbd1eb0fe87996e0d8385d4f2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.131.66.216 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --------------9FC701A4A91DE32844BDEB44 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Todd and all, Jesus and yourself are making some very good points here as to the issues regarding "Data integrity" and the admissibility of archived data in a federal court of law. The relatively new E-Discovery rules are quite vague regarding the verifiable integrity of data and how that is determined. Challenging the admissibility of any archived data is really still wide open, ergo many different Spoliation arguments can be brought forth successfully depending on the history of the original data, and how, where, when, and how many times it was accessed, by whom, and if man in the middle manipulation was possible if said data was archived remotely or to a remote location of media. Media type may also be an issue as well. Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 todd glassey wrote: > Merry Christmas All - Jesus - the phrase you are looking for is the > concept of "Data Spoliation" and its something that offends System's > Admins everywhere because it means we want proof from their systems > which is stronger than their word. That said - if LTANS wants to be > used in the world it needs to meet Legal Control Requirements on > Digital Content and if it doesn't it doesn't matter what we do > technology wise if that is not done, since the records controlled in > the LTANS system will not be admissible in a court of law without > extreme cost and extra hearings to authenticate that data > properly... The problem here I think is that this WG doesn't want to > hear that. It also doesn't seem to want to embrace that the Court's > are a lot smarter than they used to be. One of my partner's is > actually fighting a data spoliation case in the Federal Court's in NY > so I know this stuff is a key issue. > As to your commentary - Those five hours of data are spoiled and well > - that makes this a real issue I think. Todd > > ----- Original Message ----- > From: Jesus Maria Mendez Perez > To: Tobias Gondrom > Cc: ietf-ltans@imc.org > Sent: Wednesday, December 26, 2007 4:31 PM > Subject: Re: ERS - using hash tree? > Hello Tobias, I´m Jesus. > > I have some questions and I hope you can help me. > > First, about what happen with the gap of time that pass > while you send a data object and finally at the evening the > ERS-system build > the hastree for all documents that were archived during that > day?. For example, if you send a data object at 3:00 pm and > the ERS-system build the hashtree at 8:00 pm... you have 5 > hours during which that data object could lose its > integrity. What can we do in this situation? > Could be the solution to timestamp every data object > separately and inmediately after they are sent by the client > and when the ERS-system have to build the hashtree, the > hash-tree will built with all these data objects and its > timestamps? > > And now about the ARCHIVE operation. In the LTAP Protocol > draft is said LTAP Protocol is asynchronous by nature. And > my question is about then second response (service > response). Will a client receive the second response when > the TAS hast just received the data object or when the > archive operation has just finished (the hashtree has been > built)? > If the ARCHIVE operation is asynchronous we really need > another operation to permit a client to check if the full > archive operation has finished... > > Finally about the information called "Complementary data" in > the article "Long-term trusted preservation service using > service interaction protocol and evidence records", does it > include only timestamping certificates?, or does it include > timestamps' certificates > and user signer´s certificates?. Are they obtain by SCVP and > save up as complementary data in the archive operation? > > Thanks and Happy Christmas > > --------------9FC701A4A91DE32844BDEB44 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Todd and all,

  Jesus and yourself are making some very good points here as to
the issues regarding "Data integrity" and the admissibility of
archived data in a federal court of law.  The relatively new
E-Discovery rules are quite vague regarding the verifiable
integrity of data and how that is determined.  Challenging
the admissibility of any archived data is really still wide open,
ergo many different Spoliation arguments can be brought forth
successfully depending on the history of the original data, and
how, where, when, and how many times it was accessed, by
whom, and if man in the middle manipulation was possible if
said data was archived remotely or to a remote location of
media.  Media type may also be an issue as well.

Regards,

Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
jwkckid1@ix.netcom.com
My Phone: 214-244-4827

todd glassey wrote:

Merry Christmas All - Jesus  - the phrase you are looking for is the concept of "Data Spoliation" and its something that offends System's Admins everywhere because it means we want proof from their systems which is stronger than their word. That said - if LTANS wants to be used in the world it needs to meet Legal Control Requirements on Digital Content and if it doesn't it doesn't matter what we do technology wise if that is not done, since the records controlled in the LTANS system will not be admissible in a court of law without extreme cost and extra hearings to authenticate that data properly... The problem here I think is that this WG doesn't want to hear that. It also doesn't seem to want to embrace that the Court's are a lot smarter than they used to be. One of my partner's is actually fighting a data spoliation case in the Federal Court's in NY so I know this stuff is a key issue. 
As to your commentary - Those five hours of data are spoiled and well - that makes this a real issue I think. Todd
----- Original Message -----
Sent: Wednesday, December 26, 2007 4:31 PM
Subject: Re: ERS - using hash tree?
 Hello Tobias, I´m Jesus.

I have some questions and I hope you can help me.

First, about what happen with the gap of time that pass while you send a data object and finally at the evening the ERS-system build
the hastree for all documents that were archived during that day?. For example, if you send a data object at 3:00 pm and the ERS-system build the hashtree at 8:00 pm... you have 5 hours during which that data object could lose its integrity. What can we do in this situation?  
Could be the solution to timestamp every data object separately and inmediately after they are sent by the client and when the ERS-system have to build the hashtree, the hash-tree will built with all these data objects and its timestamps?

And now about the ARCHIVE operation. In the LTAP Protocol draft is said LTAP Protocol is asynchronous by nature. And my question is about then second response (service response). Will a client receive the second response when the TAS hast just received the data object or when the archive operation has just finished (the hashtree has been built)?
If the ARCHIVE operation is asynchronous we really need another operation to permit a client to check if the full archive operation has finished...

Finally about the information called "Complementary data" in the article "Long-term trusted preservation service using service interaction protocol and evidence records", does it include only timestamping certificates?, or does it include timestamps' certificates
and user signer´s certificates?. Are they obtain by SCVP and save up as complementary data in the archive operation?

Thanks and Happy Christmas
 

--------------9FC701A4A91DE32844BDEB44-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR0tiWb036130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Dec 2007 17:55:44 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBR0tixT036129; Wed, 26 Dec 2007 17:55:44 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR0thGN036123 for ; Wed, 26 Dec 2007 17:55:43 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VRs4wAu8SLV7mS7D8trKybEdcEO5eIlNSqyJ+nufuD6YPSFeUEGGYlGOdG+1ACuu; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J7h2D-0005gD-G4; Wed, 26 Dec 2007 19:55:41 -0500 Message-ID: <054301c84823$352520a0$174f7d40@home.glassey.com> From: "todd glassey" To: "Jesus Maria Mendez Perez" , "Tobias Gondrom" Cc: References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> Subject: Re: ERS - using hash tree? Date: Wed, 26 Dec 2007 16:55:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_053E_01C847E0.1B1AD990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7944523faf0440546160d0079b48ded95d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_053E_01C847E0.1B1AD990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Merry Christmas All - Jesus - the phrase you are looking for is the concept of "Data = Spoliation" and its something that offends System's Admins everywhere = because it means we want proof from their systems which is stronger than = their word. That said - if LTANS wants to be used in the world it needs to meet = Legal Control Requirements on Digital Content and if it doesn't it = doesn't matter what we do technology wise if that is not done, since the = records controlled in the LTANS system will not be admissible in a court = of law without extreme cost and extra hearings to authenticate that data = properly... The problem here I think is that this WG doesn't want to hear that. It = also doesn't seem to want to embrace that the Court's are a lot smarter = than they used to be. One of my partner's is actually fighting a data = spoliation case in the Federal Court's in NY so I know this stuff is a = key issue.=20 As to your commentary - Those five hours of data are spoiled and well - = that makes this a real issue I think. Todd=20 ----- Original Message -----=20 From: Jesus Maria Mendez Perez=20 To: Tobias Gondrom=20 Cc: ietf-ltans@imc.org=20 Sent: Wednesday, December 26, 2007 4:31 PM Subject: Re: ERS - using hash tree? Hello Tobias, I=B4m Jesus. I have some questions and I hope you can help me. First, about what happen with the gap of time that pass while you send = a data object and finally at the evening the ERS-system build the hastree for all documents that were archived during that day?. For = example, if you send a data object at 3:00 pm and the ERS-system build = the hashtree at 8:00 pm... you have 5 hours during which that data = object could lose its integrity. What can we do in this situation?=20 Could be the solution to timestamp every data object separately and = inmediately after they are sent by the client and when the ERS-system = have to build the hashtree, the hash-tree will built with all these data = objects and its timestamps?=20 And now about the ARCHIVE operation. In the LTAP Protocol draft is = said LTAP Protocol is asynchronous by nature. And my question is about = then second response (service response). Will a client receive the = second response when the TAS hast just received the data object or when = the archive operation has just finished (the hashtree has been built)?=20 If the ARCHIVE operation is asynchronous we really need another = operation to permit a client to check if the full archive operation has = finished... Finally about the information called "Complementary data" in the = article "Long-term trusted preservation service using service = interaction protocol and evidence records", does it include only = timestamping certificates?, or does it include timestamps' certificates=20 and user signer=B4s certificates?. Are they obtain by SCVP and save up = as complementary data in the archive operation?=20 Thanks and Happy Christmas ------=_NextPart_000_053E_01C847E0.1B1AD990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Merry Christmas All = -
 
Jesus  - the phrase = you are=20 looking for is the concept of "Data Spoliation" and its something that = offends=20 System's Admins everywhere because it means we want proof from their = systems=20 which is stronger than their word.
 
That said - if LTANS wants = to be used=20 in the world it needs to meet Legal Control Requirements on Digital = Content and=20 if it doesn't it doesn't matter what we do technology wise if that is = not done,=20 since the records controlled in the LTANS system will not be admissible = in a=20 court of law without extreme cost and extra hearings to authenticate = that data=20 properly...
 
The problem here I think is = that this=20 WG doesn't want to hear that. It also doesn't seem to want to embrace = that the=20 Court's are a lot smarter than they used to be. One of my partner's is actually = fighting a data=20 spoliation case in the Federal Court's in NY so I know this stuff is a = key=20 issue.

As to your commentary - = Those five=20 hours of data are spoiled and well - that makes this a real issue I=20 think.
 
Todd
----- Original Message -----
From:=20 Jesus = Maria=20 Mendez Perez
Sent: Wednesday, December 26, = 2007 4:31=20 PM
Subject: Re: ERS - using hash = tree?

Hello Tobias, I=B4m Jesus.

I have some questions and I = hope you can=20 help me.

First, about what happen with the gap of time that = pass while=20 you send a data object and finally at the evening the ERS-system = build
the=20 hastree for all documents that were archived during that day?. For = example, if=20 you send a data object at 3:00 pm and the ERS-system build the = hashtree at=20 8:00 pm... you have 5 hours during which that data object could lose = its=20 integrity. What can we do in this situation?
 

Could be the = solution to=20 timestamp every data object separately and inmediately after they are = sent by=20 the client and when the ERS-system have to build the hashtree, the = hash-tree=20 will built with all these data objects and its timestamps?

And = now=20 about the ARCHIVE operation. In the LTAP Protocol draft is said LTAP = Protocol=20 is asynchronous by nature. And my question is about then second = response=20 (service response). Will a client receive the second response when the = TAS=20 hast just received the data object or when the archive operation has = just=20 finished (the hashtree has been built)?
If the ARCHIVE operation = is=20 asynchronous we really need another operation to permit a client to = check if=20 the full archive operation has finished...

Finally about the=20 information called "Complementary data" in the article "Long-term = trusted=20 preservation service using service interaction protocol and evidence = records",=20 does it include only timestamping certificates?, or does it include=20 timestamps' certificates
and user signer=B4s certificates?. Are = they obtain=20 by SCVP and save up as complementary data in the archive operation?=20

Thanks and Happy = Christmas

------=_NextPart_000_053E_01C847E0.1B1AD990-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR0VMuA034301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Dec 2007 17:31:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBR0VM52034300; Wed, 26 Dec 2007 17:31:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBR0VJak034290 for ; Wed, 26 Dec 2007 17:31:19 -0700 (MST) (envelope-from jesusmmp@gmail.com) Received: by wa-out-1112.google.com with SMTP id l24so4622554waf.22 for ; Wed, 26 Dec 2007 16:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=zNYiJz5DoHRYz46j/LKtPgIyQd4Rm01N1xccMXw1kIk=; b=T+9diOJBzYf9Qlge9S9OnxudWFFMKvdbrhCdORYhq6NgQWIziZnTW5EpuBOyidXET9cQ71Lj9R0cnYtYosb2LCM25G5nCzRHJ1WgfzcHvQY60NgUDs6yc1sEkOC5YfFJaH9a2HTb4fADMpEDU40bM9LlLcxYVTk4yN8kiUudiuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=n19HqOcJdi0RNMGuke9WSV70S9G4T9yg1ReBI7DV+arGHQvwzSHQ1YiLVisbOzQ7fOyEgPqR9xAn0jJopGpHpzdnGfC/n+GYHN6kOstT+Cs11aTVJ0R/WLec8UFd5j1nTSHML9rWSGaWp2nWrDJGM2h0rxqS7SAZ7oxeCIWcGSc= Received: by 10.115.60.1 with SMTP id n1mr7045318wak.37.1198715479006; Wed, 26 Dec 2007 16:31:19 -0800 (PST) Received: by 10.114.156.10 with HTTP; Wed, 26 Dec 2007 16:31:18 -0800 (PST) Message-ID: Date: Thu, 27 Dec 2007 01:31:18 +0100 From: "Jesus Maria Mendez Perez" To: "Tobias Gondrom" Subject: Re: ERS - using hash tree? Cc: ietf-ltans@imc.org In-Reply-To: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15263_32524534.1198715479000" References: <2666EB2A846BAC4BB2D7F593301A786801F19531@MUCXGC2.opentext.net> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_15263_32524534.1198715479000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Tobias, I=B4m Jesus. I have some questions and I hope you can help me. First, about what happen with the gap of time that pass while you send a data object and finally at the evening the ERS-system build the hastree for all documents that were archived during that day?. For example, if you send a data object at 3:00 pm and the ERS-system build the hashtree at 8:00 pm... you have 5 hours during which that data object could lose its integrity. What can we do in this situation? Could be the solution to timestamp every data object separately and inmediately after they are sent by the client and when the ERS-system have to build the hashtree, the hash-tree will built with all these data objects and its timestamps? And now about the ARCHIVE operation. In the LTAP Protocol draft is said LTA= P Protocol is asynchronous by nature. And my question is about then second response (service response). Will a client receive the second response when the TAS hast just received the data object or when the archive operation ha= s just finished (the hashtree has been built)? If the ARCHIVE operation is asynchronous we really need another operation t= o permit a client to check if the full archive operation has finished... Finally about the information called "Complementary data" in the article "Long-term trusted preservation service using service interaction protocol and evidence records", does it include only timestamping certificates?, or does it include timestamps' certificates and user signer=B4s certificates?. Are they obtain by SCVP and save up as complementary data in the archive operation? Thanks and Happy Christmas ------=_Part_15263_32524534.1198715479000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello Tobias, I=B4m Jesus.

I have some questions and I hope you can = help me.

First, about what happen with the gap of time that pass whi= le you send a data object and finally at the evening the ERS-system build the hastree for all documents that were archived during that day?. For exam= ple, if you send a data object at 3:00 pm and the ERS-system build the hash= tree at 8:00 pm... you have 5 hours during which that data object could los= e its integrity. What can we do in this situation?
Could be the solution to timestamp every data object separately and inm= ediately after they are sent by the client and when the ERS-system have to = build the hashtree, the hash-tree will built with all these data objects an= d its timestamps?=20

And now about the ARCHIVE operation. In the LTAP Protocol draft is = said LTAP Protocol is asynchronous by nature. And my question is about then= second response (service response). Will a client receive the second respo= nse when the TAS hast just received the data object or when the archive ope= ration has just finished (the hashtree has been built)?
If the ARCHIVE operation is asynchronous we really need another operati= on to permit a client to check if the full archive operation has finished..= .

Finally about the information called "Complementary data"= ; in the article "Long-term trusted preservation service using service= interaction protocol and evidence records", does it include only time= stamping certificates?, or does it include timestamps' certificates
and user signer=B4s certificates?. Are they obtain by SCVP and save up = as complementary data in the archive operation?

Thanks and Happy Ch= ristmas

------=_Part_15263_32524534.1198715479000-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAKXMxs041795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 13:33:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBAKXMvW041794; Mon, 10 Dec 2007 13:33:22 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAKXKfb041786 for ; Mon, 10 Dec 2007 13:33:21 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rqkTG1BBUrXiYh4kefXbhJ/kPhRz5MKErp1g8R4yzZRgGyCzuFU5MZlWeoUbg4uR; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J1pJY-00076a-0g; Mon, 10 Dec 2007 15:33:20 -0500 Message-ID: <006001c83b6b$f4e9c680$174f7d40@home.glassey.com> From: "todd glassey" To: "Tobias Gondrom" , Cc: References: <2666EB2A846BAC4BB2D7F593301A78680201D243@MUCXGC2.opentext.net> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Date: Mon, 10 Dec 2007 11:05:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c30e03c803e84e38dec21b90eda9bb54350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tobias - I will answer this when I get home tonight. I am only in the office for a little bit today (I have a cold) and need to pull a couple of cat-5 lines from our new Time Servers into the lab. Todd ----- Original Message ----- From: "Tobias Gondrom" To: ; "TS Glassey" Cc: Sent: Monday, December 10, 2007 10:32 AM Subject: RE: comment on draft-ietf-ltans-dssc-01.txt > > Hi all, > > hm actually I do not understand the argument or miss the point. > Could you please explain a bit more why your argument mandates against a > flat or for a non-flat structure of the DSSC format? > > Thanks, Tobias > > > >> -----Original Message----- >> From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] >> On Behalf Of jwkckid1@ix.netcom.com >> Sent: Sunday, December 09, 2007 12:32 AM >> To: TS Glassey >> Cc: ietf-ltans@imc.org >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >> >> Todd and all, >> >> I believe Todd has a very good and valid point here. >> A flat sequence seems very much less than sufficient. >> >> Regards, >> >> Jeffrey A. Williams >> Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) >> "Obedience of the law is the greatest freedom" - >> Abraham Lincoln >> >> "Credit should go with the performance of duty and not with what is > very >> often the accident of glory" - Theodore Roosevelt >> >> "If the probability be called P; the injury, L; and the burden, B; >> liability >> depends upon whether B is less than L multiplied by >> P: i.e., whether B is less than PL." >> United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] >> =============================================================== >> Updated 1/26/04 >> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. > div. >> of >> Information Network Eng. INEG. INC. >> ABA member in good standing member ID 01257402 E-Mail >> jwkckid1@ix.netcom.com >> Phone: 214-244-4827 >> >> >> -----Original Message----- >> >From: TS Glassey >> >Sent: Dec 8, 2007 9:43 AM >> >To: Thomas Kunz , "Turner, Sean P." >> >> >Cc: ietf-ltans@imc.org >> >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> > >> > >> >Maybe not from a control perspective but that is only half of the >> picture. >> >The key value of LTANS as a 'thing' is that is would need to meet > both >> the >> >legal and emerging document management processes or else those > parties >> who >> >are constrained by those frameworks will not be able to use it, nor > will >> >those parties attached to the people so constrained. >> > >> >Todd Glassey >> > >> >----- Original Message ----- >> >From: "Thomas Kunz" >> >To: "Turner, Sean P." >> >Cc: >> >Sent: Friday, December 07, 2007 7:06 AM >> >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> > >> > >> >> We think, our flat sequence is sufficient. >> >> >> >> The goal of a policy is to specify a range for specific (safety- >> critical) >> >> parameters of an algorithm. Therefor it's not necessary to define > all >> >> parameters. >> >> >> >> In the evaluations of BSI and NIST >> >> (e.g.: http://www.keylength.com/en/4/) for elliptic curve > algorithms >> only >> >> one value is defined (namely q). By NIST a q_length of 160 is > suitable >> >> until 2010. >> >> >> >> In this case, the XML structure would be: >> >> >> >> >> >> >> >> EC-DSA 160 >> >> ... >> >> >> >> 160 >> >> 2010-12-31 >> >> >> >> >> >> >> >> so & tk >> >> >> >> >> >> >> >> >> >> >> >> Turner, Sean P. schrieb: >> >>> Yes I did misunderstand. With algorithms like DSA where there are > few >> >>> parameters your structure might work but for EC algorithms (I > attached >> >>> some >> >>> of the ASN.1 for their parameters) I don't think the flat sequence > of >> >>> will >> >>> work. >> >>> >> >>> ECParameters ::= CHOICE { >> >>> namedCurve CURVE.&id({NamedCurve}), >> >>> specifiedCuve SpecifiedCurve, >> >>> implicitCurve NULL >> >>> } >> >>> >> >>> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >> >>> WITH SYNTAX { ID &id } >> >>> >> >>> NamedCurve CURVE ::= { >> >>> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >> >>> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >> >>> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >> >>> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >> >>> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >> >>> ... -- Extensible >> >>> } >> >>> >> >>> SpecifiedCurve ::= SEQUENCE { >> >>> version SpecifiedCurveVersion >> >>> ( ecpVer1 | ecpVer2 | ecpVer3 ), >> >>> fieldID FieldID {{FieldTypes}}, >> >>> curve Curve, -- Curve E >> >>> base ECPoint, -- Base point P >> >>> order INTEGER, -- Order n of the base point >> >>> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >> >>> hash HashAlgorithm OPTIONAL, >> >>> ... -- Extensible >> >>> } >> >>> >> >>> SpecifiedCurveVersion ::= INTEGER { >> >>> ecpVer1(1), >> >>> ecpVer2(2), >> >>> ecpVer3(3), >> >>> ... -- Extensible >> >>> } >> >>> FIELD-ID ::= TYPE-IDENTIFIER >> >>> >> >>> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >> >>> FIELD-ID.&id({IOSet}), >> >>> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >> >>> } >> >>> >> >>> FieldTypes FIELD-ID ::= { >> >>> { Prime-p IDENTIFIED BY prime-field } | >> >>> { Characteristic-two IDENTIFIED BY characteristic-two-field } > | >> >>> ... -- Extensible >> >>> } >> >>> >> >>> prime-field OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 > } >> >>> >> >>> Prime-p ::= INTEGER >> >>> >> >>> characteristic-two-field OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 > } >> >>> >> >>> Characteristic-two ::= SEQUENCE { >> >>> m INTEGER, -- Field size 2^m >> >>> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >> >>> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >> >>> } >> >>> >> >>> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >> >>> >> >>> BasisTypes CHARACTERISTIC-TWO ::= { >> >>> { NULL IDENTIFIED BY gnBasis } | >> >>> { Trinomial IDENTIFIED BY tpBasis } | >> >>> { Pentanomial IDENTIFIED BY ppBasis } | >> >>> ... -- Extensible >> >>> } >> >>> >> >>> gnBasis OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >>> characteristic-two-basis(2) 1 } >> >>> >> >>> tpBasis OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >>> characteristic-two-basis(2) 2 } >> >>> >> >>> Trinomial ::= INTEGER >> >>> >> >>> ppBasis OBJECT IDENTIFIER ::= { >> >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> >>> characteristic-two-basis(2) 3 } >> >>> >> >>> Pentanomial ::= SEQUENCE { >> >>> k1 INTEGER, -- k1 > 0 >> >>> k2 INTEGER, -- k2 > k1 >> >>> k3 INTEGER -- k3 > k2 >> >>> } >> >>> >> >>> Curve ::= SEQUENCE { >> >>> a FieldElement, >> >>> b FieldElement, >> >>> seed BIT STRING OPTIONAL >> >>> -- Shall be present if used in SpecifiedCurve >> >>> -- with version of ecdpVer2 or ecdpVer3 >> >>> } >> >>> FieldElement ::= OCTET STRING >> >>> >> >>> ECPoint ::= OCTET STRING >> >>>> -----Original Message----- >> >>>> From: owner-ietf-ltans@mail.imc.org >> >>>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >> >>>> Sent: Thursday, December 06, 2007 4:52 AM >> >>>> To: Turner, Sean P. >> >>>> Cc: ietf-ltans@imc.org >> >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >>>> >> >>>> We think, You misunderstood our last post. >> >>>> With the mentioned structure (AlgorithmValidityInfo) we wanted to >> show >> >>>> that we CANNOT use the AlgorithmIdentifier. >> >>>> >> >>>> The reason is, we cannot model the following cases: >> >>>> 1. constraints for more than one parameter (e.g. p > 1024 and q > > 160 >> in >> >>>> case of DSA). >> >>>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >> >>>> >> >>>> The main problem is that AlgorithmIdentifier describes entirely > one >> >>>> algorithm with all its parameters. Therefor it is not possible to > set >> >>>> different constraints for the parameters. >> >>>> >> >>>> so & tk >> >>>> >> >>>> >> >>>> >> >>>> Turner, Sean P. schrieb: >> >>>>> This would work for me. >> >>>>> >> >>>>> spt >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >> >>>>>> Sent: Wednesday, December 05, 2007 8:02 AM >> >>>>>> To: Turner, Sean P. >> >>>>>> Cc: ietf-ltans@imc.org >> >>>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >>>>>> >> >>>>>> The problem with your suggested syntax is the definition of the > our >> >>>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >> >>>> structure, we >> >>>>>> would integrate the constraints as follows: >> >>>>>> >> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { >> >>>>>> identifier AlgorithmIdentifier, >> >>>>>> constraint CHOICE { >> >>>>>> exact [0] OCTET STRING, >> >>>>>> min [1] OCTET STRING, >> >>>>>> max [2] OCTET STRING, >> >>>>>> range [3] Range, >> >>>>>> other [4] OtherConstraints >> >>>>>> validity Validity OPTIONAL, >> >>>>>> information Information OPTIONAL } >> >>>>>> >> >>>>>> It's not possible to determine constraints for more than one >> parameter >> >>>>>> (e.g. p > 1024 and q > 160 in case of DSA). >> >>>>>> Additionally defining ranges is impossible (e.g. modulus < >> >>>>>> 2048 and modulus > 1024). >> >>>>>> >> >>>>>> >> >>>>>> so & tk >> >>>>>> >> >>>>>> >> >>>>>> Turner, Sean P. schrieb: >> >>>>>>> I'm only commenting on the Parameter structure in the >> >>>> ASN.1. I think >> >>>>>>> that it might be better to change Algorithm to be a sequence > of >> >>>>>>> algorithmIdentifier, validity, and information - call it >> >>>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >> >>>>>>> >> >>>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >> >>>>>>> algorithm's object identifier also define the parameters. So > it >> >>>>>>> probably makes sense to reuse this structure. >> >>>>>>> >> >>>>>>> 2. The parameters structures for some of the newer >> >>>>>> algorithms is quite >> >>>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >> >>>>>> [RFC3279] >> >>>>>>> aren't just an OID they are nested structure. >> >>>>>>> >> >>>>>>> (not sure how to do it in XML) >> >>>>>>> >> >>>>>>> Replace: >> >>>>>>> >> >>>>>>> Algorithm ::= SEQUENCE { >> >>>>>>> algorithmIdentifier AlgID, >> >>>>>>> parameters [0] SEQUENCE OF Parameter > OPTIONAL, >> >>>>>>> validity [1] Validity, >> >>>>>>> information [2] SEQUENCE OF UTF8String > OPTIONAL >> >>>>>>> } >> >>>>>>> >> >>>>>>> AlgID ::= SEQUENCE { >> >>>>>>> name UTF8String, >> >>>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >> >>>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >> >>>>>>> } >> >>>>>>> >> >>>>>>> Parameter ::= SEQUENCE { >> >>>>>>> name UTF8String, >> >>>>>>> constraint CHOICE { >> >>>>>>> exact [0] OCTET STRING, >> >>>>>>> min [1] OCTET STRING, >> >>>>>>> max [2] OCTET STRING, >> >>>>>>> range [3] Range, >> >>>>>>> other [4] OtherConstraints >> >>>>>>> } >> >>>>>>> } >> >>>>>>> >> >>>>>>> With: >> >>>>>>> >> >>>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >> >>>>>>> AlgorithmIdentifier, >> >>>>>>> validity Validity OPTIONAL, >> >>>>>>> information Information OPTIONAL } >> >>>>>>> >> >>>>>>> Validity ::= SEQUENCE { >> >>>>>>> start [0] GeneralizedTime OPTIONAL, >> >>>>>>> end [1] GeneralizedTime OPTIONAL } >> >>>>>>> >> >>>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >> >>>>>>> >> >>>>>>> -- From RFC3280 >> >>>>>>> AlgorithmIdentifier ::= SEQUENCE { >> >>>>>>> algorithm OBJECT IDENTIFIER, >> >>>>>>> parameters ANY DEFINED BY algorithm OPTIONAL > } >> >>>>>>> -- contains a value of the > type >> >>>>>>> -- registered for use with the >> >>>>>>> -- algorithm object >> >>>> identifier value >> >>>>>>> spt >> >>>>>>> >> >>>>>>> >> >>>>> >> >>> >> >>> >> >> >> > > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIWBV0028991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 11:32:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBAIWBsW028990; Mon, 10 Dec 2007 11:32:11 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIWAjY028983 for ; Mon, 10 Dec 2007 11:32:10 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lBAIW68e004870; Mon, 10 Dec 2007 19:32:06 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg03.opentext.net [149.235.128.137]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lBAIW3sR021593; Mon, 10 Dec 2007 13:32:04 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Mon, 10 Dec 2007 19:32:02 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78680201D243@MUCXGC2.opentext.net> In-reply-to: <24797949.1197156733684.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment on draft-ietf-ltans-dssc-01.txt Thread-Index: Acg59WqwzVETIJejRcuInCvYHergQQBZLLDw X-Priority: 5 Importance: low From: "Tobias Gondrom" To: , "TS Glassey" Cc: X-Archived: msg.BGttUkX:2007-12-10:mucpm02.smtp.dmz.opentext.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lBAIWBjY028984 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi all, hm actually I do not understand the argument or miss the point. Could you please explain a bit more why your argument mandates against a flat or for a non-flat structure of the DSSC format? Thanks, Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of jwkckid1@ix.netcom.com > Sent: Sunday, December 09, 2007 12:32 AM > To: TS Glassey > Cc: ietf-ltans@imc.org > Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > Todd and all, > > I believe Todd has a very good and valid point here. > A flat sequence seems very much less than sufficient. > > Regards, > > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > > "Credit should go with the performance of duty and not with what is very > often the accident of glory" - Theodore Roosevelt > > "If the probability be called P; the injury, L; and the burden, B; > liability > depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. > of > Information Network Eng. INEG. INC. > ABA member in good standing member ID 01257402 E-Mail > jwkckid1@ix.netcom.com > Phone: 214-244-4827 > > > -----Original Message----- > >From: TS Glassey > >Sent: Dec 8, 2007 9:43 AM > >To: Thomas Kunz , "Turner, Sean P." > > >Cc: ietf-ltans@imc.org > >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > > > >Maybe not from a control perspective but that is only half of the > picture. > >The key value of LTANS as a 'thing' is that is would need to meet both > the > >legal and emerging document management processes or else those parties > who > >are constrained by those frameworks will not be able to use it, nor will > >those parties attached to the people so constrained. > > > >Todd Glassey > > > >----- Original Message ----- > >From: "Thomas Kunz" > >To: "Turner, Sean P." > >Cc: > >Sent: Friday, December 07, 2007 7:06 AM > >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > > > >> We think, our flat sequence is sufficient. > >> > >> The goal of a policy is to specify a range for specific (safety- > critical) > >> parameters of an algorithm. Therefor it's not necessary to define all > >> parameters. > >> > >> In the evaluations of BSI and NIST > >> (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms > only > >> one value is defined (namely q). By NIST a q_length of 160 is suitable > >> until 2010. > >> > >> In this case, the XML structure would be: > >> > >> > >> > >> EC-DSA 160 > >> ... > >> > >> 160 > >> 2010-12-31 > >> > >> > >> > >> so & tk > >> > >> > >> > >> > >> > >> Turner, Sean P. schrieb: > >>> Yes I did misunderstand. With algorithms like DSA where there are few > >>> parameters your structure might work but for EC algorithms (I attached > >>> some > >>> of the ASN.1 for their parameters) I don't think the flat sequence of > >>> will > >>> work. > >>> > >>> ECParameters ::= CHOICE { > >>> namedCurve CURVE.&id({NamedCurve}), > >>> specifiedCuve SpecifiedCurve, > >>> implicitCurve NULL > >>> } > >>> > >>> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } > >>> WITH SYNTAX { ID &id } > >>> > >>> NamedCurve CURVE ::= { > >>> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | > >>> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | > >>> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | > >>> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | > >>> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | > >>> ... -- Extensible > >>> } > >>> > >>> SpecifiedCurve ::= SEQUENCE { > >>> version SpecifiedCurveVersion > >>> ( ecpVer1 | ecpVer2 | ecpVer3 ), > >>> fieldID FieldID {{FieldTypes}}, > >>> curve Curve, -- Curve E > >>> base ECPoint, -- Base point P > >>> order INTEGER, -- Order n of the base point > >>> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n > >>> hash HashAlgorithm OPTIONAL, > >>> ... -- Extensible > >>> } > >>> > >>> SpecifiedCurveVersion ::= INTEGER { > >>> ecpVer1(1), > >>> ecpVer2(2), > >>> ecpVer3(3), > >>> ... -- Extensible > >>> } > >>> FIELD-ID ::= TYPE-IDENTIFIER > >>> > >>> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType > >>> FIELD-ID.&id({IOSet}), > >>> parameters FIELD-ID.&Type({IOSet}{@fieldType}) > >>> } > >>> > >>> FieldTypes FIELD-ID ::= { > >>> { Prime-p IDENTIFIED BY prime-field } | > >>> { Characteristic-two IDENTIFIED BY characteristic-two-field } | > >>> ... -- Extensible > >>> } > >>> > >>> prime-field OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } > >>> > >>> Prime-p ::= INTEGER > >>> > >>> characteristic-two-field OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } > >>> > >>> Characteristic-two ::= SEQUENCE { > >>> m INTEGER, -- Field size 2^m > >>> basis CHARACTERISTIC-TWO.&id({BasisTypes}), > >>> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) > >>> } > >>> > >>> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER > >>> > >>> BasisTypes CHARACTERISTIC-TWO ::= { > >>> { NULL IDENTIFIED BY gnBasis } | > >>> { Trinomial IDENTIFIED BY tpBasis } | > >>> { Pentanomial IDENTIFIED BY ppBasis } | > >>> ... -- Extensible > >>> } > >>> > >>> gnBasis OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >>> characteristic-two-basis(2) 1 } > >>> > >>> tpBasis OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >>> characteristic-two-basis(2) 2 } > >>> > >>> Trinomial ::= INTEGER > >>> > >>> ppBasis OBJECT IDENTIFIER ::= { > >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > >>> characteristic-two-basis(2) 3 } > >>> > >>> Pentanomial ::= SEQUENCE { > >>> k1 INTEGER, -- k1 > 0 > >>> k2 INTEGER, -- k2 > k1 > >>> k3 INTEGER -- k3 > k2 > >>> } > >>> > >>> Curve ::= SEQUENCE { > >>> a FieldElement, > >>> b FieldElement, > >>> seed BIT STRING OPTIONAL > >>> -- Shall be present if used in SpecifiedCurve > >>> -- with version of ecdpVer2 or ecdpVer3 > >>> } > >>> FieldElement ::= OCTET STRING > >>> > >>> ECPoint ::= OCTET STRING > >>>> -----Original Message----- > >>>> From: owner-ietf-ltans@mail.imc.org > >>>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > >>>> Sent: Thursday, December 06, 2007 4:52 AM > >>>> To: Turner, Sean P. > >>>> Cc: ietf-ltans@imc.org > >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>>> > >>>> We think, You misunderstood our last post. > >>>> With the mentioned structure (AlgorithmValidityInfo) we wanted to > show > >>>> that we CANNOT use the AlgorithmIdentifier. > >>>> > >>>> The reason is, we cannot model the following cases: > >>>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 > in > >>>> case of DSA). > >>>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) > >>>> > >>>> The main problem is that AlgorithmIdentifier describes entirely one > >>>> algorithm with all its parameters. Therefor it is not possible to set > >>>> different constraints for the parameters. > >>>> > >>>> so & tk > >>>> > >>>> > >>>> > >>>> Turner, Sean P. schrieb: > >>>>> This would work for me. > >>>>> > >>>>> spt > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] > >>>>>> Sent: Wednesday, December 05, 2007 8:02 AM > >>>>>> To: Turner, Sean P. > >>>>>> Cc: ietf-ltans@imc.org > >>>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>>>>> > >>>>>> The problem with your suggested syntax is the definition of the our > >>>>>> constraints. If we used the RFC3280 AlgorithmIdentifier > >>>> structure, we > >>>>>> would integrate the constraints as follows: > >>>>>> > >>>>>> AlgorithmValidityInfo ::= SEQUENCE { > >>>>>> identifier AlgorithmIdentifier, > >>>>>> constraint CHOICE { > >>>>>> exact [0] OCTET STRING, > >>>>>> min [1] OCTET STRING, > >>>>>> max [2] OCTET STRING, > >>>>>> range [3] Range, > >>>>>> other [4] OtherConstraints > >>>>>> validity Validity OPTIONAL, > >>>>>> information Information OPTIONAL } > >>>>>> > >>>>>> It's not possible to determine constraints for more than one > parameter > >>>>>> (e.g. p > 1024 and q > 160 in case of DSA). > >>>>>> Additionally defining ranges is impossible (e.g. modulus < > >>>>>> 2048 and modulus > 1024). > >>>>>> > >>>>>> > >>>>>> so & tk > >>>>>> > >>>>>> > >>>>>> Turner, Sean P. schrieb: > >>>>>>> I'm only commenting on the Parameter structure in the > >>>> ASN.1. I think > >>>>>>> that it might be better to change Algorithm to be a sequence of > >>>>>>> algorithmIdentifier, validity, and information - call it > >>>>>>> AlgorithmValidityInfo. I suggest this for two reasons: > >>>>>>> > >>>>>>> 1. The AlgorithmIdentifier structure that is used to assign an > >>>>>>> algorithm's object identifier also define the parameters. So it > >>>>>>> probably makes sense to reuse this structure. > >>>>>>> > >>>>>>> 2. The parameters structures for some of the newer > >>>>>> algorithms is quite > >>>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs > >>>>>> [RFC3279] > >>>>>>> aren't just an OID they are nested structure. > >>>>>>> > >>>>>>> (not sure how to do it in XML) > >>>>>>> > >>>>>>> Replace: > >>>>>>> > >>>>>>> Algorithm ::= SEQUENCE { > >>>>>>> algorithmIdentifier AlgID, > >>>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, > >>>>>>> validity [1] Validity, > >>>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL > >>>>>>> } > >>>>>>> > >>>>>>> AlgID ::= SEQUENCE { > >>>>>>> name UTF8String, > >>>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > >>>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL > >>>>>>> } > >>>>>>> > >>>>>>> Parameter ::= SEQUENCE { > >>>>>>> name UTF8String, > >>>>>>> constraint CHOICE { > >>>>>>> exact [0] OCTET STRING, > >>>>>>> min [1] OCTET STRING, > >>>>>>> max [2] OCTET STRING, > >>>>>>> range [3] Range, > >>>>>>> other [4] OtherConstraints > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> With: > >>>>>>> > >>>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier > >>>>>>> AlgorithmIdentifier, > >>>>>>> validity Validity OPTIONAL, > >>>>>>> information Information OPTIONAL } > >>>>>>> > >>>>>>> Validity ::= SEQUENCE { > >>>>>>> start [0] GeneralizedTime OPTIONAL, > >>>>>>> end [1] GeneralizedTime OPTIONAL } > >>>>>>> > >>>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > >>>>>>> > >>>>>>> -- From RFC3280 > >>>>>>> AlgorithmIdentifier ::= SEQUENCE { > >>>>>>> algorithm OBJECT IDENTIFIER, > >>>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } > >>>>>>> -- contains a value of the type > >>>>>>> -- registered for use with the > >>>>>>> -- algorithm object > >>>> identifier value > >>>>>>> spt > >>>>>>> > >>>>>>> > >>>>> > >>> > >>> > >> > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIW51Y028976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 11:32:05 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lBAIW5W1028975; Mon, 10 Dec 2007 11:32:05 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBAIW1UD028967 for ; Mon, 10 Dec 2007 11:32:04 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lBAIVvuc004841; Mon, 10 Dec 2007 19:31:57 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg03.opentext.net [149.235.128.137]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lBAIVt7r021311; Mon, 10 Dec 2007 13:31:56 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_004E_01C83B63.50B41780"; micalg=SHA1 Date: Mon, 10 Dec 2007 19:31:54 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A78680201D242@MUCXGC2.opentext.net> In-reply-to: <4759615B.3000508@sit.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment on draft-ietf-ltans-dssc-01.txt Thread-Index: Acg45PITvIVohAirQSWky3QdKuEu9ACdcNzQ X-Priority: 5 Importance: low From: "Tobias Gondrom" To: "Thomas Kunz" , "Turner, Sean P." Cc: X-Archived: msg.Bf3Kebj:2007-12-10:mucpm02.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C83B63.50B41780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hm, I agree with Thomas. Intuitively I feel that a flat structure of parameters will always be sufficient to describe a used algorithm. Simply because every authority publishing such info will most probably always publish this in algorithm name and a simple (1..n) list of its acceptable parameters. Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Thomas Kunz > Sent: Friday, December 07, 2007 4:06 PM > To: Turner, Sean P. > Cc: ietf-ltans@imc.org > Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > We think, our flat sequence is sufficient. > > The goal of a policy is to specify a range for specific > (safety-critical) parameters of an algorithm. Therefor it's not > necessary to define all parameters. > > In the evaluations of BSI and NIST > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms > only one value is defined (namely q). By NIST a q_length of 160 is > suitable until 2010. > > In this case, the XML structure would be: > > > > EC-DSA 160 > ... > > 160 > 2010-12-31 > > > > so & tk > > > > > > Turner, Sean P. schrieb: > > Yes I did misunderstand. With algorithms like DSA where there are few > > parameters your structure might work but for EC algorithms (I attached > some > > of the ASN.1 for their parameters) I don't think the flat sequence of > will > > work. > > > > ECParameters ::= CHOICE { > > namedCurve CURVE.&id({NamedCurve}), > > specifiedCuve SpecifiedCurve, > > implicitCurve NULL > > } > > > > CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } > > WITH SYNTAX { ID &id } > > > > NamedCurve CURVE ::= { > > { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | > > { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | > > { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | > > { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | > > { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | > > ... -- Extensible > > } > > > > SpecifiedCurve ::= SEQUENCE { > > version SpecifiedCurveVersion > > ( ecpVer1 | ecpVer2 | ecpVer3 ), > > fieldID FieldID {{FieldTypes}}, > > curve Curve, -- Curve E > > base ECPoint, -- Base point P > > order INTEGER, -- Order n of the base point > > cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n > > hash HashAlgorithm OPTIONAL, > > ... -- Extensible > > } > > > > SpecifiedCurveVersion ::= INTEGER { > > ecpVer1(1), > > ecpVer2(2), > > ecpVer3(3), > > ... -- Extensible > > } > > FIELD-ID ::= TYPE-IDENTIFIER > > > > FieldID { FIELD-ID:IOSet } ::= SEQUENCE { > > fieldType FIELD-ID.&id({IOSet}), > > parameters FIELD-ID.&Type({IOSet}{@fieldType}) > > } > > > > FieldTypes FIELD-ID ::= { > > { Prime-p IDENTIFIED BY prime-field } | > > { Characteristic-two IDENTIFIED BY characteristic-two-field } | > > ... -- Extensible > > } > > > > prime-field OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } > > > > Prime-p ::= INTEGER > > > > characteristic-two-field OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } > > > > Characteristic-two ::= SEQUENCE { > > m INTEGER, -- Field size 2^m > > basis CHARACTERISTIC-TWO.&id({BasisTypes}), > > parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) > > } > > > > CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER > > > > BasisTypes CHARACTERISTIC-TWO ::= { > > { NULL IDENTIFIED BY gnBasis } | > > { Trinomial IDENTIFIED BY tpBasis } | > > { Pentanomial IDENTIFIED BY ppBasis } | > > ... -- Extensible > > } > > > > gnBasis OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > > characteristic-two-basis(2) 1 } > > > > tpBasis OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > > characteristic-two-basis(2) 2 } > > > > Trinomial ::= INTEGER > > > > ppBasis OBJECT IDENTIFIER ::= { > > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > > characteristic-two-basis(2) 3 } > > > > Pentanomial ::= SEQUENCE { > > k1 INTEGER, -- k1 > 0 > > k2 INTEGER, -- k2 > k1 > > k3 INTEGER -- k3 > k2 > > } > > > > Curve ::= SEQUENCE { > > a FieldElement, > > b FieldElement, > > seed BIT STRING OPTIONAL > > -- Shall be present if used in SpecifiedCurve > > -- with version of ecdpVer2 or ecdpVer3 > > } > > FieldElement ::= OCTET STRING > > > > ECPoint ::= OCTET STRING > > > >> -----Original Message----- > >> From: owner-ietf-ltans@mail.imc.org > >> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > >> Sent: Thursday, December 06, 2007 4:52 AM > >> To: Turner, Sean P. > >> Cc: ietf-ltans@imc.org > >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >> > >> We think, You misunderstood our last post. > >> With the mentioned structure (AlgorithmValidityInfo) we wanted > >> to show that we CANNOT use the AlgorithmIdentifier. > >> > >> The reason is, we cannot model the following cases: > >> 1. constraints for more than one parameter (e.g. p > 1024 and > >> q > 160 in case of DSA). > >> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) > >> > >> The main problem is that AlgorithmIdentifier describes > >> entirely one algorithm with all its parameters. Therefor it is > >> not possible to set different constraints for the parameters. > >> > >> so & tk > >> > >> > >> > >> Turner, Sean P. schrieb: > >>> This would work for me. > >>> > >>> spt > >>> > >>>> -----Original Message----- > >>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] > >>>> Sent: Wednesday, December 05, 2007 8:02 AM > >>>> To: Turner, Sean P. > >>>> Cc: ietf-ltans@imc.org > >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >>>> > >>>> The problem with your suggested syntax is the definition of the our > >>>> constraints. If we used the RFC3280 AlgorithmIdentifier > >> structure, we > >>>> would integrate the constraints as follows: > >>>> > >>>> AlgorithmValidityInfo ::= SEQUENCE { > >>>> identifier AlgorithmIdentifier, > >>>> constraint CHOICE { > >>>> exact [0] OCTET STRING, > >>>> min [1] OCTET STRING, > >>>> max [2] OCTET STRING, > >>>> range [3] Range, > >>>> other [4] OtherConstraints > >>>> validity Validity OPTIONAL, > >>>> information Information OPTIONAL } > >>>> > >>>> It's not possible to determine constraints for more than one > >>>> parameter (e.g. p > 1024 and q > 160 in case of DSA). > >>>> Additionally defining ranges is impossible (e.g. modulus < > >>>> 2048 and modulus > 1024). > >>>> > >>>> > >>>> so & tk > >>>> > >>>> > >>>> Turner, Sean P. schrieb: > >>>>> I'm only commenting on the Parameter structure in the > >> ASN.1. I think > >>>>> that it might be better to change Algorithm to be a sequence of > >>>>> algorithmIdentifier, validity, and information - call it > >>>>> AlgorithmValidityInfo. I suggest this for two reasons: > >>>>> > >>>>> 1. The AlgorithmIdentifier structure that is used to assign an > >>>>> algorithm's object identifier also define the parameters. So it > >>>>> probably makes sense to reuse this structure. > >>>>> > >>>>> 2. The parameters structures for some of the newer > >>>> algorithms is quite > >>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs > >>>> [RFC3279] > >>>>> aren't just an OID they are nested structure. > >>>>> > >>>>> (not sure how to do it in XML) > >>>>> > >>>>> Replace: > >>>>> > >>>>> Algorithm ::= SEQUENCE { > >>>>> algorithmIdentifier AlgID, > >>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, > >>>>> validity [1] Validity, > >>>>> information [2] SEQUENCE OF UTF8String OPTIONAL > >>>>> } > >>>>> > >>>>> AlgID ::= SEQUENCE { > >>>>> name UTF8String, > >>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > >>>>> uri [1] SEQUENCE OF IA5String OPTIONAL > >>>>> } > >>>>> > >>>>> Parameter ::= SEQUENCE { > >>>>> name UTF8String, > >>>>> constraint CHOICE { > >>>>> exact [0] OCTET STRING, > >>>>> min [1] OCTET STRING, > >>>>> max [2] OCTET STRING, > >>>>> range [3] Range, > >>>>> other [4] OtherConstraints > >>>>> } > >>>>> } > >>>>> > >>>>> With: > >>>>> > >>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier > >>>>> AlgorithmIdentifier, > >>>>> validity Validity OPTIONAL, > >>>>> information Information OPTIONAL } > >>>>> > >>>>> Validity ::= SEQUENCE { > >>>>> start [0] GeneralizedTime OPTIONAL, > >>>>> end [1] GeneralizedTime OPTIONAL } > >>>>> > >>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > >>>>> > >>>>> -- From RFC3280 > >>>>> AlgorithmIdentifier ::= SEQUENCE { > >>>>> algorithm OBJECT IDENTIFIER, > >>>>> parameters ANY DEFINED BY algorithm OPTIONAL } > >>>>> -- contains a value of the type > >>>>> -- registered for use with the > >>>>> -- algorithm object > >> identifier value > >>>>> spt > >>>>> > >>>>> > >>> > > > > ------=_NextPart_000_004E_01C83B63.50B41780 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwzCCBhow ggQCoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZh cmlhMQ8wDQYDVQQHEwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5 MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20u b3JnMB4XDTA2MTEwMzAwMjA0OFoXDTA5MDczMDAwMjA0OFowgZExCzAJBgNVBAYTAkRFMRAwDgYD VQQIEwdCYXZhcmlhMR4wHAYDVQQKExVPcGVuIFRleHQgQ29ycG9yYXRpb24xETAPBgNVBAsTCFNl Y3VyaXR5MRcwFQYDVQQDEw5Ub2JpYXMgR29uZHJvbTEkMCIGCSqGSIb3DQEJARYVdGdvbmRyb21A b3BlbnRleHQuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA4dYGy7tHBES4+h3Z NS3dQi4TFm0TE84vyqzWPIwPZHpP927sRb3jh5PD7WChVPcb4KG8P4q2c+bJ+EVdaRv1Uvw57n3n uhAbXtb7kcnFPIMfYn92GOBZpHoDCgT8DRYuQHvScH8l4W9WDtc2NHLkIldIBybxHLVdXX3QJsk3 /OFmJ9shKangwS+AT25cgGj5Ltu9iB2CFCrIKn5CCWDvObwoxEsYPj84Z3ygKUEOijNfkISuKiby /xLIfjDPozpWdb2rb0Oi9pYJkjuzmzF5qwHZDFySeJoVKMIHi4n956m7Etahow+7hQk57+XwQyIL l+s62FlMzsyMCZZ6MlpTs+OrymeobB44ttUn6F370N9GNXg/eV388IYA8e9Mui5F459mrM/9ub9T fQmqoW+SdF4AvBi7BOWTHRJ/DrAWeBcw+9UeX3bWgX6cLNNv+SlNSKSiGV+syf5tqD4APvgfIY0a PPmRLsbUy1Urwfe+BjqOLXZe6w+4WFbbKbAdltpUQCK04eA+g5tIT1ZT8zOxH+EvlJFSoV+i4btp Y7Ni2AfJLvf9OdgwoOJBp3gXQL4o5VWzd362GHYjj94X0sqlJf8Ggcdxz4BR4/EsFRt6MQPXrfoi wPBku/q08YwXPe1hvaW4k8MVosddaka88UY8LJrtXkZWXRERyPMH+cIJNw0CAwEAAaN7MHkwCQYD VR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYD VR0OBBYEFDwj2KwaDOuWxUz/MiFFnt7sOYVoMB8GA1UdIwQYMBaAFH1WtHxZxnLGHnuMc6Pu+Gv9 BD5CMA0GCSqGSIb3DQEBBQUAA4ICAQCne6u3Ko8FefZSDqOq8pKEYAKbuV5NoGZqImoamelDm1Yd 6GQzacZF1aJyfHEytazk2GqmcGGB/yrqaFeQopiSTqGGnB7/8fgYMAUlv+S4NHJoohAVZC/onG0W PDtWKnOyARntV2UxWIikKZZaYKlinvAwaBnmguqboWgbKBpYiV1+U7TgHlYdd9W25k1D+0n+E1mN GvqEfPFxRHEiFdLxWuTtSZnvLDAihAEcTlcKOKGz5RIMHPxG4OcVz+acGKEi8WBHQRVx7KKUkLOy SprjUpxSnEi1AbOEK2y0T/Bao3UkkxQiqKC67OUK0GPbvwat18GLmvesHArtTI8SVty63qdEmxnB CKYLuSOJbXBe5SFPrcruMvumiA4QPdcGMyTiLqDtn97QcN+F5HfB93mKFZfqZwOqi86R6jgzFd3J HsujJXDpZ0tIFRcDespNBcUIV+A38JxHsxF7xHw5wVQMEEsMceMjqEB3X58yAssNnXKD0E7WjIoO SxlnODM++6xTBOIFB3N34ENNuj2Ck8196DUOei/YBEmI5oLIlXEKU/lHiDrq1D9TsjO7vhYoG+wC vAFpGAicl25AGhaOTVeXKh+pTvHHlYva62Stww8eB/fHOW6VASWiUddE4OoxZfQiRkpn91K0rJc4 WHsP9HsBVEdA8xrfN36UXb3SXURnRzCCBqEwggSJoAMCAQICCQCamHOHv2sJlzANBgkqhkiG9w0B AQUFADCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQ MA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25k cm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwHhcNMDYxMTAzMDAxMzMxWhcN MDkwNzMwMDAxMzMxWjCBkTELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcT Bk11bmljaDEQMA4GA1UEChMHR29uZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRv YmlhcyBHb25kcm9tMSEwHwYJKoZIhvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmcwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQDRNLo77UVeV/wQ+ml3Nb5XWzkYT4Q8zo7Sl7CkuCT7UE9g v8oFNJbzedTDn//SHkUKQJ3RpZf5VP/8gHvcFUVoiZjCMXYCsjlSJppouau3F0ED2wOle+nE9suX lOuZVSsyuFSF89Yff8oD+wzHWi/9naeHrgKMVeqKa0Pcu1+tJ/zAoeeZHXlxHAuLQbF8XY2RGG0l qSYXBwPuGqSVS9OKUP5kxLm+1Cd928h7PhwKJv9JP34YOWaQmxGL6KjkVnTacKpXPbhtqgtNsHC2 QWkmyyBAS8so5qAfIdOnlRi+U0hgwAKBiAF9OQh9g+xPoqLRmb81+Q18zjPDiIQ+KhwXfJeftUZp fRy8k3thtOnkTqfKHTTaM+KaWR1bRY9DKR5u+zd/6qZ3/snVqBCNAKM0hktcSt7zQUcDo+1RsdW7 H8uJp/avtmYrmt21+Fy5+sN23sGWKNI/E3agPlTr0/jALm17ZomMP7/J4FUHsrxt5Sh6d1bWlxcR xRIhU/8JU0BqbRSW1EKeBpzGnUJ3O65wHfyMrXi5aHG2gGXXoo2AiVTEUZylMsYxTCotEeZijfQN zDH6oCvzePh4LF/Qo9u7T16Ovu3tRhOPQGfWltwC9gs+eJn4j7T2HJSEzVNZ3XTStzu8i/yKCcQZ xWYy0j7ZXKZBSUmPyzuviSOvaU/K+QIDAQABo4H5MIH2MB0GA1UdDgQWBBR9VrR8WcZyxh57jHOj 7vhr/QQ+QjCBxgYDVR0jBIG+MIG7gBR9VrR8WcZyxh57jHOj7vhr/QQ+QqGBl6SBlDCBkTELMAkG A1UEBhMCREUxEDAOBgNVBAgTB0JhdmFyaWExDzANBgNVBAcTBk11bmljaDEQMA4GA1UEChMHR29u ZHJvbTERMA8GA1UECxMIU2VjdXJpdHkxFzAVBgNVBAMTDlRvYmlhcyBHb25kcm9tMSEwHwYJKoZI hvcNAQkBFhJ0b2JpYXNAZ29uZHJvbS5vcmeCCQCamHOHv2sJlzAMBgNVHRMEBTADAQH/MA0GCSqG SIb3DQEBBQUAA4ICAQAmu3wb0JFEPQLfb9PLVEfSldtE9sLdEM4dpiJe1XqvgiI3pQI/lBzKbqcR vg4fdP7muS3tcsqrI31L14+YzphrTLTWev86JdR23ir2oJCqrsHupuqYHI0egTRshejcTjnlBlmk OSfxidjl+7RYjFAquFQEqHPEBb4Tcf6jXFbKzSLp/TcVG9a9x05C8wEJjDbINWxxb4EwjanKcMbh ZNS8Vm0x4IwJhOYwkhx980WXruCoMKec9LwrPkAO/H/ZcpW2gR174oayrNXDYZIZ4nVU248jB52R rrZxCt6/TbC8ftMzcafOLxP933RWtnf79qJbZLV9YspUEzQbuPbrb4nNuK/ZdOgJ9rNtLgZKqoa2 l5j9pNW4+yAh10s2+ZAUOlPv5wICK5gIGJo1Lj1P6cNOp3Yh03mudwM4XhQYyRCg2GbUIj0xXv/e NkYfMGA5ljKmt9qnJ3qZKwgiFwMs2+nMfLDh6GuheAaCaWewHFMcgSoMYHNc43osufcygnKno3Eq Fn8sn9YWM7X5vCuFK7+TGoJRVzVuwmzDqSG3l908auEKLetv03frw5v9cCB0ttExvsITo60lkuK3 Vy4CBDvE2U6BvuEr682hIUirV/X6oVORu3h44fTm1t5aibqwdWI3EpENwg9956Qpbo7uATZtQeWp J6lsIPBAfc6YE6crOTGCBOEwggTdAgEBMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2 YXJpYTEPMA0GA1UEBxMGTXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0 eTEXMBUGA1UEAxMOVG9iaWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9t Lm9yZwIBATAJBgUrDgMCGgUAoIICHjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0wNzEyMTAxODMxNTJaMCMGCSqGSIb3DQEJBDEWBBTlnjovdahYxMDxC60L29jt3z9p bTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqAYJKwYB BAGCNxAEMYGaMIGXMIGRMQswCQYDVQQGEwJERTEQMA4GA1UECBMHQmF2YXJpYTEPMA0GA1UEBxMG TXVuaWNoMRAwDgYDVQQKEwdHb25kcm9tMREwDwYDVQQLEwhTZWN1cml0eTEXMBUGA1UEAxMOVG9i aWFzIEdvbmRyb20xITAfBgkqhkiG9w0BCQEWEnRvYmlhc0Bnb25kcm9tLm9yZwIBATCBqgYLKoZI hvcNAQkQAgsxgZqggZcwgZExCzAJBgNVBAYTAkRFMRAwDgYDVQQIEwdCYXZhcmlhMQ8wDQYDVQQH EwZNdW5pY2gxEDAOBgNVBAoTB0dvbmRyb20xETAPBgNVBAsTCFNlY3VyaXR5MRcwFQYDVQQDEw5U b2JpYXMgR29uZHJvbTEhMB8GCSqGSIb3DQEJARYSdG9iaWFzQGdvbmRyb20ub3JnAgEBMA0GCSqG SIb3DQEBAQUABIICAG07yM9s+YdrhUUnqtVezgWIXLw7m/66gbTJ/XrbrxuGK7ImbAVgSWfJ5fy6 B/V03ex7kQNLR0GTzSIfJn8JdP6kgBv2Ax8/+SpKYcWSHqmRhz2a1uaPd6EDEYodu7+W8w8TEOl6 /4fRRBDG4rmyXMGcIbgFEs3NsBi9EH0/A4uOu7MbH6wWYO+QWVNJ2ElnjpImZ3hT4ymvklEYLFbL pYo/dJH6FurYD7ZnAO840FDR4MkPjyYVL+zBnFupQQoBWLpr1+kpLHa348EVdsh2ZxIgphtGrZIz 1k5B0v0yRL2WKRHczYw61tKhxaz/YrcSvH3ya9p8SaNr0GE1Az4NBTNZ/fFCcwaP+BsTZvKHZen1 p86QFJWVxOPo6QzNKD9Zknu6yOlReE3g11/TeRI4qCVQlVkimGeSq1io6ufzyB2R2QENfzEu1lG5 rfrIqdFo1OPOonRGRwP4wTP8benZtifVubb7uxO/H7ioIJBkNiznnHiHmjDeI25nlop8YI/gCPBR JkcCD3zChLmcsYvl1dIKGIb/9vzgPOpVaCwZ/n0td/wcrGP/wKane9EhTviRsfsfAVaMjTXSkzi/ wIdeC+BUjrjqCPcIQqIzmKExcZcRXEIUC1hb55LQ4L7Y6Ta1ojHVJetgiGMaLjMKm3Yg/zm1LGqE pxQXZNF1KlObCDD+AAAAAAAA ------=_NextPart_000_004E_01C83B63.50B41780-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8NWHsK004351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Dec 2007 16:32:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB8NWHrt004350; Sat, 8 Dec 2007 16:32:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8NWGMd004343 for ; Sat, 8 Dec 2007 16:32:16 -0700 (MST) (envelope-from jwkckid1@ix.netcom.com) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=m0wy09eVbWRvVYdIYJ+0Jvt0Y+t6mc1QTZeKoD6dp7ibHwUc4pW7JuzlfEiwDqvB; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J199Z-00033i-Nn; Sat, 08 Dec 2007 18:32:13 -0500 Received: from 4.226.15.142 by webmail.pas.earthlink.net with HTTP; Sat, 8 Dec 2007 18:32:13 -0500 Message-ID: <24797949.1197156733684.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Sat, 8 Dec 2007 18:32:13 -0500 (EST) From: jwkckid1@ix.netcom.com Reply-To: jwkckid1@ix.netcom.com To: TS Glassey Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Cc: ietf-ltans@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688498c9a26aa0701920c3ad97b9eea82b4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Todd and all, I believe Todd has a very good and valid point here. A flat sequence seems very much less than sufficient. Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 -----Original Message----- >From: TS Glassey >Sent: Dec 8, 2007 9:43 AM >To: Thomas Kunz , "Turner, Sean P." >Cc: ietf-ltans@imc.org >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > >Maybe not from a control perspective but that is only half of the picture. >The key value of LTANS as a 'thing' is that is would need to meet both the >legal and emerging document management processes or else those parties who >are constrained by those frameworks will not be able to use it, nor will >those parties attached to the people so constrained. > >Todd Glassey > >----- Original Message ----- >From: "Thomas Kunz" >To: "Turner, Sean P." >Cc: >Sent: Friday, December 07, 2007 7:06 AM >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > >> We think, our flat sequence is sufficient. >> >> The goal of a policy is to specify a range for specific (safety-critical) >> parameters of an algorithm. Therefor it's not necessary to define all >> parameters. >> >> In the evaluations of BSI and NIST >> (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only >> one value is defined (namely q). By NIST a q_length of 160 is suitable >> until 2010. >> >> In this case, the XML structure would be: >> >> >> >> EC-DSA 160 >> ... >> >> 160 >> 2010-12-31 >> >> >> >> so & tk >> >> >> >> >> >> Turner, Sean P. schrieb: >>> Yes I did misunderstand. With algorithms like DSA where there are few >>> parameters your structure might work but for EC algorithms (I attached >>> some >>> of the ASN.1 for their parameters) I don't think the flat sequence of >>> will >>> work. >>> >>> ECParameters ::= CHOICE { >>> namedCurve CURVE.&id({NamedCurve}), >>> specifiedCuve SpecifiedCurve, >>> implicitCurve NULL >>> } >>> >>> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >>> WITH SYNTAX { ID &id } >>> >>> NamedCurve CURVE ::= { >>> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >>> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >>> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >>> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >>> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >>> ... -- Extensible >>> } >>> >>> SpecifiedCurve ::= SEQUENCE { >>> version SpecifiedCurveVersion >>> ( ecpVer1 | ecpVer2 | ecpVer3 ), >>> fieldID FieldID {{FieldTypes}}, >>> curve Curve, -- Curve E >>> base ECPoint, -- Base point P >>> order INTEGER, -- Order n of the base point >>> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >>> hash HashAlgorithm OPTIONAL, >>> ... -- Extensible >>> } >>> >>> SpecifiedCurveVersion ::= INTEGER { >>> ecpVer1(1), >>> ecpVer2(2), >>> ecpVer3(3), >>> ... -- Extensible >>> } >>> FIELD-ID ::= TYPE-IDENTIFIER >>> >>> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >>> FIELD-ID.&id({IOSet}), >>> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >>> } >>> >>> FieldTypes FIELD-ID ::= { >>> { Prime-p IDENTIFIED BY prime-field } | >>> { Characteristic-two IDENTIFIED BY characteristic-two-field } | >>> ... -- Extensible >>> } >>> >>> prime-field OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } >>> >>> Prime-p ::= INTEGER >>> >>> characteristic-two-field OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } >>> >>> Characteristic-two ::= SEQUENCE { >>> m INTEGER, -- Field size 2^m >>> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >>> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >>> } >>> >>> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >>> >>> BasisTypes CHARACTERISTIC-TWO ::= { >>> { NULL IDENTIFIED BY gnBasis } | >>> { Trinomial IDENTIFIED BY tpBasis } | >>> { Pentanomial IDENTIFIED BY ppBasis } | >>> ... -- Extensible >>> } >>> >>> gnBasis OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >>> characteristic-two-basis(2) 1 } >>> >>> tpBasis OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >>> characteristic-two-basis(2) 2 } >>> >>> Trinomial ::= INTEGER >>> >>> ppBasis OBJECT IDENTIFIER ::= { >>> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >>> characteristic-two-basis(2) 3 } >>> >>> Pentanomial ::= SEQUENCE { >>> k1 INTEGER, -- k1 > 0 >>> k2 INTEGER, -- k2 > k1 >>> k3 INTEGER -- k3 > k2 >>> } >>> >>> Curve ::= SEQUENCE { >>> a FieldElement, >>> b FieldElement, >>> seed BIT STRING OPTIONAL >>> -- Shall be present if used in SpecifiedCurve >>> -- with version of ecdpVer2 or ecdpVer3 >>> } >>> FieldElement ::= OCTET STRING >>> >>> ECPoint ::= OCTET STRING >>>> -----Original Message----- >>>> From: owner-ietf-ltans@mail.imc.org >>>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >>>> Sent: Thursday, December 06, 2007 4:52 AM >>>> To: Turner, Sean P. >>>> Cc: ietf-ltans@imc.org >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>> >>>> We think, You misunderstood our last post. >>>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show >>>> that we CANNOT use the AlgorithmIdentifier. >>>> >>>> The reason is, we cannot model the following cases: >>>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in >>>> case of DSA). >>>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >>>> >>>> The main problem is that AlgorithmIdentifier describes entirely one >>>> algorithm with all its parameters. Therefor it is not possible to set >>>> different constraints for the parameters. >>>> >>>> so & tk >>>> >>>> >>>> >>>> Turner, Sean P. schrieb: >>>>> This would work for me. >>>>> >>>>> spt >>>>> >>>>>> -----Original Message----- >>>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>>>>> Sent: Wednesday, December 05, 2007 8:02 AM >>>>>> To: Turner, Sean P. >>>>>> Cc: ietf-ltans@imc.org >>>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>>>> >>>>>> The problem with your suggested syntax is the definition of the our >>>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >>>> structure, we >>>>>> would integrate the constraints as follows: >>>>>> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { >>>>>> identifier AlgorithmIdentifier, >>>>>> constraint CHOICE { >>>>>> exact [0] OCTET STRING, >>>>>> min [1] OCTET STRING, >>>>>> max [2] OCTET STRING, >>>>>> range [3] Range, >>>>>> other [4] OtherConstraints >>>>>> validity Validity OPTIONAL, >>>>>> information Information OPTIONAL } >>>>>> >>>>>> It's not possible to determine constraints for more than one parameter >>>>>> (e.g. p > 1024 and q > 160 in case of DSA). >>>>>> Additionally defining ranges is impossible (e.g. modulus < >>>>>> 2048 and modulus > 1024). >>>>>> >>>>>> >>>>>> so & tk >>>>>> >>>>>> >>>>>> Turner, Sean P. schrieb: >>>>>>> I'm only commenting on the Parameter structure in the >>>> ASN.1. I think >>>>>>> that it might be better to change Algorithm to be a sequence of >>>>>>> algorithmIdentifier, validity, and information - call it >>>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>>>>> >>>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>>>>> algorithm's object identifier also define the parameters. So it >>>>>>> probably makes sense to reuse this structure. >>>>>>> >>>>>>> 2. The parameters structures for some of the newer >>>>>> algorithms is quite >>>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>>>>> [RFC3279] >>>>>>> aren't just an OID they are nested structure. >>>>>>> >>>>>>> (not sure how to do it in XML) >>>>>>> >>>>>>> Replace: >>>>>>> >>>>>>> Algorithm ::= SEQUENCE { >>>>>>> algorithmIdentifier AlgID, >>>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>>>>> validity [1] Validity, >>>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>>>>> } >>>>>>> >>>>>>> AlgID ::= SEQUENCE { >>>>>>> name UTF8String, >>>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>>>>> } >>>>>>> >>>>>>> Parameter ::= SEQUENCE { >>>>>>> name UTF8String, >>>>>>> constraint CHOICE { >>>>>>> exact [0] OCTET STRING, >>>>>>> min [1] OCTET STRING, >>>>>>> max [2] OCTET STRING, >>>>>>> range [3] Range, >>>>>>> other [4] OtherConstraints >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> With: >>>>>>> >>>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>>>>> AlgorithmIdentifier, >>>>>>> validity Validity OPTIONAL, >>>>>>> information Information OPTIONAL } >>>>>>> >>>>>>> Validity ::= SEQUENCE { >>>>>>> start [0] GeneralizedTime OPTIONAL, >>>>>>> end [1] GeneralizedTime OPTIONAL } >>>>>>> >>>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>>>>> >>>>>>> -- From RFC3280 >>>>>>> AlgorithmIdentifier ::= SEQUENCE { >>>>>>> algorithm OBJECT IDENTIFIER, >>>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>>>>> -- contains a value of the type >>>>>>> -- registered for use with the >>>>>>> -- algorithm object >>>> identifier value >>>>>>> spt >>>>>>> >>>>>>> >>>>> >>> >>> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FT1NE072305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Dec 2007 08:29:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB8FT19i072304; Sat, 8 Dec 2007 08:29:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB8FT09u072298 for ; Sat, 8 Dec 2007 08:29:00 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tG8kgxK8HTzsS3q1qAmX5pg3p3Z1cBGa7pclR+zGMYtff4FHuNAvKgU9RP3PJUpH; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J11bu-0000lb-6N; Sat, 08 Dec 2007 10:28:58 -0500 Message-ID: <002701c839af$0d1d4060$6401a8c0@tsg1> From: "TS Glassey" To: "Thomas Kunz" , "Turner, Sean P." Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> <4759615B.3000508@sit.fraunhofer.de> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt Date: Sat, 8 Dec 2007 06:43:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79615a5274e6de898cac121fcc226ed08c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Maybe not from a control perspective but that is only half of the picture. The key value of LTANS as a 'thing' is that is would need to meet both the legal and emerging document management processes or else those parties who are constrained by those frameworks will not be able to use it, nor will those parties attached to the people so constrained. Todd Glassey ----- Original Message ----- From: "Thomas Kunz" To: "Turner, Sean P." Cc: Sent: Friday, December 07, 2007 7:06 AM Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > We think, our flat sequence is sufficient. > > The goal of a policy is to specify a range for specific (safety-critical) > parameters of an algorithm. Therefor it's not necessary to define all > parameters. > > In the evaluations of BSI and NIST > (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only > one value is defined (namely q). By NIST a q_length of 160 is suitable > until 2010. > > In this case, the XML structure would be: > > > > EC-DSA 160 > ... > > 160 > 2010-12-31 > > > > so & tk > > > > > > Turner, Sean P. schrieb: >> Yes I did misunderstand. With algorithms like DSA where there are few >> parameters your structure might work but for EC algorithms (I attached >> some >> of the ASN.1 for their parameters) I don't think the flat sequence of >> will >> work. >> >> ECParameters ::= CHOICE { >> namedCurve CURVE.&id({NamedCurve}), >> specifiedCuve SpecifiedCurve, >> implicitCurve NULL >> } >> >> CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } >> WITH SYNTAX { ID &id } >> >> NamedCurve CURVE ::= { >> { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | >> { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | >> { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | >> { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | >> { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | >> ... -- Extensible >> } >> >> SpecifiedCurve ::= SEQUENCE { >> version SpecifiedCurveVersion >> ( ecpVer1 | ecpVer2 | ecpVer3 ), >> fieldID FieldID {{FieldTypes}}, >> curve Curve, -- Curve E >> base ECPoint, -- Base point P >> order INTEGER, -- Order n of the base point >> cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n >> hash HashAlgorithm OPTIONAL, >> ... -- Extensible >> } >> >> SpecifiedCurveVersion ::= INTEGER { >> ecpVer1(1), >> ecpVer2(2), >> ecpVer3(3), >> ... -- Extensible >> } >> FIELD-ID ::= TYPE-IDENTIFIER >> >> FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType >> FIELD-ID.&id({IOSet}), >> parameters FIELD-ID.&Type({IOSet}{@fieldType}) >> } >> >> FieldTypes FIELD-ID ::= { >> { Prime-p IDENTIFIED BY prime-field } | >> { Characteristic-two IDENTIFIED BY characteristic-two-field } | >> ... -- Extensible >> } >> >> prime-field OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } >> >> Prime-p ::= INTEGER >> >> characteristic-two-field OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } >> >> Characteristic-two ::= SEQUENCE { >> m INTEGER, -- Field size 2^m >> basis CHARACTERISTIC-TWO.&id({BasisTypes}), >> parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) >> } >> >> CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER >> >> BasisTypes CHARACTERISTIC-TWO ::= { >> { NULL IDENTIFIED BY gnBasis } | >> { Trinomial IDENTIFIED BY tpBasis } | >> { Pentanomial IDENTIFIED BY ppBasis } | >> ... -- Extensible >> } >> >> gnBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 1 } >> >> tpBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 2 } >> >> Trinomial ::= INTEGER >> >> ppBasis OBJECT IDENTIFIER ::= { >> iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) >> characteristic-two-basis(2) 3 } >> >> Pentanomial ::= SEQUENCE { >> k1 INTEGER, -- k1 > 0 >> k2 INTEGER, -- k2 > k1 >> k3 INTEGER -- k3 > k2 >> } >> >> Curve ::= SEQUENCE { >> a FieldElement, >> b FieldElement, >> seed BIT STRING OPTIONAL >> -- Shall be present if used in SpecifiedCurve >> -- with version of ecdpVer2 or ecdpVer3 >> } >> FieldElement ::= OCTET STRING >> >> ECPoint ::= OCTET STRING >>> -----Original Message----- >>> From: owner-ietf-ltans@mail.imc.org >>> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >>> Sent: Thursday, December 06, 2007 4:52 AM >>> To: Turner, Sean P. >>> Cc: ietf-ltans@imc.org >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>> >>> We think, You misunderstood our last post. >>> With the mentioned structure (AlgorithmValidityInfo) we wanted to show >>> that we CANNOT use the AlgorithmIdentifier. >>> >>> The reason is, we cannot model the following cases: >>> 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in >>> case of DSA). >>> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >>> >>> The main problem is that AlgorithmIdentifier describes entirely one >>> algorithm with all its parameters. Therefor it is not possible to set >>> different constraints for the parameters. >>> >>> so & tk >>> >>> >>> >>> Turner, Sean P. schrieb: >>>> This would work for me. >>>> >>>> spt >>>> >>>>> -----Original Message----- >>>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>>>> Sent: Wednesday, December 05, 2007 8:02 AM >>>>> To: Turner, Sean P. >>>>> Cc: ietf-ltans@imc.org >>>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>>> >>>>> The problem with your suggested syntax is the definition of the our >>>>> constraints. If we used the RFC3280 AlgorithmIdentifier >>> structure, we >>>>> would integrate the constraints as follows: >>>>> >>>>> AlgorithmValidityInfo ::= SEQUENCE { >>>>> identifier AlgorithmIdentifier, >>>>> constraint CHOICE { >>>>> exact [0] OCTET STRING, >>>>> min [1] OCTET STRING, >>>>> max [2] OCTET STRING, >>>>> range [3] Range, >>>>> other [4] OtherConstraints >>>>> validity Validity OPTIONAL, >>>>> information Information OPTIONAL } >>>>> >>>>> It's not possible to determine constraints for more than one parameter >>>>> (e.g. p > 1024 and q > 160 in case of DSA). >>>>> Additionally defining ranges is impossible (e.g. modulus < >>>>> 2048 and modulus > 1024). >>>>> >>>>> >>>>> so & tk >>>>> >>>>> >>>>> Turner, Sean P. schrieb: >>>>>> I'm only commenting on the Parameter structure in the >>> ASN.1. I think >>>>>> that it might be better to change Algorithm to be a sequence of >>>>>> algorithmIdentifier, validity, and information - call it >>>>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>>>> >>>>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>>>> algorithm's object identifier also define the parameters. So it >>>>>> probably makes sense to reuse this structure. >>>>>> >>>>>> 2. The parameters structures for some of the newer >>>>> algorithms is quite >>>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>>>> [RFC3279] >>>>>> aren't just an OID they are nested structure. >>>>>> >>>>>> (not sure how to do it in XML) >>>>>> >>>>>> Replace: >>>>>> >>>>>> Algorithm ::= SEQUENCE { >>>>>> algorithmIdentifier AlgID, >>>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>>>> validity [1] Validity, >>>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>>>> } >>>>>> >>>>>> AlgID ::= SEQUENCE { >>>>>> name UTF8String, >>>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>>>> } >>>>>> >>>>>> Parameter ::= SEQUENCE { >>>>>> name UTF8String, >>>>>> constraint CHOICE { >>>>>> exact [0] OCTET STRING, >>>>>> min [1] OCTET STRING, >>>>>> max [2] OCTET STRING, >>>>>> range [3] Range, >>>>>> other [4] OtherConstraints >>>>>> } >>>>>> } >>>>>> >>>>>> With: >>>>>> >>>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>>>> AlgorithmIdentifier, >>>>>> validity Validity OPTIONAL, >>>>>> information Information OPTIONAL } >>>>>> >>>>>> Validity ::= SEQUENCE { >>>>>> start [0] GeneralizedTime OPTIONAL, >>>>>> end [1] GeneralizedTime OPTIONAL } >>>>>> >>>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>>>> >>>>>> -- From RFC3280 >>>>>> AlgorithmIdentifier ::= SEQUENCE { >>>>>> algorithm OBJECT IDENTIFIER, >>>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>>>> -- contains a value of the type >>>>>> -- registered for use with the >>>>>> -- algorithm object >>> identifier value >>>>>> spt >>>>>> >>>>>> >>>> >> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7F6HHa069200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2007 08:06:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB7F6HdJ069199; Fri, 7 Dec 2007 08:06:17 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB7F6Ba5069188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Dec 2007 08:06:14 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.89.208] (sitp1_72.sit.fraunhofer.de [141.12.68.72]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id lB7F68oT008883; Fri, 7 Dec 2007 16:06:08 +0100 Message-ID: <4759615B.3000508@sit.fraunhofer.de> Date: Fri, 07 Dec 2007 16:06:03 +0100 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Turner, Sean P." CC: ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> <00e601c8382d$560103d0$e8f9a8c0@Wylie> In-Reply-To: <00e601c8382d$560103d0$e8f9a8c0@Wylie> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010203000101070907090001" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms010203000101070907090001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We think, our flat sequence is sufficient. The goal of a policy is to specify a range for specific (safety-critical) parameters of an algorithm. Therefor it's not necessary to define all parameters. In the evaluations of BSI and NIST (e.g.: http://www.keylength.com/en/4/) for elliptic curve algorithms only one value is defined (namely q). By NIST a q_length of 160 is suitable until 2010. In this case, the XML structure would be: EC-DSA 160 ... 160 2010-12-31 so & tk Turner, Sean P. schrieb: > Yes I did misunderstand. With algorithms like DSA where there are few > parameters your structure might work but for EC algorithms (I attached some > of the ASN.1 for their parameters) I don't think the flat sequence of will > work. > > ECParameters ::= CHOICE { > namedCurve CURVE.&id({NamedCurve}), > specifiedCuve SpecifiedCurve, > implicitCurve NULL > } > > CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } > WITH SYNTAX { ID &id } > > NamedCurve CURVE ::= { > { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | > { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | > { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | > { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | > { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | > ... -- Extensible > } > > SpecifiedCurve ::= SEQUENCE { > version SpecifiedCurveVersion > ( ecpVer1 | ecpVer2 | ecpVer3 ), > fieldID FieldID {{FieldTypes}}, > curve Curve, -- Curve E > base ECPoint, -- Base point P > order INTEGER, -- Order n of the base point > cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n > hash HashAlgorithm OPTIONAL, > ... -- Extensible > } > > SpecifiedCurveVersion ::= INTEGER { > ecpVer1(1), > ecpVer2(2), > ecpVer3(3), > ... -- Extensible > } > FIELD-ID ::= TYPE-IDENTIFIER > > FieldID { FIELD-ID:IOSet } ::= SEQUENCE { > fieldType FIELD-ID.&id({IOSet}), > parameters FIELD-ID.&Type({IOSet}{@fieldType}) > } > > FieldTypes FIELD-ID ::= { > { Prime-p IDENTIFIED BY prime-field } | > { Characteristic-two IDENTIFIED BY characteristic-two-field } | > ... -- Extensible > } > > prime-field OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } > > Prime-p ::= INTEGER > > characteristic-two-field OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } > > Characteristic-two ::= SEQUENCE { > m INTEGER, -- Field size 2^m > basis CHARACTERISTIC-TWO.&id({BasisTypes}), > parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) > } > > CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER > > BasisTypes CHARACTERISTIC-TWO ::= { > { NULL IDENTIFIED BY gnBasis } | > { Trinomial IDENTIFIED BY tpBasis } | > { Pentanomial IDENTIFIED BY ppBasis } | > ... -- Extensible > } > > gnBasis OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > characteristic-two-basis(2) 1 } > > tpBasis OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > characteristic-two-basis(2) 2 } > > Trinomial ::= INTEGER > > ppBasis OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) > characteristic-two-basis(2) 3 } > > Pentanomial ::= SEQUENCE { > k1 INTEGER, -- k1 > 0 > k2 INTEGER, -- k2 > k1 > k3 INTEGER -- k3 > k2 > } > > Curve ::= SEQUENCE { > a FieldElement, > b FieldElement, > seed BIT STRING OPTIONAL > -- Shall be present if used in SpecifiedCurve > -- with version of ecdpVer2 or ecdpVer3 > } > FieldElement ::= OCTET STRING > > ECPoint ::= OCTET STRING > >> -----Original Message----- >> From: owner-ietf-ltans@mail.imc.org >> [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >> Sent: Thursday, December 06, 2007 4:52 AM >> To: Turner, Sean P. >> Cc: ietf-ltans@imc.org >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >> We think, You misunderstood our last post. >> With the mentioned structure (AlgorithmValidityInfo) we wanted >> to show that we CANNOT use the AlgorithmIdentifier. >> >> The reason is, we cannot model the following cases: >> 1. constraints for more than one parameter (e.g. p > 1024 and >> q > 160 in case of DSA). >> 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) >> >> The main problem is that AlgorithmIdentifier describes >> entirely one algorithm with all its parameters. Therefor it is >> not possible to set different constraints for the parameters. >> >> so & tk >> >> >> >> Turner, Sean P. schrieb: >>> This would work for me. >>> >>> spt >>> >>>> -----Original Message----- >>>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>>> Sent: Wednesday, December 05, 2007 8:02 AM >>>> To: Turner, Sean P. >>>> Cc: ietf-ltans@imc.org >>>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>>> >>>> The problem with your suggested syntax is the definition of the our >>>> constraints. If we used the RFC3280 AlgorithmIdentifier >> structure, we >>>> would integrate the constraints as follows: >>>> >>>> AlgorithmValidityInfo ::= SEQUENCE { >>>> identifier AlgorithmIdentifier, >>>> constraint CHOICE { >>>> exact [0] OCTET STRING, >>>> min [1] OCTET STRING, >>>> max [2] OCTET STRING, >>>> range [3] Range, >>>> other [4] OtherConstraints >>>> validity Validity OPTIONAL, >>>> information Information OPTIONAL } >>>> >>>> It's not possible to determine constraints for more than one >>>> parameter (e.g. p > 1024 and q > 160 in case of DSA). >>>> Additionally defining ranges is impossible (e.g. modulus < >>>> 2048 and modulus > 1024). >>>> >>>> >>>> so & tk >>>> >>>> >>>> Turner, Sean P. schrieb: >>>>> I'm only commenting on the Parameter structure in the >> ASN.1. I think >>>>> that it might be better to change Algorithm to be a sequence of >>>>> algorithmIdentifier, validity, and information - call it >>>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>>> >>>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>>> algorithm's object identifier also define the parameters. So it >>>>> probably makes sense to reuse this structure. >>>>> >>>>> 2. The parameters structures for some of the newer >>>> algorithms is quite >>>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>>> [RFC3279] >>>>> aren't just an OID they are nested structure. >>>>> >>>>> (not sure how to do it in XML) >>>>> >>>>> Replace: >>>>> >>>>> Algorithm ::= SEQUENCE { >>>>> algorithmIdentifier AlgID, >>>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>>> validity [1] Validity, >>>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>>> } >>>>> >>>>> AlgID ::= SEQUENCE { >>>>> name UTF8String, >>>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>>> } >>>>> >>>>> Parameter ::= SEQUENCE { >>>>> name UTF8String, >>>>> constraint CHOICE { >>>>> exact [0] OCTET STRING, >>>>> min [1] OCTET STRING, >>>>> max [2] OCTET STRING, >>>>> range [3] Range, >>>>> other [4] OtherConstraints >>>>> } >>>>> } >>>>> >>>>> With: >>>>> >>>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>>> AlgorithmIdentifier, >>>>> validity Validity OPTIONAL, >>>>> information Information OPTIONAL } >>>>> >>>>> Validity ::= SEQUENCE { >>>>> start [0] GeneralizedTime OPTIONAL, >>>>> end [1] GeneralizedTime OPTIONAL } >>>>> >>>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>>> >>>>> -- From RFC3280 >>>>> AlgorithmIdentifier ::= SEQUENCE { >>>>> algorithm OBJECT IDENTIFIER, >>>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>>> -- contains a value of the type >>>>> -- registered for use with the >>>>> -- algorithm object >> identifier value >>>>> spt >>>>> >>>>> >>> > > --------------ms010203000101070907090001 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9 6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47 IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN +6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh 6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1 bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6 DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMDcxNTA2MDNaMCMGCSqGSIb3 DQEJBDEWBBT/XF1wW+cgTWKlTbWni+nYPEmhkTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAIAp1PTSg7UmnDno2JL/vKIizyn31bRgX2BcT0pwPaV8AYdFDlEZ94ii hsc8B2wWsHeLpFAnsLvidHWo1L56MoK71DjKypCEWdOeqmxZPwZeMsn5z/HInX4vcYzP1opI H+OalEaHKvlF0dyTvv3bNH8M4Jzsl5vIgJ/wOOcCzlkF8AG25tBGgBuHb7W5U62QGddoJ3Cy 8OkW34qchPJnP1GFWh/KdcCwS6/bFlCR8Z0QU2924PrljYEgPuQCIV/gOVTOOpjOkLiWMBDA DPu19k4UGbENep9wUNhMejpL4EwQxzbbmTIqf4Nt+oKXnsuwfnbL3wpNPgGrjlsrqHgHsvgA AAAAAAA= --------------ms010203000101070907090001-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6HWARY059510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2007 10:32:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6HWAk2059509; Thu, 6 Dec 2007 10:32:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp109.biz.mail.re2.yahoo.com (smtp109.biz.mail.re2.yahoo.com [206.190.53.8]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB6HW8Jq059501 for ; Thu, 6 Dec 2007 10:32:09 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 54193 invoked from network); 6 Dec 2007 17:32:08 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@216.18.3.1 with login) by smtp109.biz.mail.re2.yahoo.com with SMTP; 6 Dec 2007 17:32:07 -0000 X-YMail-OSG: cOVgrfwVM1mZhXMM3cyftIrz5S2Hep2iOpEmNk6rQkS3XvfhTOI.6xDVfFj7kCDxBk8jC10_nvV_00yMKlPO9qGn7edKp2QAM1y8eowMTJZBM3KlDpEoaQ-- From: "Turner, Sean P." To: "'Thomas Kunz'" Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> <4757F05F.6080604@sit.fraunhofer.de> Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Thu, 6 Dec 2007 09:27:53 -0800 Organization: IECA, Inc. Message-ID: <00e601c8382d$560103d0$e8f9a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg4CH0cbP0CPmbjT7yyMmAM0/thrwAJBj/A In-Reply-To: <4757F05F.6080604@sit.fraunhofer.de> Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes I did misunderstand. With algorithms like DSA where there are few parameters your structure might work but for EC algorithms (I attached some of the ASN.1 for their parameters) I don't think the flat sequence of will work. ECParameters ::= CHOICE { namedCurve CURVE.&id({NamedCurve}), specifiedCuve SpecifiedCurve, implicitCurve NULL } CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { ID &id } NamedCurve CURVE ::= { { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | ... -- Extensible } SpecifiedCurve ::= SEQUENCE { version SpecifiedCurveVersion ( ecpVer1 | ecpVer2 | ecpVer3 ), fieldID FieldID {{FieldTypes}}, curve Curve, -- Curve E base ECPoint, -- Base point P order INTEGER, -- Order n of the base point cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n hash HashAlgorithm OPTIONAL, ... -- Extensible } SpecifiedCurveVersion ::= INTEGER { ecpVer1(1), ecpVer2(2), ecpVer3(3), ... -- Extensible } FIELD-ID ::= TYPE-IDENTIFIER FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType FIELD-ID.&id({IOSet}), parameters FIELD-ID.&Type({IOSet}{@fieldType}) } FieldTypes FIELD-ID ::= { { Prime-p IDENTIFIED BY prime-field } | { Characteristic-two IDENTIFIED BY characteristic-two-field } | ... -- Extensible } prime-field OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } Prime-p ::= INTEGER characteristic-two-field OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } Characteristic-two ::= SEQUENCE { m INTEGER, -- Field size 2^m basis CHARACTERISTIC-TWO.&id({BasisTypes}), parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) } CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER BasisTypes CHARACTERISTIC-TWO ::= { { NULL IDENTIFIED BY gnBasis } | { Trinomial IDENTIFIED BY tpBasis } | { Pentanomial IDENTIFIED BY ppBasis } | ... -- Extensible } gnBasis OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) 1 } tpBasis OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) 2 } Trinomial ::= INTEGER ppBasis OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) 3 } Pentanomial ::= SEQUENCE { k1 INTEGER, -- k1 > 0 k2 INTEGER, -- k2 > k1 k3 INTEGER -- k3 > k2 } Curve ::= SEQUENCE { a FieldElement, b FieldElement, seed BIT STRING OPTIONAL -- Shall be present if used in SpecifiedCurve -- with version of ecdpVer2 or ecdpVer3 } FieldElement ::= OCTET STRING ECPoint ::= OCTET STRING >-----Original Message----- >From: owner-ietf-ltans@mail.imc.org >[mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz >Sent: Thursday, December 06, 2007 4:52 AM >To: Turner, Sean P. >Cc: ietf-ltans@imc.org >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >We think, You misunderstood our last post. >With the mentioned structure (AlgorithmValidityInfo) we wanted >to show that we CANNOT use the AlgorithmIdentifier. > >The reason is, we cannot model the following cases: >1. constraints for more than one parameter (e.g. p > 1024 and >q > 160 in case of DSA). >2. defining ranges is impossible (e.g. 1024 < modulus < 2048) > >The main problem is that AlgorithmIdentifier describes >entirely one algorithm with all its parameters. Therefor it is >not possible to set different constraints for the parameters. > >so & tk > > > >Turner, Sean P. schrieb: >> This would work for me. >> >> spt >> >>> -----Original Message----- >>> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >>> Sent: Wednesday, December 05, 2007 8:02 AM >>> To: Turner, Sean P. >>> Cc: ietf-ltans@imc.org >>> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >>> >>> The problem with your suggested syntax is the definition of the our >>> constraints. If we used the RFC3280 AlgorithmIdentifier >structure, we >>> would integrate the constraints as follows: >>> >>> AlgorithmValidityInfo ::= SEQUENCE { >>> identifier AlgorithmIdentifier, >>> constraint CHOICE { >>> exact [0] OCTET STRING, >>> min [1] OCTET STRING, >>> max [2] OCTET STRING, >>> range [3] Range, >>> other [4] OtherConstraints >>> validity Validity OPTIONAL, >>> information Information OPTIONAL } >>> >>> It's not possible to determine constraints for more than one >>> parameter (e.g. p > 1024 and q > 160 in case of DSA). >>> Additionally defining ranges is impossible (e.g. modulus < >>> 2048 and modulus > 1024). >>> >>> >>> so & tk >>> >>> >>> Turner, Sean P. schrieb: >>>> I'm only commenting on the Parameter structure in the >ASN.1. I think >>>> that it might be better to change Algorithm to be a sequence of >>>> algorithmIdentifier, validity, and information - call it >>>> AlgorithmValidityInfo. I suggest this for two reasons: >>>> >>>> 1. The AlgorithmIdentifier structure that is used to assign an >>>> algorithm's object identifier also define the parameters. So it >>>> probably makes sense to reuse this structure. >>>> >>>> 2. The parameters structures for some of the newer >>> algorithms is quite >>>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >>> [RFC3279] >>>> aren't just an OID they are nested structure. >>>> >>>> (not sure how to do it in XML) >>>> >>>> Replace: >>>> >>>> Algorithm ::= SEQUENCE { >>>> algorithmIdentifier AlgID, >>>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>>> validity [1] Validity, >>>> information [2] SEQUENCE OF UTF8String OPTIONAL >>>> } >>>> >>>> AlgID ::= SEQUENCE { >>>> name UTF8String, >>>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>>> uri [1] SEQUENCE OF IA5String OPTIONAL >>>> } >>>> >>>> Parameter ::= SEQUENCE { >>>> name UTF8String, >>>> constraint CHOICE { >>>> exact [0] OCTET STRING, >>>> min [1] OCTET STRING, >>>> max [2] OCTET STRING, >>>> range [3] Range, >>>> other [4] OtherConstraints >>>> } >>>> } >>>> >>>> With: >>>> >>>> AlgorithmValidityInfo ::= SEQUENCE { identifier >>>> AlgorithmIdentifier, >>>> validity Validity OPTIONAL, >>>> information Information OPTIONAL } >>>> >>>> Validity ::= SEQUENCE { >>>> start [0] GeneralizedTime OPTIONAL, >>>> end [1] GeneralizedTime OPTIONAL } >>>> >>>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>>> >>>> -- From RFC3280 >>>> AlgorithmIdentifier ::= SEQUENCE { >>>> algorithm OBJECT IDENTIFIER, >>>> parameters ANY DEFINED BY algorithm OPTIONAL } >>>> -- contains a value of the type >>>> -- registered for use with the >>>> -- algorithm object >identifier value >>>> >>>> spt >>>> >>>> >> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6Cq1Nh032204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2007 05:52:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB6Cq1Vs032203; Thu, 6 Dec 2007 05:52:01 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB6Cpvb0032190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Dec 2007 05:51:59 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.89.208] (sitp2_133.sit.fraunhofer.de [141.12.69.133]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id lB6CpmUO022197; Thu, 6 Dec 2007 13:51:48 +0100 Message-ID: <4757F05F.6080604@sit.fraunhofer.de> Date: Thu, 06 Dec 2007 13:51:43 +0100 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Turner, Sean P." CC: ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> In-Reply-To: <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020703090304090908030601" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms020703090304090908030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We think, You misunderstood our last post. With the mentioned structure (AlgorithmValidityInfo) we wanted to show that we CANNOT use the AlgorithmIdentifier. The reason is, we cannot model the following cases: 1. constraints for more than one parameter (e.g. p > 1024 and q > 160 in case of DSA). 2. defining ranges is impossible (e.g. 1024 < modulus < 2048) The main problem is that AlgorithmIdentifier describes entirely one algorithm with all its parameters. Therefor it is not possible to set different constraints for the parameters. so & tk Turner, Sean P. schrieb: > This would work for me. > > spt > >> -----Original Message----- >> From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >> Sent: Wednesday, December 05, 2007 8:02 AM >> To: Turner, Sean P. >> Cc: ietf-ltans@imc.org >> Subject: Re: comment on draft-ietf-ltans-dssc-01.txt >> >> The problem with your suggested syntax is the definition of >> the our constraints. If we used the RFC3280 >> AlgorithmIdentifier structure, we would integrate the >> constraints as follows: >> >> AlgorithmValidityInfo ::= SEQUENCE { >> identifier AlgorithmIdentifier, >> constraint CHOICE { >> exact [0] OCTET STRING, >> min [1] OCTET STRING, >> max [2] OCTET STRING, >> range [3] Range, >> other [4] OtherConstraints >> validity Validity OPTIONAL, >> information Information OPTIONAL } >> >> It's not possible to determine constraints for more than one >> parameter (e.g. p > 1024 and q > 160 in case of DSA). >> Additionally defining ranges is impossible (e.g. modulus < >> 2048 and modulus > 1024). >> >> >> so & tk >> >> >> Turner, Sean P. schrieb: >>> I'm only commenting on the Parameter structure in the ASN.1. I think >>> that it might be better to change Algorithm to be a sequence of >>> algorithmIdentifier, validity, and information - call it >>> AlgorithmValidityInfo. I suggest this for two reasons: >>> >>> 1. The AlgorithmIdentifier structure that is used to assign an >>> algorithm's object identifier also define the parameters. So it >>> probably makes sense to reuse this structure. >>> >>> 2. The parameters structures for some of the newer >> algorithms is quite >>> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >> [RFC3279] >>> aren't just an OID they are nested structure. >>> >>> (not sure how to do it in XML) >>> >>> Replace: >>> >>> Algorithm ::= SEQUENCE { >>> algorithmIdentifier AlgID, >>> parameters [0] SEQUENCE OF Parameter OPTIONAL, >>> validity [1] Validity, >>> information [2] SEQUENCE OF UTF8String OPTIONAL >>> } >>> >>> AlgID ::= SEQUENCE { >>> name UTF8String, >>> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >>> uri [1] SEQUENCE OF IA5String OPTIONAL >>> } >>> >>> Parameter ::= SEQUENCE { >>> name UTF8String, >>> constraint CHOICE { >>> exact [0] OCTET STRING, >>> min [1] OCTET STRING, >>> max [2] OCTET STRING, >>> range [3] Range, >>> other [4] OtherConstraints >>> } >>> } >>> >>> With: >>> >>> AlgorithmValidityInfo ::= SEQUENCE { >>> identifier AlgorithmIdentifier, >>> validity Validity OPTIONAL, >>> information Information OPTIONAL } >>> >>> Validity ::= SEQUENCE { >>> start [0] GeneralizedTime OPTIONAL, >>> end [1] GeneralizedTime OPTIONAL } >>> >>> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >>> >>> -- From RFC3280 >>> AlgorithmIdentifier ::= SEQUENCE { >>> algorithm OBJECT IDENTIFIER, >>> parameters ANY DEFINED BY algorithm OPTIONAL } >>> -- contains a value of the type >>> -- registered for use with the >>> -- algorithm object identifier value >>> >>> spt >>> >>> > > --------------ms020703090304090908030601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9 6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47 IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN +6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh 6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1 bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6 DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMDYxMjUxNDNaMCMGCSqGSIb3 DQEJBDEWBBR49lOjDD4NDSMsr8w1cf5CRq6rnDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAHdXrgpUwdZJSPbIeb+LPyH/W82zqbymqfxqxw91bLSg/wE9zq7IvJZK aghNA86rnvrpWwLtsj3ZOK/yhRx4hjdTbyC3q12lIU58Yf1EkuGciRfY60Cs4suJ0BtMLk7P 27BIWF6xj31D5cLdTTjxYqa5olvQbuVguLP1+GF12OEouWRb+ikMAsa/ON3KaLkL9GhoHQuu wsHcB5KoRIa3BwlrsY0n2ivMLpxOxx3M4h9o45j/wVkzrl6C5rpDRT7y3HNzqtM1ZFoOHxCR CPHwak5wirp7dYrt1S6EHPzwRJyb0ny3ArwMw5hPhFvryi+DHjOq8v0P7a8ZgR+dT0xAU5MA AAAAAAA= --------------ms020703090304090908030601-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5NJtRr073786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 16:19:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5NJtKl073785; Wed, 5 Dec 2007 16:19:55 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5NJrxj073775 for ; Wed, 5 Dec 2007 16:19:53 -0700 (MST) (envelope-from tglassey@earthlink.net) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=geXWlKNPgjxKImDAyku8E5WrKud4U4CIuQJiFHX9XgsWU6a8ORgsnRAoElthYeU9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.125.79.23] (helo=gw) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J03Wy-0007ZF-OF; Wed, 05 Dec 2007 18:19:52 -0500 Message-ID: <00c001c83795$5ec4f500$174f7d40@home.glassey.com> From: "todd glassey" To: "Tobias Gondrom" , References: <2666EB2A846BAC4BB2D7F593301A786801F19FF9@MUCXGC2.opentext.net> Subject: Re: closing of WG LC for ERS/SCVP next week on Dec-11 Date: Wed, 5 Dec 2007 15:20:03 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BD_01C83752.4F3C3190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c45d0e1ee808f30990c65cf0ff9ecdf1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00BD_01C83752.4F3C3190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable closing of WG LC for ERS/SCVP next week on Dec-11Tobias, the problem is = that here in the US there are new and very formal hurdles for Long Term = Document Storage and these are per the US Court Standard set in a case = called "Lorraine v. Markel", and these now constrain the use of any = "electronic media" storage technology, and whether ANY of us like this = or not, this standard is IN FORCE and will be in force for the = foreseeable future making the design of a protocol to support long term = document archiving a key piece of any and all such public companies = operations.=20 The reality here is that LTANS was given a guarantee on its deployment = if it will embrace and meet these standards, and if not the adoption of = LTANS will become a pariah in my opinion since company's will not be = able to rely on protocols which do not allow them to meet their new = digital evidence needs. It is for that reason I suggest adding another I-D on Digital Evidence = Compliance to the WG's Deliverables. I will be filing a prototype for this if the WG is interested sometime = early next week but I want to know up front that this is not a wasted = effort as I am pretty busy now. Todd Glassey CISM CIFI CTO Wireless-Time.COM ----- Original Message -----=20 From: Tobias Gondrom=20 To: ietf-ltans@imc.org=20 Sent: Wednesday, December 05, 2007 1:56 PM Subject: closing of WG LC for ERS/SCVP next week on Dec-11 Hello all, just a last reminder: I initiated WG LC on ERS/SCVP = (draft-ietf-ltans-ers-scvp) several weeks ago.=20 Carl included the feedback he received during LC (mostly editorial = changes and one minor change of bit-on-the-wire)) in the revisions 04 = and 05.=20 As discussed yesterday at the meeting, I feel the draft is in good = shape and will close WG LC for this document next week (Dec-11) and = proceed it to AD/IESG review and IETF LC. So if you have any last = comments or discusses for the ERS/SCVP, please submit them until this = deadline.=20 .=20 Greetings, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler This email is protected by domestic and international copyright laws = and treaties and is the property of Open Text Corporation, it may = contain confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------=_NextPart_000_00BD_01C83752.4F3C3190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable closing of WG LC for ERS/SCVP next week on = Dec-11
Tobias, the problem is that = here in the=20 US there are new and very formal hurdles for Long Term Document Storage = and=20 these are per the US Court Standard set in a case called "Lorraine v. = Markel",=20 and these now constrain the use of any "electronic media" storage = technology,=20 and whether ANY of us like this or not, this standard is IN FORCE and = will be in=20 force for the foreseeable future making the design of a protocol to = support long=20 term document archiving a key piece of any and all such public companies = operations.
 
The reality here is that = LTANS was=20 given a guarantee on its deployment if it will embrace and meet these = standards,=20 and if not the adoption of LTANS will become a pariah in my opinion = since=20 company's will not be able to rely on protocols which do not allow them = to meet=20 their new digital evidence needs.

It is for that reason I suggest adding another I-D on Digital = Evidence=20 Compliance to the WG's Deliverables.
 
I will be filing a prototype for this if the WG is interested = sometime=20 early next week but I want to know up front that this is not a wasted = effort as=20 I am pretty busy now.

Todd Glassey CISM CIFI
CTO Wireless-Time.COM
----- Original Message -----
From:=20 Tobias=20 Gondrom
Sent: Wednesday, December 05, = 2007 1:56=20 PM
Subject: closing of WG LC for = ERS/SCVP=20 next week on Dec-11

Hello=20 all,

just a = last=20 reminder: I = initiated WG LC on ERS/SCVP (draft-ietf-ltans-ers-scvp) several weeks ago. =

Carl = included the=20 feedback he received during LC (mostly editorial changes = and one minor=20 change of bit-on-the-wire)) in the revisions 04 and 05.=20

As = discussed yesterday=20 at the meeting, I feel the draft is in good = shape=20 and=20 will close WG LC for this document next = week (Dec-11)=20 and proceed it to = AD/IESG review = and IETF LC. So if you have any last = comments or=20 discusses for the ERS/SCVP, please submit them until this=20 deadline.

. =

Greetings,=20 Tobias


__________________________________________=
Tobias Gondrom
Head of Open = Text Security=20 Team
Director, Product Security

Open Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630=20 Grasbrunn

Phone:=20 +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 = (0) 89=20 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/ =20

Place = of Incorporation=20 / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, = 85630=20 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 = 1199 |=20 Register Court / Registergericht: M=FCnchen, Germany | Trade Register = Number /=20 HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing = Director /=20 Gesch=E4ftsf=FChrer: John Shackleton, Walter = K=F6hler

This = email is protected=20 by domestic and international copyright laws and treaties and is the = property=20 of Open Text Corporation, it may contain confidential and/or trade = secret=20 information of the Open Text Corporation and/or its subsidiaries = (OTC), and=20 may be subject to legal privilege in favor of OTC. This email may only = be=20 lawfully received, accessed, displayed on a computer screen, printed, = copied,=20 and/or used by the specific addressee(s) named above ("Authorized = Recipient")=20 for the purpose for which it was sent by OTC. All other rights and = licenses to=20 this email are fully reserved to OTC. If you are not an Authorized = Recipient,=20 you are required to immediately delete this email in its entirety = without=20 printing, copying, using, and/or re-transmitting this email, either in = whole=20 or in part. The transmission of this email by OTC is not to be = construed as a=20 waiver by OTC and/or the individual sending this email on behalf of = OTC of any=20 of their respective rights or privileges at law or otherwise, = howsoever=20 arising.

------=_NextPart_000_00BD_01C83752.4F3C3190-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5NDgpB073316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 16:13:42 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5NDgDM073315; Wed, 5 Dec 2007 16:13:42 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5NDewE073307 for ; Wed, 5 Dec 2007 16:13:40 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lB5NDERl020408; Thu, 6 Dec 2007 00:13:14 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lB5NDBYF024444; Wed, 5 Dec 2007 18:13:14 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Thu, 6 Dec 2007 00:13:09 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F1A002@MUCXGC2.opentext.net> In-Reply-To: <009701c83751$dd369680$e8f9a8c0@Wylie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment on draft-ietf-ltans-dssc-01.txt Thread-Index: Acg3S0pgiz5lHlfCSEOf5QUbXBxltQABTdhQABC0CHA= From: "Tobias Gondrom" To: "Turner, Sean P." , "Peter Sylvester" , "Paul Thorpe" Cc: X-Archived: msg.Agfvwuv:2007-12-05:mucpm01.smtp.dmz.opentext.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id lB5NDfwE073310 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello all, in the past the fact that we did not have a comprehensive free ASN.1-compiler for 1997 or 2002 available has been keeping us to at least provide 1988-ASN.1 as one of the modules with every RFC. Thanks to the good and by the IETF well recognized progress on free ASN.1 compilers for 2002-ASN.1 we can now freely use this more recent ASN.1 version. So please consider the new version of ASN.1 to be recommended for your drafts and it no longer to be required to provide a module in 1988-ASN.1 in parallel. Compiler I am referring to is a2c. Regards, Tobias > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org [mailto:owner-ietf-ltans@mail.imc.org] > On Behalf Of Turner, Sean P. > Sent: Wednesday, December 05, 2007 7:17 AM > To: 'Peter Sylvester'; 'Paul Thorpe' > Cc: ietf-ltans@imc.org > Subject: RE: comment on draft-ietf-ltans-dssc-01.txt > > > >-----Original Message----- > >From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] > >Sent: Wednesday, December 05, 2007 6:30 AM > >To: Paul Thorpe > >Cc: Turner, Sean P.; ietf-ltans@imc.org > >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > > > > > >> in 1994 and > >> replaced with the "open type" which allows ASN.1 compilers to > >> explicitly link the contents of the "open type" field with > >the object identifier. > >> > >> > >In other LTANS specifications the following approach is used: > > > >One module is specified in 'CURRENT' ASN.1 syntax. > >An alternative module is done for 'old' compilers with is an > >almost 88 syntax Which one is normative is still a debate (as > >in another group). > > > >In some specs also an XSD schema is defined. For LTAP at least > >the XSD is automatically generated from the ASN.1 and produces > >the same encodings and an XER encoding of the ASN.1 > > > >Besides that and in response to Sean. > > > >Although a module can reuse a name that is defined in another > >module, I agree that this may be confusing. > > > > I like the idea of moving to the later ASN.1. The reason we've been > stopped > in the past was the lack of an open source compiler. We basically have one > now with the a2c compiler. > > Peter - are you saying you don't want to import code, you'd rather grow > your > own? If you do I'd like to see how the current syntax would break out if I > specified an elliptic curve and all it's parameters. It would be an long > sequence of 'stuff' that you'd have to write up some verbiage about the > 1st > element of the sequence was this, the next this, and so on. That seems > like > an unworkable solution to me. > > spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5MVU4g070747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 15:31:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5MVUv5070746; Wed, 5 Dec 2007 15:31:30 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5MVSBD070736 for ; Wed, 5 Dec 2007 15:31:29 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lB5MVP5C018762; Wed, 5 Dec 2007 23:31:26 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lB5MVPO9007194; Wed, 5 Dec 2007 17:31:25 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8378E.91BA4D78" Subject: FYI: FW: [saag] Summary of LTANS WG meeting at IETF 70th in Vancouver Date: Wed, 5 Dec 2007 23:31:23 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F19FFF@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: FW: [saag] Summary of LTANS WG meeting at IETF 70th in Vancouver Thread-Index: Acg3jigIqLZ2p8AHTI2xqzq3Ft+gFwAAAUog X-Priority: 5 Importance: low From: "Tobias Gondrom" To: Cc: "Carl Wallace" X-Archived: msg.BjLxIHo:2007-12-05:mucpm02.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C8378E.91BA4D78 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just FYI. This is just a shortened summary about the meeting yesterday. = For the full minutes please go to the meeting materials page:=20 https://datatracker.ietf.org/meeting/70/materials.html - Tobias _____________________________________________ From: Tobias Gondrom=20 Sent: Wednesday, December 05, 2007 2:28 PM To: saag@mit.edu Cc: 'Carl Wallace' Subject: [saag] Summary of LTANS WG meeting at IETF 70th in Vancouver Summary of LTANS WG meeting 12/4/2007 - 70th IETF - Vancouver:=20 (Detailed minutes have been published on the meeting materials page.) Current work of LTANS WG focuses on finishing existing drafts to bring = them to IETF LC.=20 There are currently five I-Ds in progress:=20 - ERS/SCVP is closing WG LC right after 70th IETF and will proceed to = IETF LC.=20 - DSSC (info about algorithm lifetimes) will go into WG LC soon - XMLERS (had a larger revision and may go into WG LC in Jan/Feb) - validate has been revised and may go to WG LC in Jan/Feb) - LTAP: WG plans to move from planned status "proposed standard" to = "experimental" as we do not see sufficient number of implementations - = planned WG LC in Feb Further comments:=20 - as SCVP has now moved to RFC, ERS/SCVP will continue to proceed as = well. Sample ERS/SCVP artifacts will be made available shortly after the = IETF meeting and a responder may be made available in January for = interop testing. - XMLERS has be revised and its XML structure now closely matches ERS = ASN.1 - invitation for additional XMLERS implementations to run interop tests - search for government authorities (that provide info on suitability of = algorithms and their pararmeters) who want to use and provide data in = the dssc format.=20 - LTAP will change status to "experimental" - currently tbd whether LTANS shall re-continue work on architecture I-D = to explain how the standards work together and outline the architecture = of an overall system Cheers, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler ------_=_NextPart_001_01C8378E.91BA4D78 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI: FW: [saag] Summary of LTANS WG meeting at IETF 70th in = Vancouver

Just FYI. This is just a shortened summary about the meeting = yesterday. For the full minutes please go to the meeting materials page: =

https://datatracker.ietf.org/meeting/70/materials.html

- Tobias


_____________________________________________
From: = Tobias Gondrom
Sent: = Wednesday, December 05, 2007 2:28 PM
To: saag@mit.edu
Cc: = 'Carl Wallace'
Subject: = [saag] Summary of LTANS WG meeting at IETF 70th in = Vancouver

Summary of LTANS WG meeting 12/4/2007 - 70th IETF – = Vancouver:

(Detailed minutes have been published on the meeting = materials page.)

Current work of LTANS WG focuses on finishing existing = drafts to bring them to IETF LC.

There = are currently five I-Ds in progress:

- = ERS/SCVP is closing WG LC right after 70th = IETF and will proceed to IETF LC.

- = DSSC (info about algorithm lifetimes) will go into WG LC = soon

- = XMLERS (had a larger revision and may go into WG LC in = Jan/Feb)

- = validate has been revised and may go to WG LC in = Jan/Feb)

- = LTAP: WG plans to move from planned status “proposed = standard” to “experimental” as we do not see = sufficient number of implementations – planned WG LC in = Feb

Further comments:

- as = SCVP has now moved to RFC, ERS/SCVP will continue to proceed as well. = Sample ERS/SCVP artifacts will be made available shortly after the IETF = meeting and a responder may be made available in January for interop = testing.

- = XMLERS has be revised and its XML structure now closely matches ERS = ASN.1

- = invitation for additional XMLERS implementations to run interop = tests

- = search for government authorities (that provide info on suitability of = algorithms and their pararmeters) who want to use and provide data in = the dssc format.

- = LTAP will change status to “experimental”

- = currently tbd whether LTANS shall re-continue work on architecture I-D = to explain how the standards work together and outline the architecture = of an overall system

Cheers, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open = Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentext.com
Internet: http://www.opentext.com/ 

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler

------_=_NextPart_001_01C8378E.91BA4D78-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5LucVa067267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 14:56:38 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5LucPs067266; Wed, 5 Dec 2007 14:56:38 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5LuaYT067259 for ; Wed, 5 Dec 2007 14:56:37 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm01.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lB5LuZed016209 for ; Wed, 5 Dec 2007 22:56:35 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm01.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lB5LuY52017590 for ; Wed, 5 Dec 2007 16:56:35 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83789.B3BF4795" Subject: closing of WG LC for ERS/SCVP next week on Dec-11 Date: Wed, 5 Dec 2007 22:56:32 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F19FF9@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: closing of WG LC for ERS/SCVP next week on Dec-11 Thread-Index: Acg3ibLJL12m2KX9QMKMYkc3qdf95w== From: "Tobias Gondrom" To: X-Archived: msg.A7HuQrg:2007-12-05:mucpm01.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C83789.B3BF4795 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, just a last reminder: I initiated WG LC on ERS/SCVP = (draft-ietf-ltans-ers-scvp) several weeks ago.=20 Carl included the feedback he received during LC (mostly editorial = changes and one minor change of bit-on-the-wire)) in the revisions 04 = and 05.=20 As discussed yesterday at the meeting, I feel the draft is in good shape = and will close WG LC for this document next week (Dec-11) and proceed it = to AD/IESG review and IETF LC. So if you have any last comments or = discusses for the ERS/SCVP, please submit them until this deadline.=20 .=20 Greetings, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler This email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C83789.B3BF4795 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable closing of WG LC for ERS/SCVP next week on Dec-11

Hello = all,

just = a last reminder: I = initiated WG LC on ERS/SCVP (draft-ietf-ltans-ers-scvp) several weeks ago.

Carl = included the feedback he received during LC (mostly editorial changes and one minor change of = bit-on-the-wire)) in the revisions 04 and 05.

As = discussed yesterday at the meeting, I feel the draft is in good shape = and will close WG LC for this = document next week (Dec-11) and proceed it to AD/IESG review and IETF LC. So if you have any last comments or discusses = for the ERS/SCVP, please submit them until this = deadline.

.

Greetings, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open = Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler

This = email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized = Recipient") for the purpose for which it was sent by OTC. All other = rights and licenses to this email are fully reserved to OTC. If you are = not an Authorized Recipient, you are required to immediately delete this = email in its entirety without printing, copying, using, and/or = re-transmitting this email, either in whole or in part. The transmission = of this email by OTC is not to be construed as a waiver by OTC and/or = the individual sending this email on behalf of OTC of any of their = respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C83789.B3BF4795-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5Lm2fx066661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 14:48:02 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5Lm2ZR066660; Wed, 5 Dec 2007 14:48:02 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mucmx01.ixos.de (mucmx01.ixos.de [149.235.128.48]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5Lm0Rf066653 for ; Wed, 5 Dec 2007 14:48:01 -0700 (MST) (envelope-from tgondrom@opentext.com) Received: from mucpm02.smtp.dmz.opentext.com (localhost [127.0.0.1]) by mucmx01.ixos.de (8.12.10+Sun/8.12.10) with ESMTP id lB5Llx1N015603 for ; Wed, 5 Dec 2007 22:47:59 +0100 (MET) Received: from MUCXGC2.opentext.net (mucxg04.opentext.net [149.235.128.138]) by mucpm02.smtp.dmz.opentext.com (8.13.8/8.13.8) with ESMTP id lB5Llwtq002628 for ; Wed, 5 Dec 2007 16:47:58 -0500 (envelope-from tgondrom@opentext.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83788.7FE685CE" Subject: LTANS meeting minutes and slides from 70th IETF are available online Date: Wed, 5 Dec 2007 22:47:55 +0100 Message-ID: <2666EB2A846BAC4BB2D7F593301A786801F19FF8@MUCXGC2.opentext.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS meeting minutes and slides from 70th IETF are available online Thread-Index: Acg3iH6dhrygCMn6TPyoyxdFlrVMhw== X-Priority: 5 Importance: low From: "Tobias Gondrom" To: X-Archived: msg.B5kQjxX:2007-12-05:mucpm02.smtp.dmz.opentext.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C83788.7FE685CE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all,=20 just FYI: the minutes and presentation slides are available on the = Meetings Material web page:=20 https://datatracker.ietf.org/meeting/70/materials.html and an audio archive of the meeting is also available (audio file = combined with forces and smime): http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf70/ietf70-ch3-tue= -afnoon-forces-ltans-smime.mp3 cheers, Tobias __________________________________________ Tobias Gondrom Head of Open Text Security Team Director, Product Security Open Text Technopark 2 Werner-von-Siemens-Ring 20 D-85630 Grasbrunn Phone: +49 (0) 89 4629-1816 Mobile: +49 (0) 173 5942987 Telefax: +49 (0) 89 4629-33-1816 eMail: mailto:tobias.gondrom@opentext.com=20 Internet: http://www.opentext.com/ =20 Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler This email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized Recipient") for = the purpose for which it was sent by OTC. All other rights and licenses = to this email are fully reserved to OTC. If you are not an Authorized = Recipient, you are required to immediately delete this email in its = entirety without printing, copying, using, and/or re-transmitting this = email, either in whole or in part. The transmission of this email by OTC = is not to be construed as a waiver by OTC and/or the individual sending = this email on behalf of OTC of any of their respective rights or = privileges at law or otherwise, howsoever arising. ------_=_NextPart_001_01C83788.7FE685CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LTANS meeting minutes and slides from 70th IETF are available = online

Hi all, =

just = FYI: the minutes and presentation slides are available on the Meetings Material web page:

https://datatracker.ietf.org/meeting/70/materials.html

and an audio archive of the meeting is also available = (audio file = combined with forces and smime):

http://limestone.uoregon.edu/ftp/= pub/videolab/media/ietf70/ietf70-ch3-tue-afnoon-forces-ltans-smime.mp3

cheers, Tobias


__________________________________________
Tobias = Gondrom
Head of = Open Text Security Team
Director, Product Security

Open = Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias.gondrom@opentex= t.com
Internet: http://www.opentext.com/  =

Place = of Incorporation / Sitz der Gesellschaft: Open Text GmbH, = Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 = 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: = M=FCnchen, Germany | Trade Register Number / HRB: 168364 | VAT ID Number = /USt-ID: DE 114 169 819 | Managing Director / Gesch=E4ftsf=FChrer: John = Shackleton, Walter K=F6hler

This = email is protected by domestic and international copyright laws and = treaties and is the property of Open Text Corporation, it may contain = confidential and/or trade secret information of the Open Text = Corporation and/or its subsidiaries (OTC), and may be subject to legal = privilege in favor of OTC. This email may only be lawfully received, = accessed, displayed on a computer screen, printed, copied, and/or used = by the specific addressee(s) named above ("Authorized = Recipient") for the purpose for which it was sent by OTC. All other = rights and licenses to this email are fully reserved to OTC. If you are = not an Authorized Recipient, you are required to immediately delete this = email in its entirety without printing, copying, using, and/or = re-transmitting this email, either in whole or in part. The transmission = of this email by OTC is not to be construed as a waiver by OTC and/or = the individual sending this email on behalf of OTC of any of their = respective rights or privileges at law or otherwise, howsoever = arising.

------_=_NextPart_001_01C83788.7FE685CE-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5IVAMJ045739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 11:31:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5IVAFr045738; Wed, 5 Dec 2007 11:31:10 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB5IV9NS045732 for ; Wed, 5 Dec 2007 11:31:09 -0700 (MST) (envelope-from CWallace@cygnacom.com) Received: (qmail 27714 invoked from network); 5 Dec 2007 18:25:27 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;05 Dec 2007 18:25:27 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 5 Dec 2007 18:25:26 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Dec 2007 13:31:07 -0500 Message-ID: From: Carl Wallace To: Thomas Kunz , "Turner, Sean P." Cc: ietf-ltans@imc.org Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Wed, 5 Dec 2007 13:30:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A6_01C83743.0D4F5AA0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00A6_01C83743.0D4F5AA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit How about something like the following to avoid multiple instances of an alg ID: > AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > constraints SEQUENCE OF Constraint } Constraint::= SEQUENCE { parameter CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints} > validity Validity OPTIONAL, > information Information OPTIONAL } > -----Original Message----- > From: owner-ietf-ltans@mail.imc.org > [mailto:owner-ietf-ltans@mail.imc.org] On Behalf Of Thomas Kunz > Sent: Wednesday, December 05, 2007 11:02 AM > To: Turner, Sean P. > Cc: ietf-ltans@imc.org > Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > The problem with your suggested syntax is the definition of > the our constraints. If we used the RFC3280 > AlgorithmIdentifier structure, we would integrate the > constraints as follows: > > AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > constraint CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints > validity Validity OPTIONAL, > information Information OPTIONAL } > > It's not possible to determine constraints for more than one > parameter (e.g. p > 1024 and q > 160 in case of DSA). > Additionally defining ranges is impossible (e.g. modulus < > 2048 and modulus > 1024). > > > so & tk > > > Turner, Sean P. schrieb: > > I'm only commenting on the Parameter structure in the > ASN.1. I think > > that it might be better to change Algorithm to be a sequence of > > algorithmIdentifier, validity, and information - call it > > AlgorithmValidityInfo. I suggest this for two reasons: > > > > 1. The AlgorithmIdentifier structure that is used to assign an > > algorithm's object identifier also define the parameters. So it > > probably makes sense to reuse this structure. > > > > 2. The parameters structures for some of the newer > algorithms is quite > > complicated. For example, RSASSA-PSS [RFC4055] and ECC > Algs [RFC3279] > > aren't just an OID they are nested structure. > > > > (not sure how to do it in XML) > > > > Replace: > > > > Algorithm ::= SEQUENCE { > > algorithmIdentifier AlgID, > > parameters [0] SEQUENCE OF Parameter OPTIONAL, > > validity [1] Validity, > > information [2] SEQUENCE OF UTF8String OPTIONAL > > } > > > > AlgID ::= SEQUENCE { > > name UTF8String, > > oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > > uri [1] SEQUENCE OF IA5String OPTIONAL > > } > > > > Parameter ::= SEQUENCE { > > name UTF8String, > > constraint CHOICE { > > exact [0] OCTET STRING, > > min [1] OCTET STRING, > > max [2] OCTET STRING, > > range [3] Range, > > other [4] OtherConstraints > > } > > } > > > > With: > > > > AlgorithmValidityInfo ::= SEQUENCE { > > identifier AlgorithmIdentifier, > > validity Validity OPTIONAL, > > information Information OPTIONAL } > > > > Validity ::= SEQUENCE { > > start [0] GeneralizedTime OPTIONAL, > > end [1] GeneralizedTime OPTIONAL } > > > > Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > > > > -- From RFC3280 > > AlgorithmIdentifier ::= SEQUENCE { > > algorithm OBJECT IDENTIFIER, > > parameters ANY DEFINED BY algorithm OPTIONAL } > > -- contains a value of the type > > -- registered for use with the > > -- algorithm object identifier value > > > > spt > > > > > ------=_NextPart_000_00A6_01C83743.0D4F5AA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILpjCCA60w ggKVoAMCAQICBECEF1YwDQYJKoZIhvcNAQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5 Z25hY29tMB4XDTA0MDQxOTE3NDYwMVoXDTI0MDQxOTE4MTYwMVowIDELMAkGA1UEBhMCdXMxETAP BgNVBAoTCGN5Z25hY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuw8jjNSH/3qx UShITC4+vYJG8TZsE2f4pbGUhcXe+v0PChxtWvVpOAVqXm/7y1hdBKKMjdg98Xo/jmVtFPGlKXhV v9FYyK1zxydN1YgEjRzmuSd9RNNm9YL2rgg2Q/TtT3hDwDiT4rj62ukIKYTlZHNLm1t7uYa8K/44 F5jJvo6zPkWtRqrKBFJfBblKFaPteEXU5JIKX8cbwIF3HJx9+P15S0wRngCKb0+1/d9pIuwS4Frg 1R98hG+jRXiS8klB6TncucWH2w1OqYouzUGSncb+o+EVx4PHwsE7kKxIMAsQC6zbHsAS0CAOb6hw JW7P+dtaR/9Gi8NdKsgkFlQjbQIDAQABo4HuMIHrMEIGA1UdHwQ7MDkwN6A1oDOkMTAvMQswCQYD VQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMjAw NDA0MTkxNzQ2MDFagQ8yMDI0MDQxOTE4MTYwMVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFHqT o3DI3p2/kOS+O6DeN/DUalp5MB0GA1UdDgQWBBR6k6NwyN6dv5Dkvjug3jfw1GpaeTAMBgNVHRME BTADAQH/MB0GCSqGSIb2fQdBAAQQMA4bCFY3LjA6NC4wAwIEkDANBgkqhkiG9w0BAQUFAAOCAQEA aHtrFA6rDnATj2GxfNuRLFVrsWBLSCYUdMs6YbssKI2f/Fh/o382eAnvvcpI76koLijn4Cbj482A tkWgw6hOhgESamFWaY951O0nUrk43KG5Nv4KQjXiNArFwf1ATEtB6KTeiaffh2vVbUWodZ+uwnTh X6ZlPmVooWFcB9NH+9GteR7zIJA/Eq0p0CHiCozIhOp1QGJ2cXTtHQk4Cq+sYh8du6ry0xRB3b5Z Jw/iewtxAoge2e/vh0f46mgrSdmCuPzjVLvyLg63ktN9hJe8Iiy4JiKqplnsMGizW2lxKwl/Ys0L alsltxYuLF1jytrzGJEit+5acGcjhdhijL0IojCCA98wggLHoAMCAQICBECEWOUwDQYJKoZIhvcN AQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMB4XDTA2MDkyNzExNDcxN1oX DTA5MDkyNzEyMTcxN1owRzELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMSUwDgYDVQQF EwcyRUNSVzAyMBMGA1UEAxMMQ2FybCBXYWxsYWNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAwVtX5z3+WT31t1J6qYHb6CsFBl6NLFq+cnJjpuxMAiFfMoifHSreDtDfJMUJcUMqOG1o 0JdBUI4nakhAo8nPNMkzatmF0cxyryagaWWnILjPJKz5LCzM/LNQnMhUFGoRPDMnkaJp82pAW/Me cjUSS1w2MMFnjxjZ9t8DHvQ3FEY2nU5yKolnLrbmx07qVCT2KNEyetQKTR5iCsA7YiYPTFIsXHPr TiqUsbIETHIWJqh8hRZt3Mf1jg4ayrGKmcOvpjphit7HCOPxtM/u9tajt705LzcAk/6YN3yXtc/c 88Sw48YtKrba1m5IwBq6MNBp0K9tSq7j0Mpm0bIkyL8bMwIDAQABo4H5MIH2MCAGA1UdEQQZMBeB FWN3YWxsYWNlQGN5Z25hY29tLmNvbTAbBgNVHQkEFDASMBAGCSqGSIb2fQdEHTEDAgEKMEIGA1Ud HwQ7MDkwN6A1oDOkMTAvMQswCQYDVQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTALBgNVBAMT BENSTDEwCwYDVR0PBAQDAgUgMB8GA1UdIwQYMBaAFHqTo3DI3p2/kOS+O6DeN/DUalp5MB0GA1Ud DgQWBBSTgaWOBxA4oFp5yDWk+ZSoowxj0zAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3 LjADAgSQMA0GCSqGSIb3DQEBBQUAA4IBAQCAPGGb5f6vwUpGtEaX0UbWzcCn0g5l72s82rsQjiBF rXYpRO62c2rcnqrSp6EVa2Qk62h+DXmxnLzF+zjJ6roRnAW9LW28UYxPi9cpLGxmRkRe+d62K7QU LM7G5vU64jfW641ykblwQaf/dVzcTpXg7mU7n7qO46YWAAVaTyq3gdKYZxtXInZEWvnxzH3dJjcD 7Q1KSrH/ztsbwgW/rFq29iorSjVZNG4ROB7QAG85GVy5GkDSLEjOnEU+3dVgqjEjxODyCP+owkzO k2JKsyqaewHPnbNs4NV7OGCJx+BJsLK2Ef0MBYdt7Ebe1efxNIK8IyeuFBJPjJRLQItdBiVnMIIE DjCCAvagAwIBAgIEQIRY+zANBgkqhkiG9w0BAQUFADAgMQswCQYDVQQGEwJ1czERMA8GA1UEChMI Y3lnbmFjb20wHhcNMDYwOTI4MTY0NjMxWhcNMDkwOTI4MTcxNjMxWjBHMQswCQYDVQQGEwJ1czER MA8GA1UEChMIY3lnbmFjb20xJTAOBgNVBAUTBzJFQ1JXMDIwEwYDVQQDEwxDYXJsIFdhbGxhY2Uw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTeGLLD5qbBCFsqR9R+3UTCxdJKetGhH7z UVgI2cfdzArj3uXkR7r2bpVS80GRVKaC/0t8EYaxW4Ls8ZfdwWutaFfzbbIB2E+TAzF+ldT01Vdv gy3Rws+BhZWudk5blrakYfKeUffzWiYHrJGHtOTOnyucHdE6gahikPDQ8lsDEbtxt+hzymOXZKVY VAk2u5eBj/uxtAk/PMbIUcQLqvMf01AiZs6kNvHuhaWheAxGa4+cHM5nFUpSZpC49r4BuoBA2Rw2 ES2a+OqhMIKlsdE9MM7G9YQf4jREcf4cfnT+cMd57lc8TijkKJOMoXyMtLRK+UByDtQ1FbCNHAz4 hnRxAgMBAAGjggEnMIIBIzALBgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwNjA5MjgxNjQ2MzFa gQ8yMDA4MTEwMzIxMTYzMVowIAYDVR0RBBkwF4EVY3dhbGxhY2VAY3lnbmFjb20uY29tMBsGA1Ud CQQUMBIwEAYJKoZIhvZ9B0QdMQMCAQowQgYDVR0fBDswOTA3oDWgM6QxMC8xCzAJBgNVBAYTAnVz MREwDwYDVQQKEwhjeWduYWNvbTENMAsGA1UEAxMEQ1JMMTAfBgNVHSMEGDAWgBR6k6NwyN6dv5Dk vjug3jfw1GpaeTAdBgNVHQ4EFgQU/GqeRUaoI5dNtUm3CGFNyYv1k64wCQYDVR0TBAIwADAZBgkq hkiG9n0HQQAEDDAKGwRWNy4wAwIEsDANBgkqhkiG9w0BAQUFAAOCAQEAOOP2IoptDkJugTF+3euz rC8N5aO392HDa3y2cf7XL9uVGJ9YT2DUMmaxZBS9hpKa9yxeU+Vcoho6p/7QhLtDhHR4LlXg1CXd EuMTlEdL2aA0CYJjAbCQsPACCm7+MFvfdTKwrD6NEx+3eInppPTgXm3HuZEamKPQN69tZ3wr7TMe qBBWRUrS2GfnfpGGRneI7yhA+HJ0PDOEMA31C877efxHOqnRsojU4f9+F7EPw8y6Ipovf0GFJ0ZV a4gMaouSzNwmOHhsZfgzM8lpmUN8CkYXTdHEwDedKjzJ3mltindxDYml6tFl0A4kAv/rD68dGgbz kPNQAkbrT9dijO2yNTGCAo0wggKJAgEBMCgwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25h Y29tAgRAhFj7MAkGBSsOAwIaBQCgggE6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTA3MTIwNTE4MzA1MFowIwYJKoZIhvcNAQkEMRYEFEXOgtQqINZd7Ig/IB1PQmE8 jdCcMDcGCSsGAQQBgjcQBDEqMCgwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tAgRA hFjlMDkGCyqGSIb3DQEJEAILMSqgKDAgMQswCQYDVQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20C BECEWOUwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwDQYJ KoZIhvcNAQEBBQAEggEAwNln1PpwdzEBU/mY4FlOO8ILHMjiwytvwVX2Vu8nP8DZyqY/gBwZ27nJ zk5BpGSSKR+Zq0lo5lMiwlRj2cPm4HNaoi2zx1Q3Un9tlGFBsrtgOJx5Qco1F75yprJljwDzBkUg xyMlgB/O9Fnug1gqW72BNMWTWRNaHPLQEIpVv16TA3Z+xJkmZSutRPlfhUKL0PbU6KPDMqcY1SRb gsMZkUqDmPN9HqyiqOAIAdeSEhugwf+na4MoVVlZlBoQF8ZDS36LHTv1gdcwsiUlkUmYtiajcDze ihqPCzbevxNNKaslUPUFKEMsPc+WaqXwU+iXBDpDagfTt/TN1QN/Muv0TwAAAAAAAA== ------=_NextPart_000_00A6_01C83743.0D4F5AA0-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5GSJXV033046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 09:28:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5GSJSo033045; Wed, 5 Dec 2007 09:28:19 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB5GSHsj033037 for ; Wed, 5 Dec 2007 09:28:18 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 36553 invoked from network); 5 Dec 2007 16:28:17 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@216.18.3.1 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 5 Dec 2007 16:28:17 -0000 X-YMail-OSG: Oaro.qEVM1m__zx.j.N6KByUgy7ir9poRBpFbEn641bmFkIERtaGOhdhPkXpxn5siN8cgzkH82yjTYRtSCHJk4CP_dSZx_6h2hBDutOiYA0xKu8VYWiRPYBtCMwvs2BDTNbyl..vIh3yKDY- From: "Turner, Sean P." To: "'Peter Sylvester'" Cc: "'Paul Thorpe'" , References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756B5D7.7010407@edelweb.fr> <009701c83751$dd369680$e8f9a8c0@Wylie> <4756CA1F.9080202@edelweb.fr> Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Wed, 5 Dec 2007 08:24:03 -0800 Organization: IECA, Inc. Message-ID: <010801c8375b$4105a620$e8f9a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4756CA1F.9080202@edelweb.fr> Thread-Index: Acg3V2EN8w1QKvlOR5iahCnkFNO2WQAA47Xw Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> I like the idea of moving to the later ASN.1. The reason we've been >> stopped in the past was the lack of an open source compiler. We >> basically have one now with the a2c compiler. >> >I disagree that we were stopped by that. But that's an old story I hope >> Peter - are you saying you don't want to import code, you'd rather >> grow your own? If you do I'd like to see how the current >syntax would >> break out if I specified an elliptic curve and all it's >parameters. It >> would be an long sequence of 'stuff' that you'd have to >write up some >> verbiage about the 1st element of the sequence was this, the next >> this, and so on. That seems like an unworkable solution to me. >> >I have made no comment about the structure of the information >that this document is proposing. I just mentioned that reusing >a particular name 'Algorithm' >to define >another but similar structure as in some other module is not a >good idea, and indeed defining another thing like >AlgorithmValidityInfo is better. > >I think you refer to some older message from me? >Following your comment: Before really entering into concrete >syntax, it would be good to describe what abstract information >needs to be encoded and how a validator (an automatic tool!!) >is supposed to operate. >An important requirement to me seems that when adding >something to the structure, the core validator doesn't change. > >Does that makes sense? >P I guess I was reacting to the thoughts of algorithm spec writers have to have to different formats for representing their algorithms. One which is used in most ASN.1 based security protocols and another for this. I think picking another syntax would sink this proposal. Thomas has solved my concern though. spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5GPh7M032885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 09:25:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5GPh0B032884; Wed, 5 Dec 2007 09:25:43 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB5GPfTs032876 for ; Wed, 5 Dec 2007 09:25:42 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 37485 invoked from network); 5 Dec 2007 16:25:41 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@216.18.3.1 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 5 Dec 2007 16:25:40 -0000 X-YMail-OSG: d__moJMVM1lQEVbcr0bCPoG2LZT2sQR04zJY0puvkXp4RHY7O5ytuVPWimYlBATrY3VQ.Yx2ug-- From: "Turner, Sean P." To: "'Thomas Kunz'" Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756CB6A.4030504@sit.fraunhofer.de> Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Wed, 5 Dec 2007 08:21:25 -0800 Organization: IECA, Inc. Message-ID: <00f101c8375a$e3c98bc0$e8f9a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4756CB6A.4030504@sit.fraunhofer.de> Thread-Index: Acg3WCi6c4cGEkitQ12REqMINMbYlAAAp67Q Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This would work for me. spt >-----Original Message----- >From: Thomas Kunz [mailto:thomas.kunz@sit.fraunhofer.de] >Sent: Wednesday, December 05, 2007 8:02 AM >To: Turner, Sean P. >Cc: ietf-ltans@imc.org >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > >The problem with your suggested syntax is the definition of >the our constraints. If we used the RFC3280 >AlgorithmIdentifier structure, we would integrate the >constraints as follows: > >AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > constraint CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints > validity Validity OPTIONAL, > information Information OPTIONAL } > >It's not possible to determine constraints for more than one >parameter (e.g. p > 1024 and q > 160 in case of DSA). >Additionally defining ranges is impossible (e.g. modulus < >2048 and modulus > 1024). > > >so & tk > > >Turner, Sean P. schrieb: >> I'm only commenting on the Parameter structure in the ASN.1. I think >> that it might be better to change Algorithm to be a sequence of >> algorithmIdentifier, validity, and information - call it >> AlgorithmValidityInfo. I suggest this for two reasons: >> >> 1. The AlgorithmIdentifier structure that is used to assign an >> algorithm's object identifier also define the parameters. So it >> probably makes sense to reuse this structure. >> >> 2. The parameters structures for some of the newer >algorithms is quite >> complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs >[RFC3279] >> aren't just an OID they are nested structure. >> >> (not sure how to do it in XML) >> >> Replace: >> >> Algorithm ::= SEQUENCE { >> algorithmIdentifier AlgID, >> parameters [0] SEQUENCE OF Parameter OPTIONAL, >> validity [1] Validity, >> information [2] SEQUENCE OF UTF8String OPTIONAL >> } >> >> AlgID ::= SEQUENCE { >> name UTF8String, >> oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, >> uri [1] SEQUENCE OF IA5String OPTIONAL >> } >> >> Parameter ::= SEQUENCE { >> name UTF8String, >> constraint CHOICE { >> exact [0] OCTET STRING, >> min [1] OCTET STRING, >> max [2] OCTET STRING, >> range [3] Range, >> other [4] OtherConstraints >> } >> } >> >> With: >> >> AlgorithmValidityInfo ::= SEQUENCE { >> identifier AlgorithmIdentifier, >> validity Validity OPTIONAL, >> information Information OPTIONAL } >> >> Validity ::= SEQUENCE { >> start [0] GeneralizedTime OPTIONAL, >> end [1] GeneralizedTime OPTIONAL } >> >> Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String >> >> -- From RFC3280 >> AlgorithmIdentifier ::= SEQUENCE { >> algorithm OBJECT IDENTIFIER, >> parameters ANY DEFINED BY algorithm OPTIONAL } >> -- contains a value of the type >> -- registered for use with the >> -- algorithm object identifier value >> >> spt >> >> > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5G206g030570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 09:02:00 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5G206v030568; Wed, 5 Dec 2007 09:02:00 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5G1vHC030561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Dec 2007 09:01:59 -0700 (MST) (envelope-from thomas.kunz@sit.fraunhofer.de) Received: from [141.12.89.208] (sitp1_212.sit.fraunhofer.de [141.12.68.212]) by mailext.sit.fraunhofer.de (8.13.6/8.13.6/9.9.9) with ESMTP id lB5G1qnK025562; Wed, 5 Dec 2007 17:01:52 +0100 Message-ID: <4756CB6A.4030504@sit.fraunhofer.de> Date: Wed, 05 Dec 2007 17:01:46 +0100 From: Thomas Kunz User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Turner, Sean P." CC: ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> In-Reply-To: <001201c836e7$1f82a4e0$df128182@Wylie> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030004040002090306050507" Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms030004040002090306050507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The problem with your suggested syntax is the definition of the our constraints. If we used the RFC3280 AlgorithmIdentifier structure, we would integrate the constraints as follows: AlgorithmValidityInfo ::= SEQUENCE { identifier AlgorithmIdentifier, constraint CHOICE { exact [0] OCTET STRING, min [1] OCTET STRING, max [2] OCTET STRING, range [3] Range, other [4] OtherConstraints validity Validity OPTIONAL, information Information OPTIONAL } It's not possible to determine constraints for more than one parameter (e.g. p > 1024 and q > 160 in case of DSA). Additionally defining ranges is impossible (e.g. modulus < 2048 and modulus > 1024). so & tk Turner, Sean P. schrieb: > I'm only commenting on the Parameter structure in the ASN.1. I think that it > might be better to change Algorithm to be a sequence of algorithmIdentifier, > validity, and information - call it AlgorithmValidityInfo. I suggest this > for two reasons: > > 1. The AlgorithmIdentifier structure that is used to assign an algorithm's > object identifier also define the parameters. So it probably makes sense to > reuse this structure. > > 2. The parameters structures for some of the newer algorithms is quite > complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs [RFC3279] > aren't just an OID they are nested structure. > > (not sure how to do it in XML) > > Replace: > > Algorithm ::= SEQUENCE { > algorithmIdentifier AlgID, > parameters [0] SEQUENCE OF Parameter OPTIONAL, > validity [1] Validity, > information [2] SEQUENCE OF UTF8String OPTIONAL > } > > AlgID ::= SEQUENCE { > name UTF8String, > oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > uri [1] SEQUENCE OF IA5String OPTIONAL > } > > Parameter ::= SEQUENCE { > name UTF8String, > constraint CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints > } > } > > With: > > AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > validity Validity OPTIONAL, > information Information OPTIONAL } > > Validity ::= SEQUENCE { > start [0] GeneralizedTime OPTIONAL, > end [1] GeneralizedTime OPTIONAL } > > Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > > -- From RFC3280 > AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > -- contains a value of the type > -- registered for use with the > -- algorithm object identifier value > > spt > > --------------ms030004040002090306050507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCC BacwggSPoAMCAQICAgDfMA0GCSqGSIb3DQEBBQUAME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQK EwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNB IHYyMB4XDTA0MDYwOTA3MzQyM1oXDTA4MTIzMTIzMDAwMFowVzELMAkGA1UEBhMCREUxEzAR BgNVBAoTCkZyYXVuaG9mZXIxDDAKBgNVBAsTA1NJVDEPMA0GA1UECxMGUGVvcGxlMRQwEgYD VQQDEwtUaG9tYXMgS3VuejCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALFclK+E n2p85uM4bbfxKqpHBUOd9qSCNnuPcITixktM7A1rRmbu1nbQcppKj40Bjv/rOqTavvux1oiS O+mzrOq9Aa0MmjPyFpjcPOK62EaGFMNuHx7cafnLe4Y8EJcdl9RZdBO+SY/2gr5wq9/jvaaF fkU0Q+5iY4NS2/nLZ2mYaqRI2wCxaLAMyfJYL4z5/qEW51KTQ0LHHm9qiVZg2hempXSMABC9 6/BzYKwaGMh0vaSCppUFdJvhVNwAUHsUkosNTFiU9ks2fIpzlNPJv7UE8wfTrCzAf4CBgWTA jHXJdgaAF2rD0JjbbpA/G1w3rAT8yKy3mfljJOcLcuUZYBMCAwEAAaOCAoMwggJ/MIGeBglg hkgBhvhCAQ0EgZAWgY1Tb2Z0d2FyZSBaZXJ0aWZpa2F0IGRlciBaZXJ0aWZpemllcnVuZ2lu c3RhbnogKENBKSBkZXIgRnJhdW5ob2Zlci1HZXNlbGxzY2hhZnQgZS5WLiwgTXVlbmNoZW47 IFd1cnplbHplcnRpZmlrYXQgdmlhIGh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS8wTQYIKwYB BQUHAQEEQTA/MD0GCCsGAQUFBzABhjFodHRwOi8vcGtpLmZyYXVuaG9mZXIuZGUvRmhHLUNB X3YyX09DU1AtUmVzcG9uZGVyMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9wa2kuZnJhdW5o b2Zlci5kZS9GaEctQ0EtQ2VydHMvRmhHLUNBX3YyX0NSTC5jcmwwCQYDVR0TBAIwADBKBgNV HRIEQzBBgSR6ZXJ0aWZpemllcnVuZ3NpbnN0YW56QGZyYXVuaG9mZXIuZGWGGWh0dHA6Ly9w a2kuZnJhdW5ob2Zlci5kZS8wKAYDVR0RBCEwH4EddGhvbWFzLmt1bnpAc2l0LmZyYXVuaG9m ZXIuZGUwTAYDVR0gBEUwQzBBBgsrBgEEAYYKUAIBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8v cGtpLmZyYXVuaG9mZXIuZGUvcG9saWN5Lmh0bWwwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsG AQUFBwMDBggrBgEFBQcDBDALBgNVHQ8EBAMCA/gwHQYDVR0OBBYEFAT5q7Rw9gTlubggX/wN +6oZowK3MB8GA1UdIwQYMBaAFADD/O9jwlYoL1ELdVb/ewXpHMnxMA0GCSqGSIb3DQEBBQUA A4IBAQDoyyNHTB3tv3kVsap2axcaFKsKwzTNqq/bnj+a6VFpy5ejBbtusHG8njqa+LheRT/k Vi6xFYFXegw54Cf6IGCJ2E1EBWfgJXqyaO+PgUggd6bLOy/8fZauR1oIlt4nQNjoXyJxqV9x tpgxZsF7pHtqcwh4ZYA+nsEC6DdCfsUqegrqzmtA7hZ34o3yeZCR5qs3M9jja3lw9KfxnbHh 6CM/vM7o6KIEFdx8RlIWpYEJB05rqMO7PrXiRrmJDHeCwRtx+R5iskUX3grhh6yHBRM1NKHx LY/waDKxBj3ZXPSkN0k7PBppeuYHgJ4ZVAuvP9v2GKkyU3pHOcwE5iZOiQyNMIIFpzCCBI+g AwIBAgICAN8wDQYJKoZIhvcNAQEFBQAwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVu aG9mZXIxKzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjIwHhcN MDQwNjA5MDczNDIzWhcNMDgxMjMxMjMwMDAwWjBXMQswCQYDVQQGEwJERTETMBEGA1UEChMK RnJhdW5ob2ZlcjEMMAoGA1UECxMDU0lUMQ8wDQYDVQQLEwZQZW9wbGUxFDASBgNVBAMTC1Ro b21hcyBLdW56MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsVyUr4Sfanzm4zht t/EqqkcFQ532pII2e49whOLGS0zsDWtGZu7WdtBymkqPjQGO/+s6pNq++7HWiJI76bOs6r0B rQyaM/IWmNw84rrYRoYUw24fHtxp+ct7hjwQlx2X1Fl0E75Jj/aCvnCr3+O9poV+RTRD7mJj g1Lb+ctnaZhqpEjbALFosAzJ8lgvjPn+oRbnUpNDQsceb2qJVmDaF6aldIwAEL3r8HNgrBoY yHS9pIKmlQV0m+FU3ABQexSSiw1MWJT2SzZ8inOU08m/tQTzB9OsLMB/gIGBZMCMdcl2BoAX asPQmNtukD8bXDesBPzIrLeZ+WMk5wty5RlgEwIDAQABo4ICgzCCAn8wgZ4GCWCGSAGG+EIB DQSBkBaBjVNvZnR3YXJlIFplcnRpZmlrYXQgZGVyIFplcnRpZml6aWVydW5naW5zdGFueiAo Q0EpIGRlciBGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBlLlYuLCBNdWVuY2hlbjsgV3VyemVs emVydGlmaWthdCB2aWEgaHR0cDovL3BraS5mcmF1bmhvZmVyLmRlLzBNBggrBgEFBQcBAQRB MD8wPQYIKwYBBQUHMAGGMWh0dHA6Ly9wa2kuZnJhdW5ob2Zlci5kZS9GaEctQ0FfdjJfT0NT UC1SZXNwb25kZXIwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL3BraS5mcmF1bmhvZmVyLmRl L0ZoRy1DQS1DZXJ0cy9GaEctQ0FfdjJfQ1JMLmNybDAJBgNVHRMEAjAAMEoGA1UdEgRDMEGB JHplcnRpZml6aWVydW5nc2luc3RhbnpAZnJhdW5ob2Zlci5kZYYZaHR0cDovL3BraS5mcmF1 bmhvZmVyLmRlLzAoBgNVHREEITAfgR10aG9tYXMua3VuekBzaXQuZnJhdW5ob2Zlci5kZTBM BgNVHSAERTBDMEEGCysGAQQBhgpQAgEBMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly9wa2kuZnJh dW5ob2Zlci5kZS9wb2xpY3kuaHRtbDAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMG CCsGAQUFBwMEMAsGA1UdDwQEAwID+DAdBgNVHQ4EFgQUBPmrtHD2BOW5uCBf/A37qhmjArcw HwYDVR0jBBgwFoAUAMP872PCVigvUQt1Vv97BekcyfEwDQYJKoZIhvcNAQEFBQADggEBAOjL I0dMHe2/eRWxqnZrFxoUqwrDNM2qr9ueP5rpUWnLl6MFu26wcbyeOpr4uF5FP+RWLrEVgVd6 DDngJ/ogYInYTUQFZ+AlerJo74+BSCB3pss7L/x9lq5HWgiW3idA2OhfInGpX3G2mDFmwXuk e2pzCHhlgD6ewQLoN0J+xSp6CurOa0DuFnfijfJ5kJHmqzcz2ONreXD0p/GdseHoIz+8zujo ogQV3HxGUhalgQkHTmuow7s+teJGuYkMd4LBG3H5HmKyRRfeCuGHrIcFEzU0ofEtj/BoMrEG Pdlc9KQ3STs8Gml65geAnhlUC68/2/YYqTJTekc5zATmJk6JDI0xggL/MIIC+wIBATBVME8x CzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVy LUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zAJBgUrDgMCGgUAoIIBfzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzEyMDUxNjAxNDZaMCMGCSqGSIb3 DQEJBDEWBBQ2P7zNfrr0j3/upIjvYwz0/4r+BDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhv ZmVyMSswKQYDVQQDEyJGcmF1bmhvZmVyLUdlc2VsbHNjaGFmdCBSb290LUNBIHYyAgIA3zBm BgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIx KzApBgNVBAMTIkZyYXVuaG9mZXItR2VzZWxsc2NoYWZ0IFJvb3QtQ0EgdjICAgDfMA0GCSqG SIb3DQEBAQUABIIBAG2Q30eVHpfmfXmCsFqfBlGcGhWePxY4+0YqMEECAny+3focOpLAvwa0 OXQFbp8yLAtvG/76krfuyPXTxQIQcJTOn7PSwTkPkzMD0XEiIGUG5fll2D243bBljzPJtEP3 SMdC1pdxTIJN3o+0sp1dBC6I1/sc+mio7SI/qtmMRExb/6wuzYdxuujolHi39fVTvIeaT+qf fBGbxpKwd5zgo9KmCCbFlAl1woRKcPC+hg0AphUZT90EKnRnrstTahus5te1xk9kcGGLGpJ/ J/WDM1KbELmaSeCfbE6LyRV94iaGuj656RjNQ/yD6WXw9giibswyS8cR0jOnsoGK13HloHQA AAAAAAA= --------------ms030004040002090306050507-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5FuLBk029991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 08:56:21 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5FuL8W029990; Wed, 5 Dec 2007 08:56:21 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5FuJ0T029983 for ; Wed, 5 Dec 2007 08:56:20 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id B64E346; Wed, 5 Dec 2007 16:56:18 +0100 (CET) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18287-01; Wed, 5 Dec 2007 16:56:16 +0100 (CET) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 13CA113; Wed, 5 Dec 2007 16:56:16 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007120516561465:153528 ; Wed, 5 Dec 2007 16:56:14 +0100 Message-ID: <4756CA1F.9080202@edelweb.fr> Date: Wed, 05 Dec 2007 16:56:15 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: "Turner, Sean P." Cc: "'Paul Thorpe'" , ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756B5D7.7010407@edelweb.fr> <009701c83751$dd369680$e8f9a8c0@Wylie> In-Reply-To: <009701c83751$dd369680$e8f9a8c0@Wylie> X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 12/05/2007 04:56:14 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 12/05/2007 04:56:15 PM, Serialize complete at 12/05/2007 04:56:15 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050504080200010300090206" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms050504080200010300090206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > I like the idea of moving to the later ASN.1. The reason we've been stopped > in the past was the lack of an open source compiler. We basically have one > now with the a2c compiler. > I disagree that we were stopped by that. But that's an old story I hope > Peter - are you saying you don't want to import code, you'd rather grow your > own? If you do I'd like to see how the current syntax would break out if I > specified an elliptic curve and all it's parameters. It would be an long > sequence of 'stuff' that you'd have to write up some verbiage about the 1st > element of the sequence was this, the next this, and so on. That seems like > an unworkable solution to me. > I have made no comment about the structure of the information that this document is proposing. I just mentioned that reusing a particular name 'Algorithm' to define another but similar structure as in some other module is not a good idea, and indeed defining another thing like AlgorithmValidityInfo is better. I think you refer to some older message from me? Following your comment: Before really entering into concrete syntax, it would be good to describe what abstract information needs to be encoded and how a validator (an automatic tool!!) is supposed to operate. An important requirement to me seems that when adding something to the structure, the core validator doesn't change. Does that makes sense? P -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorite'; die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch. --------------ms050504080200010300090206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NzEyMDUxNTU2MTVaMCMGCSqGSIb3DQEJBDEWBBRcKp0lQlHpBb+YRNxtGf4CPbpewTBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYBkJZpewpR24U2PRJJthpqLVnXpEHSLDlZXTaNNLPpgXGjImJ+1EpS/VsqJ cQWVh/OQatUD/W73j0OJtBQfPX/TL042HAyMwubt4ctn3h4kDti/WwHiZjuFrzl0ymok3ThF Qg7l3txKWUgcbjtHed8OYij+LQjltFsgBuddpNKr8wAAAAAAAA== --------------ms050504080200010300090206-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5FL7QB027485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 08:21:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5FL7In027484; Wed, 5 Dec 2007 08:21:07 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB5FL5WE027475 for ; Wed, 5 Dec 2007 08:21:06 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 33517 invoked from network); 5 Dec 2007 15:21:05 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@216.18.3.1 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 5 Dec 2007 15:21:03 -0000 X-YMail-OSG: sasS60YVM1nA_JFCQKycG9.QG0l6DzeQJa3PhGNA3lqTIAxKIMWKYMM8TPrb26DXtbTFoyDkEg-- From: "Turner, Sean P." To: "'Peter Sylvester'" , "'Paul Thorpe'" Cc: References: <001201c836e7$1f82a4e0$df128182@Wylie> <4756B5D7.7010407@edelweb.fr> Subject: RE: comment on draft-ietf-ltans-dssc-01.txt Date: Wed, 5 Dec 2007 07:16:41 -0800 Organization: IECA, Inc. Message-ID: <009701c83751$dd369680$e8f9a8c0@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4756B5D7.7010407@edelweb.fr> Thread-Index: Acg3S0pgiz5lHlfCSEOf5QUbXBxltQABTdhQ Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >-----Original Message----- >From: Peter Sylvester [mailto:Peter.Sylvester@edelweb.fr] >Sent: Wednesday, December 05, 2007 6:30 AM >To: Paul Thorpe >Cc: Turner, Sean P.; ietf-ltans@imc.org >Subject: Re: comment on draft-ietf-ltans-dssc-01.txt > > > >> in 1994 and >> replaced with the "open type" which allows ASN.1 compilers to >> explicitly link the contents of the "open type" field with >the object identifier. >> >> >In other LTANS specifications the following approach is used: > >One module is specified in 'CURRENT' ASN.1 syntax. >An alternative module is done for 'old' compilers with is an >almost 88 syntax Which one is normative is still a debate (as >in another group). > >In some specs also an XSD schema is defined. For LTAP at least >the XSD is automatically generated from the ASN.1 and produces >the same encodings and an XER encoding of the ASN.1 > >Besides that and in response to Sean. > >Although a module can reuse a name that is defined in another >module, I agree that this may be confusing. > I like the idea of moving to the later ASN.1. The reason we've been stopped in the past was the lack of an open source compiler. We basically have one now with the a2c compiler. Peter - are you saying you don't want to import code, you'd rather grow your own? If you do I'd like to see how the current syntax would break out if I specified an elliptic curve and all it's parameters. It would be an long sequence of 'stuff' that you'd have to write up some verbiage about the 1st element of the sequence was this, the next this, and so on. That seems like an unworkable solution to me. spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5ETnAD022688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 07:29:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5ETn8Q022687; Wed, 5 Dec 2007 07:29:49 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ganymede.on-x.com (ganymede.on-x.com [194.51.68.3]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5ETmLT022679 for ; Wed, 5 Dec 2007 07:29:49 -0700 (MST) (envelope-from Peter.Sylvester@edelweb.fr) Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 25E3C57; Wed, 5 Dec 2007 15:29:47 +0100 (CET) Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14056-05; Wed, 5 Dec 2007 15:29:44 +0100 (CET) Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id ACA9556; Wed, 5 Dec 2007 15:29:44 +0100 (CET) Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2007120515294382:153348 ; Wed, 5 Dec 2007 15:29:43 +0100 Message-ID: <4756B5D7.7010407@edelweb.fr> Date: Wed, 05 Dec 2007 15:29:43 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Paul Thorpe Cc: "Turner, Sean P." , ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt References: <001201c836e7$1f82a4e0$df128182@Wylie> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 12/05/2007 03:29:44 PM, Serialize by Router on vinea/ON-X(Release 5.0.11 |July 24, 2002) at 12/05/2007 03:29:44 PM, Serialize complete at 12/05/2007 03:29:44 PM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030304060301000707060009" X-Virus-Scanned: by amavisd-new at on-x.com Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a cryptographically signed message in MIME format. --------------ms030304060301000707060009 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > in 1994 and > replaced with the "open type" which allows ASN.1 compilers to explicitly > link the contents of the "open type" field with the object identifier. > > In other LTANS specifications the following approach is used: One module is specified in 'CURRENT' ASN.1 syntax. An alternative module is done for 'old' compilers with is an almost 88 syntax Which one is normative is still a debate (as in another group). In some specs also an XSD schema is defined. For LTAP at least the XSD is automatically generated from the ASN.1 and produces the same encodings and an XER encoding of the ASN.1 Besides that and in response to Sean. Although a module can reuse a name that is defined in another module, I agree that this may be confusing. Peter -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorite'; die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch. --------------ms030304060301000707060009 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOhTCC BHIwggLfoAMCAQICBgqvijKA3jANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNzAzMjYxMDM3MDNaFw0wOTA2MDMxMDM3MDNaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPB7ZSfmYsUuVIV0W2izxb1Zyvr6ZJ IjPiqRMs77dbEQhQ6FZhhUSuABxxc8NjZvyPMRo0uuT0iVpRDktb0fWPTx3m9qTfdqrhWg2c IOBKNbNQr8NogDJvG1AxRx4q9SXKZCVpZCoHu3fz2Rfji1kL7l597+7qBEsFd9IyvRaexQID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSZjq81LuJmsiiu1Yt/ezwCiUQSQTAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAAUq5MJ3gXhdKDpOm0ascDE9e1iMo0RQ24ujkc9IrFXhAJNS+3eNwcJEieU2vgZTsGb zKeBZom1zVOFoh73VIRP6T08j4dDlndpDYZbxD20KzFt9zX6gV8IgR2zkkZXLQRbLyW16kw8 oFe3s//p1csCkCPAlZv1rZQYR5Psm0A1aiOiuSHhWUmgfAJxmIgfbmKtS3WpsUZVBuLQpThN rWjLRAqJKYA++++qqo3ujqAAzJLe+MHrX5dai7+n6WBfV4qo1uDArR7XbmgVpV/EdPA75XRi XEedLgbFDawJ9nAMN6WfL/NG6GZkEa7mZ7sH/gG34y21nq4w4mAAxn9wz7mDKMsEbJMZ5VlJ TOp0g6TdYqGjNoc/rQg7pqjcRChVitwd1Rl8O31+bIdNSpv4UReNMDcffRQrt+pF1FxR4q6q M9YLJU8NThx/89Mf/WF7fzrgVlsNJ78D9nJu0EhKes/9EX2qpIcHUfk/izOj8lCc1ksFgXpd UEchE0DcMIIEcjCCAt+gAwIBAgIGCq+KMoDeMA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA3MDMyNjEwMzcwM1oXDTA5MDYwMzEw MzcwM1owcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM8HtlJ+ZixS5UhXRbaL PFvVnK+vpkkiM+KpEyzvt1sRCFDoVmGFRK4AHHFzw2Nm/I8xGjS65PSJWlEOS1vR9Y9PHeb2 pN92quFaDZwg4Eo1s1Cvw2iAMm8bUDFHHir1JcpkJWlkKge7d/PZF+OLWQvuXn3v7uoESwV3 0jK9Fp7FAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJmOrzUu4mayKK7Vi397PAKJ RBJBMB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8ABSrkwneBeF0oOk6bRqxwMT17WIyjRFDbi6ORz0isVeEAk1L7d43BwkS J5Ta+BlOwZvMp4FmibXNU4WiHvdUhE/pPTyPh0OWd2kNhlvEPbQrMW33NfqBXwiBHbOSRlct BFsvJbXqTDygV7ez/+nVywKQI8CVm/WtlBhHk+ybQDVqI6K5IeFZSaB8AnGYiB9uYq1Ldamx RlUG4tClOE2taMtECokpgD7776qqje6OoADMkt74wetfl1qLv6fpYF9XiqjW4MCtHtduaBWl X8R08DvldGJcR50uBsUNrAn2cAw3pZ8v80boZmQRruZnuwf+AbfjLbWerjDiYADGf3DPuYMo ywRskxnlWUlM6nSDpN1ioaM2hz+tCDumqNxEKFWK3B3VGXw7fX5sh01Km/hRF40wNx99FCu3 6kXUXFHirqoz1gslTw1OHH/z0x/9YXt/OuBWWw0nvwP2cm7QSEp6z/0RfaqkhwdR+T+LM6Py UJzWSwWBel1QRyETQNwwggWVMIIDMKADAgECAgYKwoI0lJgwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDcwNjI4MTc0MDU0WhcNMTQwNTAyMTc0 MDU0WjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4GgMIGdMDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAfBgNV HSMEGDAWgBSo2SuP1LBnur1JXLwz/HdSEblnnTANBgkqhkiG9w0BAQUFAAOCAk4AUgtIR4Jh Ynyk939SM6X4YZPNYIgDio8Gp064P1MBILDgI/hzSwyxT5bb1qUQub+icXO9/5ufsDufr/ff 2gCzKMuo3hC26iey630PzHTvJgrTcEp9c92IZPt3UKeouqy+95Lz2r58dbfouKLZVwiKQ0jP 2c2U5tPWmzW4CAjFWUKRYlrhbt+tjzW8CAA0DHO1xrrzAuTyuGNKcH4LlLuVo7MbDPn/uLma 1fAVYvH2c6OTwGHJyKTQVveYw4UqgAhErJMFWJDKm+Q9h91mCzkjrA1Eu0nVDUTV1+dW6mNT DPLIq0qSdqP7iT2WcNzQVy/0PiXT2aaEH9lE2W1SSD6PnT8y+aqJTGjRMK1cl7VSJHxbq8U9 lIS+6eiV5VrogAa8X52pKF0u91i+/CBZ3e5Mi2/BwMrMN/mXA/ZwL3p+jZpnijpqnqdz8iCn qR9ExhR+BpN/b56RqEu7llLrcwOS44kjbubALjxe0+XutidWjt/6/tLYuM7rJ6Hk1EweFGVd kRejKogD3GzZ3gOAIF/D28VBJcTRcyF7OI/k/3jPD0gHUGN1uxk2Krz8SE9GEPvP/JehCBl/ FrQOCsEUmszi7Se0Vxr2k1P7icxT7L/AcWt/djIgp/vsQNurbi0+5+q7YS2b2bc1HchjsmaI cXy8ha5IGk4+F1qrHZsGqTm5M7TzZN6k0X2llMaozrtPzxNMC6uvf1uRvHYHf1x0Q0pdxTzZ PuuFw1PUlu6o5xPHbf3ZgC7ZNSDry13ZEXmlG2Re0u9WwEJJ1nYqlcDvNzGCAq4wggKqAgEB MGUwWzELMAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2Ug RWRlbFBLSTEgMB4GA1UEAxMXRWRlbFBLSSBFZGVsV2ViIFBlcnNHRU4CBgqvijKA3jAJBgUr DgMCGgUAoIIBnzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0w NzEyMDUxNDI5NDNaMCMGCSqGSIb3DQEJBDEWBBR6Rr9l1IjkScdg8jh2nhEbkscw+zBSBgkq hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI hvcNAQEBBQAEgYC12rJugwEGRIouWZ3irNpyT74s+d/nqt3fKX3Qs98PH0sswO58eWZzV/g3 IclC2PbZ42edzfpqFHFmIEju7OIeHdAWtN1zwr8bzT0k4ctsu2R5kDAeoPrp943a4SXJ2iNa 7Zlyv7pV63Qe3NVPNHyeEXG40OnQmXptn9DKF6CM9AAAAAAAAA== --------------ms030304060301000707060009-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5DfI2m018945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 06:41:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB5DfIbs018944; Wed, 5 Dec 2007 06:41:18 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from fortress.oss.com (fortress.oss.com [66.146.12.63]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB5DfHWf018937 for ; Wed, 5 Dec 2007 06:41:17 -0700 (MST) (envelope-from thorpe@oss.com) Received: from fortress (fortress [192.168.2.1]) by fortress.oss.com (8.13.8+Sun/8.13.8) with ESMTP id lB5Df9kE001072; Wed, 5 Dec 2007 05:41:14 -0800 (PST) Date: Wed, 5 Dec 2007 05:41:09 -0800 (PST) From: Paul Thorpe To: "Turner, Sean P." cc: ietf-ltans@imc.org Subject: Re: comment on draft-ietf-ltans-dssc-01.txt In-Reply-To: <001201c836e7$1f82a4e0$df128182@Wylie> Message-ID: References: <001201c836e7$1f82a4e0$df128182@Wylie> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 4 Dec 2007, Turner, Sean P. wrote: > > I'm only commenting on the Parameter structure in the ASN.1. I think that it > might be better to change Algorithm to be a sequence of algorithmIdentifier, > validity, and information - call it AlgorithmValidityInfo. I suggest this > for two reasons: > > 1. The AlgorithmIdentifier structure that is used to assign an algorithm's > object identifier also define the parameters. So it probably makes sense to > reuse this structure. > > 2. The parameters structures for some of the newer algorithms is quite > complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs [RFC3279] > aren't just an OID they are nested structure. > > (not sure how to do it in XML) > > Replace: > > Algorithm ::= SEQUENCE { > algorithmIdentifier AlgID, > parameters [0] SEQUENCE OF Parameter OPTIONAL, > validity [1] Validity, > information [2] SEQUENCE OF UTF8String OPTIONAL > } > > AlgID ::= SEQUENCE { > name UTF8String, > oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, > uri [1] SEQUENCE OF IA5String OPTIONAL > } > > Parameter ::= SEQUENCE { > name UTF8String, > constraint CHOICE { > exact [0] OCTET STRING, > min [1] OCTET STRING, > max [2] OCTET STRING, > range [3] Range, > other [4] OtherConstraints > } > } > > With: > > AlgorithmValidityInfo ::= SEQUENCE { > identifier AlgorithmIdentifier, > validity Validity OPTIONAL, > information Information OPTIONAL } > > Validity ::= SEQUENCE { > start [0] GeneralizedTime OPTIONAL, > end [1] GeneralizedTime OPTIONAL } > > Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String > > -- From RFC3280 > AlgorithmIdentifier ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > parameters ANY DEFINED BY algorithm OPTIONAL } > -- contains a value of the type > -- registered for use with the > -- algorithm object identifier value > > spt > The ASN.1 type "ANY DEFINED BY" was withdrawn from ASN.1 in 1994 and replaced with the "open type" which allows ASN.1 compilers to explicitly link the contents of the "open type" field with the object identifier. For example try the following: SOMECLASS ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type } AlgorithmIdentifier ::= SEQUENCE { algorithm SOMECLASS.&id ({SomeTable}), parameters SOMECLASS.&Type ({SomeTable}{@algorithm}) } SomeTable SOMECLASS ::= { { &id oid1, &Type TypeForOid1 } | { &id oid2, &Type TypeForOid2 }, ... } The bits on the wire will be identical to the old ANY DEFINED BY, but you can explicitly list the types that particular oids correspond to. An ASN.1 Tool can automatically handle this for you rather than every implementer needing to hand code the table linking the list of object identifiers to a specific ASN.1 type for the parameter. Again, the key is that the bits on the wire are identical, but good ASN.1 Tools can take advantage of the table to make programmers tasks easier and less error prone. Note that "SomeTable" can be either completely specific in the specification, or it can have rows added or removed dynamically at runtime if desired. I recommend using the "open type" instead of the "ANY DEFINED BY" which was withdrawn from ASN.1 in 1994. Paul Thorpe thorpe@oss.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB52b6vX067975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 19:37:06 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB52b6wj067974; Tue, 4 Dec 2007 19:37:06 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from smtp104.biz.mail.mud.yahoo.com (smtp104.biz.mail.mud.yahoo.com [68.142.200.252]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id lB52b5Ij067968 for ; Tue, 4 Dec 2007 19:37:05 -0700 (MST) (envelope-from turners@ieca.com) Received: (qmail 18027 invoked from network); 5 Dec 2007 02:36:59 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.18.223 with login) by smtp104.biz.mail.mud.yahoo.com with SMTP; 5 Dec 2007 02:36:59 -0000 X-YMail-OSG: IerVI18VM1ktPhv1k_u13zb68Y7dkJ4DT66EniZncgCTa1TNoqf5VxJodKkqlCvfvbRnYTPjuw-- From: "Turner, Sean P." To: Subject: comment on draft-ietf-ltans-dssc-01.txt Date: Tue, 4 Dec 2007 18:32:46 -0800 Organization: IECA, Inc. Message-ID: <001201c836e7$1f82a4e0$df128182@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg25x6PW88UK/8NRKWtWCH61Adr+A== Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm only commenting on the Parameter structure in the ASN.1. I think that it might be better to change Algorithm to be a sequence of algorithmIdentifier, validity, and information - call it AlgorithmValidityInfo. I suggest this for two reasons: 1. The AlgorithmIdentifier structure that is used to assign an algorithm's object identifier also define the parameters. So it probably makes sense to reuse this structure. 2. The parameters structures for some of the newer algorithms is quite complicated. For example, RSASSA-PSS [RFC4055] and ECC Algs [RFC3279] aren't just an OID they are nested structure. (not sure how to do it in XML) Replace: Algorithm ::= SEQUENCE { algorithmIdentifier AlgID, parameters [0] SEQUENCE OF Parameter OPTIONAL, validity [1] Validity, information [2] SEQUENCE OF UTF8String OPTIONAL } AlgID ::= SEQUENCE { name UTF8String, oid [0] SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, uri [1] SEQUENCE OF IA5String OPTIONAL } Parameter ::= SEQUENCE { name UTF8String, constraint CHOICE { exact [0] OCTET STRING, min [1] OCTET STRING, max [2] OCTET STRING, range [3] Range, other [4] OtherConstraints } } With: AlgorithmValidityInfo ::= SEQUENCE { identifier AlgorithmIdentifier, validity Validity OPTIONAL, information Information OPTIONAL } Validity ::= SEQUENCE { start [0] GeneralizedTime OPTIONAL, end [1] GeneralizedTime OPTIONAL } Information ::= SEQUENCE SIZE (1..MAX) OF UTF8String -- From RFC3280 AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } -- contains a value of the type -- registered for use with the -- algorithm object identifier value spt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB40e4Vf033291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 17:40:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id lB40e457033290; Mon, 3 Dec 2007 17:40:04 -0700 (MST) (envelope-from owner-ietf-ltans@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-ltans@mail.imc.org using -f Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lB40e2Pb033281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Dec 2007 17:40:03 -0700 (MST) (envelope-from ietf@ietf.org) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 497A332928; Tue, 4 Dec 2007 00:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IzLpS-00086j-5Y; Mon, 03 Dec 2007 19:40:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ietf-ltans@imc.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-ltans-xmlers-01.txt Message-Id: Date: Mon, 03 Dec 2007 19:40:02 -0500 Sender: owner-ietf-ltans@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF. Title : Extensible Markup Language Evidence Record Syntax Author(s) : A. Blazic, et al. Filename : draft-ietf-ltans-xmlers-01.txt Pages : 36 Date : 2007-12-03 In many scenarios, users must be able to demonstrate the (time) existence, integrity and validity of data including signed data for long or undetermined period of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence of data. ERS-XML incorporates alternative syntax and processing rules to ASN.1 ERS syntax by using XML language. 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-xmlers-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltans-xmlers-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltans-xmlers-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-12-03193448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltans-xmlers-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltans-xmlers-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-03193448.I-D\@ietf.org> --OtherAccess-- --NextPart--
The problem here I think is = that this=20 WG doesn't want to hear that. It also doesn't seem to want to embrace = that the=20 Court's are a lot smarter than they used to be. One of my partner's is actually = fighting a data=20 spoliation case in the Federal Court's in NY so I know this stuff is a = key=20 issue.