Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt

"Carl Wallace" <CWallace@cygnacom.com> Thu, 01 October 2009 12:08 UTC

Return-Path: <cwallace@cygnacom.com>
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 <ltans@core3.amsl.com>; 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 <ltans@core3.amsl.com>; 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 <ltans@ietf.org>; 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 <cwallace@cygnacom.com>); 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 <cwallace@cygnacom.com>); 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: <FAD1CF17F2A45B43ADE04E140BA83D48D2D138@scygexch1.cygnacom.com>
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><FAD1CF17F2A45B43ADE04E140BA83D48D2D0EA@scygexch1.cygnacom.com> <410895869A205548A19FE0746861331C041B5945@S4DE9JSAAIG.ost.t-com.de>
From: "Carl Wallace" <CWallace@cygnacom.com>
To: <ErnstG.Giessmann@t-systems.com>, <ltans@ietf.org>
X-Spam: [F=0.2000000000; S=0.200(2009092101)]
X-MAIL-FROM: <cwallace@cygnacom.com>
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 <ltans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltans>, <mailto:ltans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltans>
List-Post: <mailto:ltans@ietf.org>
List-Help: <mailto:ltans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltans>, <mailto:ltans-request@ietf.org?subject=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.  

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.  

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:-)  

> -----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
> 
> 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 ::= 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 ::= SEQUENCE {
>    expectedEOV     GeneralizedTime,
>    beginOfValidity GeneralizedTime OPTIONAL
>    }
> 
> 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  ::=  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.
> >
> >> -----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 ::= SEQUENCE {
> >> --   extensionType           OBJECT IDENTIFIER,
> >> --   extension               ANY DEFINED BY extensionType
> >> --   }
> >>
> >> which has a (presumably better defined) twin in RFC5280:
> >> Extension  ::=  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 ::= SEQUENCE {
> >> --   start  [0] GeneralizedTime OPTIONAL,
> >> --   end    [1] GeneralizedTime OPTIONAL
> >> --   }
> >>
> >> which clashes also with a twin in RFC3280/RFC5280:
> >>
> >> Validity ::= 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é 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üngliche 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