Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt
Bill Russell <brussell@pericore.com> Wed, 30 September 2009 15:37 UTC
Return-Path: <brussell@pericore.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 82BDB3A6898 for <ltans@core3.amsl.com>; Wed, 30 Sep 2009 08:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.802
X-Spam-Level:
X-Spam-Status: No, score=-3.802 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQVq3qCnz3fE for <ltans@core3.amsl.com>; Wed, 30 Sep 2009 08:37:53 -0700 (PDT)
Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 1A2E23A67BD for <ltans@ietf.org>; Wed, 30 Sep 2009 08:37:52 -0700 (PDT)
Received: from BH001.mail.lan ([10.110.21.101]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 11:39:15 -0400
Received: from HUB010.mail.lan ([10.110.17.10]) by BH001.mail.lan with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 11:39:06 -0400
Received: from HUB014.mail.lan (10.110.17.14) by HUB010.mail.lan (10.110.17.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 30 Sep 2009 11:39:06 -0400
Received: from MAILR003.mail.lan ([10.110.18.20]) by HUB014.mail.lan ([10.110.17.14]) with mapi; Wed, 30 Sep 2009 11:39:05 -0400
From: Bill Russell <brussell@pericore.com>
To: "ErnstG.Giessmann@t-systems.com" <ErnstG.Giessmann@t-systems.com>, "ltans@ietf.org" <ltans@ietf.org>
Date: Wed, 30 Sep 2009 11:39:11 -0400
Thread-Topic: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt
Thread-Index: AcpBvNy1JYJ+//k+TGih5sVPz/rGlgAEiLmwAAUm2LA=
Message-ID: <9DCCF5807745F9438462F1F6A66CADA4032059B465@MAILR003.mail.lan>
References: <20090930080001.BFBB73A6A1C@core3.amsl.com> <410895869A205548A19FE0746861331C041B5939@S4DE9JSAAIG.ost.t-com.de>
In-Reply-To: <410895869A205548A19FE0746861331C041B5939@S4DE9JSAAIG.ost.t-com.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Sep 2009 15:39:06.0253 (UTC) FILETIME=[24FF23D0:01CA41E4]
Subject: Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.txt
X-BeenThere: ltans@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LTANS Working Group <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: Wed, 30 Sep 2009 15:37:54 -0000
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] I-D Action:draft-ietf-ltans-dssc-12.txt Internet-Drafts
- Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.t… ErnstG.Giessmann
- Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.t… Bill Russell
- Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.t… Carl Wallace
- Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.t… ErnstG.Giessmann
- Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.t… Carl Wallace
- Re: [ltans] I-D Action:draft-ietf-ltans-dssc-12.t… Bill Russell