From ErnstG.Giessmann@t-systems.com Thu Oct 1 01:38:26 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50DE43A6AB1 for ; Thu, 1 Oct 2009 01:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_HEAD_HDR_XIDKEY=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTcOK7TaD0qh for ; Thu, 1 Oct 2009 01:38:25 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 5E6133A6A19 for ; Thu, 1 Oct 2009 01:38:24 -0700 (PDT) From: Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 01 Oct 2009 10:39:43 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 10:39:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Enigmail-Version: 0.96.0 X-Account-Key: account2 FCC: imap://ost2%2FGiessmann.Ernst-G%2FErnstG.Giessmann@S4DE9JSAAIG.ost.t-com.de/Sent X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0 User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) X-Mozilla-Keys: Content-class: urn:content-classes:message Date: Thu, 1 Oct 2009 10:39:43 +0200 Message-ID: <410895869A205548A19FE0746861331C041B5945@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-Identity-Key: id1 X-MS-TNEF-Correlator: Thread-Topic: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt Thread-Index: AcpCc8QjQqjrgv28TxyWM/KLKzDFjQ== References: <20090930080001.BFBB73A6A1C@core3.amsl.com><410895869A205548A19FE0746861331C041B5939@S4DE9JSAAIG.ost.t-com.de> <9DCCF5807745F9438462F1F6A66CADA4032059B465@MAILR003.mail.lan> To: X-OriginalArrivalTime: 01 Oct 2009 08:39:43.0567 (UTC) FILETIME=[B947B5F0:01CA4272] Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 08:38:26 -0000 Hi Bill and Carl, first remark: you wrote > GeneralizedTime IMHO is better than Time but such a comparison is a bit wrong, because Time is a CHOICE type and = GeneralizedTime an ASN.1 built-in type. You can always use your lovely = GeneralizedTime also with the Time type, e.g.: LTANSValidity ::=3D SEQUENCE { start [0] Time OPTIONAL, -- GeneralizedTime MAY be used end [1] Time OPTIONAL -- GeneralizedTime SHOULD be used } second: Could you really give an example of an crypto algo that "has an = indefinite end time"? And then you should include this example in your = Appendix E. Keeping in consideration the environmental destruction I guess that you = can also use for this purpose the year 2100. third: I'm not sure about my level of understanding. Could you give me an = example of cryptographic algorithm parameters (e.g. for RSA) which are = unsuitable today but will become suitable next year? Anyway you should = include such an example in your Appendix E as well. If you insist of having a start time, what about: LTANSValidity ::=3D SEQUENCE { expectedEOV GeneralizedTime,=20 beginOfValidity GeneralizedTime OPTIONAL=20 } based on a required suitability end time estimation (cf. section 1.1). Concerning your remark on Extension type definition I would like to = point out that the critical field in the RFC5280 definition is a DEFAULT = value, so you can always drop it if you wish: -- Extension ::=3D SEQUENCE { -- extnID OBJECT IDENTIFIER, -- critical BOOLEAN DEFAULT FALSE, -- extnValue OCTET STRING text proposal: There is no use case for the critical BOOLEAN field in the imported from = PKIX1Explicit88 definition of the Extension type, therefore conforming = implementations SHOULD NOT/MUST NOT include it in a Evaluation object. Even if this is not acceptable for you, you should rethink your = definition and not only the naming. IMHO the encapsulating another = structure is better then the deprecated ANY type. Regards, Ernst. Carl Wallace schrieb: > I think the name change suggestion is fine. This can be handled = during the AUTH48 period for this draft, which cleared IESG review today = as this draft addressed the last of the issues. >=20 >> -----Original Message----- >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On = Behalf >> Of Bill Russell >> Sent: Wednesday, September 30, 2009 11:39 AM >> To: ErnstG.Giessmann@t-systems.com; ltans@ietf.org >> Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >> >> I propose that we just change the name in our draft but keep the new >> definitions. For the Validity, GeneralizedTime IMHO is better than >> Time, since the current year would still code as UTCTime as part of >> that def (making it a two digit year rather than four until something >> like 2050). And, if there is no use for a criticality field, there is >> no sense in reusing that definition for extensions. >> >> -----Original Message----- >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On = Behalf >> Of ErnstG.Giessmann@t-systems.com >> Sent: Wednesday, September 30, 2009 10:11 AM >> To: ltans@ietf.org >> Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >> >> Hi all, >> there are some clashes in the ASN.1 code of the draft that prevents = to >> use it with e.g. RFC3280/RFC5280. >> >> 1. >> The Draft defines >> -- Extension ::=3D SEQUENCE { >> -- extensionType OBJECT IDENTIFIER, >> -- extension ANY DEFINED BY extensionType >> -- } >> >> which has a (presumably better defined) twin in RFC5280: >> Extension ::=3D SEQUENCE { >> extnID OBJECT IDENTIFIER, >> critical BOOLEAN DEFAULT FALSE, >> extnValue OCTET STRING >> -- contains the DER encoding of an ASN.1 value >> -- corresponding to the extension type identified >> -- by extnID >> } >> >> I suggest to import the type Extension from PKIX1Explicit88. Please >> take into account that already since 1997 the ASN.1 types ANY/ANY >> DEFINED BY are deprecated (http://www.itu.int/ITU- >> T/studygroups/com07/changing-ASN.html). >> >> >> 2. >> The Draft defines >> -- Validity ::=3D SEQUENCE { >> -- start [0] GeneralizedTime OPTIONAL, >> -- end [1] GeneralizedTime OPTIONAL >> -- } >> >> which clashes also with a twin in RFC3280/RFC5280: >> >> Validity ::=3D SEQUENCE { >> notBefore Time, >> notAfter Time } >> >> It seems to me that this is based on a misunderstanding already in >> section 1.1 (Motivation) >> >> Cryptographic algorithms that are used in signatures shall be >> selected to resist such attacks during their period of use. For >> signature keys included in public key certificates, it is the >> validity period of the certificate. Cryptographic algorithms that >> are used for encryption shall resist during the time during which = it >> is planned to keep the information confidential. >> >> The validity period of a certificate is primarily *not* a period = where >> resistance against attacks is assured but "is the time interval = during >> which the CA warrants that it will maintain information about the >> status of the certificate". If the signatures are made in a >> authentication context, then the validity is almost the same as the >> usage time. But if the signatures are related to a non-repudiation >> context then the documented in the certificate validity time may be >> longer then predicted at time of certificate generation. If the >> algorithm becomes weaker then the certificate can be easily revoked, >> which reduces the "usage time" immediately, leaving the "warranty = time" >> unchanged. If on the other side it turned out that the algorithm is >> harder than predicted, it is not necessary to revoke the certificate >> based on a still secure algorithm. >> >> Just another thought: For a certificate the dates notBefore and >> notAfter make sense. But how we understand the notBefore date for >> algorithm resistance? A certificate may become valid later, but how a >> weak algorithm may become hard after a while? >> >> I would suggest to remove the Validity type and replace it by a = single >> notAfter date. >> >> Regards, >> Ernst. >> -- >> Ernst G Giessmann >> T-Systems Enterprise Services GmbH >> ICT Operations >> Security and Smart Card Solutions >> Goslarer Ufer 35, D-10589 Berlin >> tel:+49-30-3497-4342 >> >> Legal Notice >> T-Systems Enterprise Services GmbH >> Supervisory Board: Ren=E9 Obermann (Chairman) >> Executive Committee: Reinhard Clemens (Chairman), >> Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack, >> Dr. Matthias Schuster, Klaus Werner >> >> Commercial Register: Amtsgericht Frankfurt am Main, HRB 55933 >> Registered Office: Frankfurt am Main >> WEEE-Reg.-No. DE87523644 >> >> Importante Notice: >> If you received this transmittal in error, please notify us >> immediately, and delete this message and its attachments. >> Thank you. >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] >>> Im Auftrag von Internet-Drafts@ietf.org >>> Gesendet: Mittwoch, 30. September 2009 10:00 >>> An: i-d-announce@ietf.org >>> Cc: ltans@ietf.org >>> Betreff: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. >>> This draft is a work item of the Long-Term Archive and Notary >>> Services Working Group of the IETF. >>> >>> >>> Title : Data Structure for the Security >>> Suitability of Cryptographic Algorithms (DSSC) >>> Author(s) : T. Kunz, et al. >>> Filename : draft-ietf-ltans-dssc-12.txt >>> Pages : 48 >>> Date : 2009-09-30 >>> >>> Since cryptographic algorithms can become weak over the >>> years, it is necessary to evaluate their security >>> suitability. When signing or verifying data, or when >>> encrypting or decrypting data, these evaluations must be >>> considered. This document specifies a data structure that >>> enables an automated analysis of the security suitability of >>> a given cryptographic algorithm at a given point of time >>> which may be in the past, at the present time or in the >>> future.Conventions used in this document >> ... >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-12.txt >> ... >> _______________________________________________ >> ltans mailing list >> ltans@ietf.org >> https://www.ietf.org/mailman/listinfo/ltans >> _______________________________________________ >> ltans mailing list >> ltans@ietf.org >> https://www.ietf.org/mailman/listinfo/ltans From cwallace@cygnacom.com Thu Oct 1 05:08:35 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E882E28DA77 for ; Thu, 1 Oct 2009 05:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.79 X-Spam-Level: X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP3LR4V2LF54 for ; Thu, 1 Oct 2009 05:08:25 -0700 (PDT) Received: from p03c11o141.symantecmail.net (p03c11o141.symantecmail.net [208.65.144.84]) by core3.amsl.com (Postfix) with ESMTP id 2EB0C28E020 for ; Thu, 1 Oct 2009 05:02:25 -0700 (PDT) Received: from unknown [65.242.48.5] (EHLO p03c11o141.symantecmail.net) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 6aa94ca4.2130455472.104316.00-507.p03c11o141.symantecmail.net (envelope-from ); Thu, 01 Oct 2009 06:03:50 -0600 (MDT) Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o141.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 4aa94ca4.2256333744.104307.00-014.p03c11o141.symantecmail.net (envelope-from ); Thu, 01 Oct 2009 06:03:48 -0600 (MDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 1 Oct 2009 08:03:46 -0400 Message-ID: In-Reply-To: <410895869A205548A19FE0746861331C041B5945@S4DE9JSAAIG.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt Thread-Index: AcpCc8QjQqjrgv28TxyWM/KLKzDFjQAF6GpA References: <20090930080001.BFBB73A6A1C@core3.amsl.com><410895869A205548A19FE0746861331C041B5939@S4DE9JSAAIG.ost.t-com.de><9DCCF5807745F9438462F1F6A66CADA4032059B465@MAILR003.mail.lan> <410895869A205548A19FE0746861331C041B5945@S4DE9JSAAIG.ost.t-com.de> From: "Carl Wallace" To: , X-Spam: [F=0.2000000000; S=0.200(2009092101)] X-MAIL-FROM: X-SOURCE-IP: [65.242.48.5] Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 12:08:35 -0000 Re: time values, omitting UTCTime as an option seems fine to me. Why do = we need two options here? Re: extension values, I don't see any benefit to importing Extension = from the PKIX module so we can include a field that must always take its = default value and use an OCTET STRING hole instead of ANY. The = normative DSSC module uses an information object class; the ANY is there = only in a module included as a courtesy to folks working with old ASN1 = compilers. =20 Given no great need to include UTCTime nor an extension structure that = includes a field that is not needed, renaming to avoid possible = confusion seems sufficient. =20 Your suggestions regarding alternative arrangement of OPTIONAL fields = for validity were options, but the spec features two OPTIONAL fields. = You can choose to always include an end time in your policies. The = start time is not of use in the scenario you give - i.e. parameters that = become valid tomorrow - but help one decide what to do with an RSA = signature purportedly generated in 1947:-) =20 > -----Original Message----- > From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf > Of ErnstG.Giessmann@t-systems.com > Sent: Thursday, October 01, 2009 4:40 AM > To: ltans@ietf.org > Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >=20 > Hi Bill and Carl, >=20 > first remark: > you wrote > > GeneralizedTime IMHO is better than Time >=20 > but such a comparison is a bit wrong, because Time is a CHOICE type = and > GeneralizedTime an ASN.1 built-in type. You can always use your lovely > GeneralizedTime also with the Time type, e.g.: >=20 > LTANSValidity ::=3D SEQUENCE { > start [0] Time OPTIONAL, -- GeneralizedTime MAY be used > end [1] Time OPTIONAL -- GeneralizedTime SHOULD be used > } >=20 > second: > Could you really give an example of an crypto algo that "has an > indefinite end time"? And then you should include this example in your > Appendix E. > Keeping in consideration the environmental destruction I guess that = you > can also use for this purpose the year 2100. >=20 > third: > I'm not sure about my level of understanding. Could you give me an > example of cryptographic algorithm parameters (e.g. for RSA) which are > unsuitable today but will become suitable next year? Anyway you should > include such an > example in your Appendix E as well. >=20 > If you insist of having a start time, what about: >=20 > LTANSValidity ::=3D SEQUENCE { > expectedEOV GeneralizedTime, > beginOfValidity GeneralizedTime OPTIONAL > } >=20 > based on a required suitability end time estimation (cf. section 1.1). >=20 > Concerning your remark on Extension type definition I would like to > point out that the critical field in the RFC5280 definition is a > DEFAULT value, so you can always drop it if you wish: >=20 > -- Extension ::=3D SEQUENCE { > -- extnID OBJECT IDENTIFIER, > -- critical BOOLEAN DEFAULT FALSE, > -- extnValue OCTET STRING >=20 > text proposal: >=20 > There is no use case for the critical BOOLEAN field in the imported > from PKIX1Explicit88 definition of the Extension type, therefore > conforming implementations SHOULD NOT/MUST NOT include it in a > Evaluation object. >=20 > Even if this is not acceptable for you, you should rethink your > definition and not only the naming. IMHO the encapsulating another > structure is better then the deprecated ANY type. >=20 > Regards, > Ernst. >=20 >=20 > Carl Wallace schrieb: > > I think the name change suggestion is fine. This can be handled > during the AUTH48 period for this draft, which cleared IESG review > today as this draft addressed the last of the issues. > > > >> -----Original Message----- > >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On > Behalf > >> Of Bill Russell > >> Sent: Wednesday, September 30, 2009 11:39 AM > >> To: ErnstG.Giessmann@t-systems.com; ltans@ietf.org > >> Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt > >> > >> I propose that we just change the name in our draft but keep the = new > >> definitions. For the Validity, GeneralizedTime IMHO is better than > >> Time, since the current year would still code as UTCTime as part of > >> that def (making it a two digit year rather than four until > something > >> like 2050). And, if there is no use for a criticality field, there > is > >> no sense in reusing that definition for extensions. > >> > >> -----Original Message----- > >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On > Behalf > >> Of ErnstG.Giessmann@t-systems.com > >> Sent: Wednesday, September 30, 2009 10:11 AM > >> To: ltans@ietf.org > >> Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt > >> > >> Hi all, > >> there are some clashes in the ASN.1 code of the draft that prevents > to > >> use it with e.g. RFC3280/RFC5280. > >> > >> 1. > >> The Draft defines > >> -- Extension ::=3D SEQUENCE { > >> -- extensionType OBJECT IDENTIFIER, > >> -- extension ANY DEFINED BY extensionType > >> -- } > >> > >> which has a (presumably better defined) twin in RFC5280: > >> Extension ::=3D SEQUENCE { > >> extnID OBJECT IDENTIFIER, > >> critical BOOLEAN DEFAULT FALSE, > >> extnValue OCTET STRING > >> -- contains the DER encoding of an ASN.1 value > >> -- corresponding to the extension type identified > >> -- by extnID > >> } > >> > >> I suggest to import the type Extension from PKIX1Explicit88. Please > >> take into account that already since 1997 the ASN.1 types ANY/ANY > >> DEFINED BY are deprecated (http://www.itu.int/ITU- > >> T/studygroups/com07/changing-ASN.html). > >> > >> > >> 2. > >> The Draft defines > >> -- Validity ::=3D SEQUENCE { > >> -- start [0] GeneralizedTime OPTIONAL, > >> -- end [1] GeneralizedTime OPTIONAL > >> -- } > >> > >> which clashes also with a twin in RFC3280/RFC5280: > >> > >> Validity ::=3D SEQUENCE { > >> notBefore Time, > >> notAfter Time } > >> > >> It seems to me that this is based on a misunderstanding already in > >> section 1.1 (Motivation) > >> > >> Cryptographic algorithms that are used in signatures shall be > >> selected to resist such attacks during their period of use. For > >> signature keys included in public key certificates, it is the > >> validity period of the certificate. Cryptographic algorithms > that > >> are used for encryption shall resist during the time during = which > it > >> is planned to keep the information confidential. > >> > >> The validity period of a certificate is primarily *not* a period > where > >> resistance against attacks is assured but "is the time interval > during > >> which the CA warrants that it will maintain information about the > >> status of the certificate". If the signatures are made in a > >> authentication context, then the validity is almost the same as the > >> usage time. But if the signatures are related to a non-repudiation > >> context then the documented in the certificate validity time may be > >> longer then predicted at time of certificate generation. If the > >> algorithm becomes weaker then the certificate can be easily = revoked, > >> which reduces the "usage time" immediately, leaving the "warranty > time" > >> unchanged. If on the other side it turned out that the algorithm is > >> harder than predicted, it is not necessary to revoke the = certificate > >> based on a still secure algorithm. > >> > >> Just another thought: For a certificate the dates notBefore and > >> notAfter make sense. But how we understand the notBefore date for > >> algorithm resistance? A certificate may become valid later, but how > a > >> weak algorithm may become hard after a while? > >> > >> I would suggest to remove the Validity type and replace it by a > single > >> notAfter date. > >> > >> Regards, > >> Ernst. > >> -- > >> Ernst G Giessmann > >> T-Systems Enterprise Services GmbH > >> ICT Operations > >> Security and Smart Card Solutions > >> Goslarer Ufer 35, D-10589 Berlin > >> tel:+49-30-3497-4342 > >> > >> Legal Notice > >> T-Systems Enterprise Services GmbH > >> Supervisory Board: Ren=E9 Obermann (Chairman) > >> Executive Committee: Reinhard Clemens (Chairman), > >> Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack, > >> Dr. Matthias Schuster, Klaus Werner > >> > >> Commercial Register: Amtsgericht Frankfurt am Main, HRB 55933 > >> Registered Office: Frankfurt am Main > >> WEEE-Reg.-No. DE87523644 > >> > >> Importante Notice: > >> If you received this transmittal in error, please notify us > >> immediately, and delete this message and its attachments. > >> Thank you. > >> > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] > >>> Im Auftrag von Internet-Drafts@ietf.org > >>> Gesendet: Mittwoch, 30. September 2009 10:00 > >>> An: i-d-announce@ietf.org > >>> Cc: ltans@ietf.org > >>> Betreff: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt > >>> > >>> A New Internet-Draft is available from the on-line > >>> Internet-Drafts directories. > >>> This draft is a work item of the Long-Term Archive and Notary > >>> Services Working Group of the IETF. > >>> > >>> > >>> Title : Data Structure for the Security > >>> Suitability of Cryptographic Algorithms (DSSC) > >>> Author(s) : T. Kunz, et al. > >>> Filename : draft-ietf-ltans-dssc-12.txt > >>> Pages : 48 > >>> Date : 2009-09-30 > >>> > >>> Since cryptographic algorithms can become weak over the > >>> years, it is necessary to evaluate their security > >>> suitability. When signing or verifying data, or when > >>> encrypting or decrypting data, these evaluations must be > >>> considered. This document specifies a data structure that > >>> enables an automated analysis of the security suitability of > >>> a given cryptographic algorithm at a given point of time > >>> which may be in the past, at the present time or in the > >>> future.Conventions used in this document > >> ... > >>> A URL for this Internet-Draft is: > >>> http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-12.txt > >> ... > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org > >> https://www.ietf.org/mailman/listinfo/ltans > >> _______________________________________________ > >> ltans mailing list > >> ltans@ietf.org > >> https://www.ietf.org/mailman/listinfo/ltans >=20 >=20 > _______________________________________________ > ltans mailing list > ltans@ietf.org > https://www.ietf.org/mailman/listinfo/ltans From brussell@pericore.com Thu Oct 1 07:12:18 2009 Return-Path: X-Original-To: ltans@core3.amsl.com Delivered-To: ltans@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7562A3A68D5 for ; Thu, 1 Oct 2009 07:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.773 X-Spam-Level: X-Spam-Status: No, score=-3.773 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ilkNu2L1xpw for ; Thu, 1 Oct 2009 07:12:16 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 643F53A6405 for ; Thu, 1 Oct 2009 07:12:16 -0700 (PDT) Received: from BH003.mail.lan ([10.110.21.103]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 10:13:41 -0400 Received: from HUB023.mail.lan ([10.110.17.23]) by BH003.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 10:13:40 -0400 Received: from MAILR003.mail.lan ([10.110.18.20]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Thu, 1 Oct 2009 10:13:40 -0400 From: Bill Russell To: "ErnstG.Giessmann@t-systems.com" , "ltans@ietf.org" Date: Thu, 1 Oct 2009 10:13:50 -0400 Thread-Topic: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt Thread-Index: AcpCc8QjQqjrgv28TxyWM/KLKzDFjQALE+9A Message-ID: <9DCCF5807745F9438462F1F6A66CADA4032059B596@MAILR003.mail.lan> References: <20090930080001.BFBB73A6A1C@core3.amsl.com><410895869A205548A19FE0746861331C041B5939@S4DE9JSAAIG.ost.t-com.de> <9DCCF5807745F9438462F1F6A66CADA4032059B465@MAILR003.mail.lan> <410895869A205548A19FE0746861331C041B5945@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <410895869A205548A19FE0746861331C041B5945@S4DE9JSAAIG.ost.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Oct 2009 14:13:40.0505 (UTC) FILETIME=[6039D090:01CA42A1] Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt X-BeenThere: ltans@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LTANS Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 14:12:18 -0000 Hi Ernst, Thanks for your insight, but the thing to keep in mind is that behind the d= efinition is also a common usage of that definition. So, while technically = Time is a CHOICE, the practice of which choice to make is defined in RFC 32= 80 (at least in terms of validity). While RFC 3280's use of Time does not b= ind us, it's easier to avoid the confusion. See below from RFC 3280. 4.1.2.5 Validity <...> CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime. <...> By selecting GeneralizedTime, we erase the ambiguity. RFC 3280's usage of T= ime I believe is one of legacy, because I imagine most would prefer a 4 dig= it year after Y2K. Take care, Bill -----Original Message----- From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf Of E= rnstG.Giessmann@t-systems.com Sent: Thursday, October 01, 2009 4:40 AM To: ltans@ietf.org Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt Hi Bill and Carl, first remark: you wrote > GeneralizedTime IMHO is better than Time but such a comparison is a bit wrong, because Time is a CHOICE type and Gen= eralizedTime an ASN.1 built-in type. You can always use your lovely General= izedTime also with the Time type, e.g.: LTANSValidity ::=3D SEQUENCE { start [0] Time OPTIONAL, -- GeneralizedTime MAY be used end [1] Time OPTIONAL -- GeneralizedTime SHOULD be used } second: Could you really give an example of an crypto algo that "has an indefinite = end time"? And then you should include this example in your Appendix E. Keeping in consideration the environmental destruction I guess that you can= also use for this purpose the year 2100. third: I'm not sure about my level of understanding. Could you give me an example = of cryptographic algorithm parameters (e.g. for RSA) which are unsuitable t= oday but will become suitable next year? Anyway you should include such an example in your Appendix E as well. If you insist of having a start time, what about: LTANSValidity ::=3D SEQUENCE { expectedEOV GeneralizedTime,=20 beginOfValidity GeneralizedTime OPTIONAL=20 } based on a required suitability end time estimation (cf. section 1.1). Concerning your remark on Extension type definition I would like to point o= ut that the critical field in the RFC5280 definition is a DEFAULT value, so= you can always drop it if you wish: -- Extension ::=3D SEQUENCE { -- extnID OBJECT IDENTIFIER, -- critical BOOLEAN DEFAULT FALSE, -- extnValue OCTET STRING text proposal: There is no use case for the critical BOOLEAN field in the imported from PK= IX1Explicit88 definition of the Extension type, therefore conforming implem= entations SHOULD NOT/MUST NOT include it in a Evaluation object. Even if this is not acceptable for you, you should rethink your definition = and not only the naming. IMHO the encapsulating another structure is better= then the deprecated ANY type. Regards, Ernst. Carl Wallace schrieb: > I think the name change suggestion is fine. This can be handled during t= he AUTH48 period for this draft, which cleared IESG review today as this dr= aft addressed the last of the issues. >=20 >> -----Original Message----- >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf >> Of Bill Russell >> Sent: Wednesday, September 30, 2009 11:39 AM >> To: ErnstG.Giessmann@t-systems.com; ltans@ietf.org >> Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >> >> I propose that we just change the name in our draft but keep the new >> definitions. For the Validity, GeneralizedTime IMHO is better than >> Time, since the current year would still code as UTCTime as part of >> that def (making it a two digit year rather than four until something >> like 2050). And, if there is no use for a criticality field, there is >> no sense in reusing that definition for extensions. >> >> -----Original Message----- >> From: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] On Behalf >> Of ErnstG.Giessmann@t-systems.com >> Sent: Wednesday, September 30, 2009 10:11 AM >> To: ltans@ietf.org >> Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >> >> Hi all, >> there are some clashes in the ASN.1 code of the draft that prevents to >> use it with e.g. RFC3280/RFC5280. >> >> 1. >> The Draft defines >> -- Extension ::=3D SEQUENCE { >> -- extensionType OBJECT IDENTIFIER, >> -- extension ANY DEFINED BY extensionType >> -- } >> >> which has a (presumably better defined) twin in RFC5280: >> Extension ::=3D SEQUENCE { >> extnID OBJECT IDENTIFIER, >> critical BOOLEAN DEFAULT FALSE, >> extnValue OCTET STRING >> -- contains the DER encoding of an ASN.1 value >> -- corresponding to the extension type identified >> -- by extnID >> } >> >> I suggest to import the type Extension from PKIX1Explicit88. Please >> take into account that already since 1997 the ASN.1 types ANY/ANY >> DEFINED BY are deprecated (http://www.itu.int/ITU- >> T/studygroups/com07/changing-ASN.html). >> >> >> 2. >> The Draft defines >> -- Validity ::=3D SEQUENCE { >> -- start [0] GeneralizedTime OPTIONAL, >> -- end [1] GeneralizedTime OPTIONAL >> -- } >> >> which clashes also with a twin in RFC3280/RFC5280: >> >> Validity ::=3D SEQUENCE { >> notBefore Time, >> notAfter Time } >> >> It seems to me that this is based on a misunderstanding already in >> section 1.1 (Motivation) >> >> Cryptographic algorithms that are used in signatures shall be >> selected to resist such attacks during their period of use. For >> signature keys included in public key certificates, it is the >> validity period of the certificate. Cryptographic algorithms that >> are used for encryption shall resist during the time during which it >> is planned to keep the information confidential. >> >> The validity period of a certificate is primarily *not* a period where >> resistance against attacks is assured but "is the time interval during >> which the CA warrants that it will maintain information about the >> status of the certificate". If the signatures are made in a >> authentication context, then the validity is almost the same as the >> usage time. But if the signatures are related to a non-repudiation >> context then the documented in the certificate validity time may be >> longer then predicted at time of certificate generation. If the >> algorithm becomes weaker then the certificate can be easily revoked, >> which reduces the "usage time" immediately, leaving the "warranty time" >> unchanged. If on the other side it turned out that the algorithm is >> harder than predicted, it is not necessary to revoke the certificate >> based on a still secure algorithm. >> >> Just another thought: For a certificate the dates notBefore and >> notAfter make sense. But how we understand the notBefore date for >> algorithm resistance? A certificate may become valid later, but how a >> weak algorithm may become hard after a while? >> >> I would suggest to remove the Validity type and replace it by a single >> notAfter date. >> >> Regards, >> Ernst. >> -- >> Ernst G Giessmann >> T-Systems Enterprise Services GmbH >> ICT Operations >> Security and Smart Card Solutions >> Goslarer Ufer 35, D-10589 Berlin >> tel:+49-30-3497-4342 >> >> Legal Notice >> T-Systems Enterprise Services GmbH >> Supervisory Board: Ren=E9 Obermann (Chairman) >> Executive Committee: Reinhard Clemens (Chairman), >> Dr. Ferri Abolhassan, Olaf Heyden, Joachim Langmack, >> Dr. Matthias Schuster, Klaus Werner >> >> Commercial Register: Amtsgericht Frankfurt am Main, HRB 55933 >> Registered Office: Frankfurt am Main >> WEEE-Reg.-No. DE87523644 >> >> Importante Notice: >> If you received this transmittal in error, please notify us >> immediately, and delete this message and its attachments. >> Thank you. >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: ltans-bounces@ietf.org [mailto:ltans-bounces@ietf.org] >>> Im Auftrag von Internet-Drafts@ietf.org >>> Gesendet: Mittwoch, 30. September 2009 10:00 >>> An: i-d-announce@ietf.org >>> Cc: ltans@ietf.org >>> Betreff: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt >>> >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. >>> This draft is a work item of the Long-Term Archive and Notary >>> Services Working Group of the IETF. >>> >>> >>> Title : Data Structure for the Security >>> Suitability of Cryptographic Algorithms (DSSC) >>> Author(s) : T. Kunz, et al. >>> Filename : draft-ietf-ltans-dssc-12.txt >>> Pages : 48 >>> Date : 2009-09-30 >>> >>> Since cryptographic algorithms can become weak over the >>> years, it is necessary to evaluate their security >>> suitability. When signing or verifying data, or when >>> encrypting or decrypting data, these evaluations must be >>> considered. This document specifies a data structure that >>> enables an automated analysis of the security suitability of >>> a given cryptographic algorithm at a given point of time >>> which may be in the past, at the present time or in the >>> future.Conventions used in this document >> ... >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-12.txt >> ... >> _______________________________________________ >> ltans mailing list >> ltans@ietf.org >> https://www.ietf.org/mailman/listinfo/ltans >> _______________________________________________ >> ltans mailing list >> ltans@ietf.org >> https://www.ietf.org/mailman/listinfo/ltans _______________________________________________ ltans mailing list ltans@ietf.org https://www.ietf.org/mailman/listinfo/ltans