Re: this document may of interest to PKIX members

Russ Housley <housley@vigilsec.com> Tue, 03 February 2009 16:18 UTC

Return-Path: <owner-ietf-pkix@mail.imc.org>
X-Original-To: ietfarch-pkix-archive@core3.amsl.com
Delivered-To: ietfarch-pkix-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D1428C121 for <ietfarch-pkix-archive@core3.amsl.com>; Tue, 3 Feb 2009 08:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.376
X-Spam-Level:
X-Spam-Status: No, score=-101.376 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100]
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 bbDFNmVAXB1r for <ietfarch-pkix-archive@core3.amsl.com>; Tue, 3 Feb 2009 08:18:11 -0800 (PST)
Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2C1DA28C10E for <pkix-archive@ietf.org>; Tue, 3 Feb 2009 08:18:10 -0800 (PST)
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n13Flhcr022305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 08:47:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n13Flhl5022304; Tue, 3 Feb 2009 08:47:43 -0700 (MST) (envelope-from owner-ietf-pkix@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n13FlWIJ022278 for <ietf-pkix@imc.org>; Tue, 3 Feb 2009 08:47:42 -0700 (MST) (envelope-from housley@vigilsec.com)
Message-Id: <200902031547.n13FlWIJ022278@balder-227.proper.com>
Received: (qmail 9726 invoked by uid 0); 3 Feb 2009 15:47:28 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.24) by woodstock.binhost.com with SMTP; 3 Feb 2009 15:47:28 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 03 Feb 2009 10:28:29 -0500
To: denis.pinkas@bull.net
From: Russ Housley <housley@vigilsec.com>
Subject: Re: this document may of interest to PKIX members
Cc: ietf-pkix@imc.org
In-Reply-To: <DreamMail__110301_48833121452@msga-001.frcl.bull.fr>
References: <p06240813c59fe948e2a5@[192.168.1.4]> <DreamMail__110301_48833121452@msga-001.frcl.bull.fr>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>

This document is a direct submission to the RFC Editor as part of the Independent Submission Stream.  It is not a product of the IETF.  The role of the IESG in such documents is to ensure that they are not en end-run around the IETF Standards Process.  This one is not.

Please send technical comments to the RFC Editor directly at rfc-editor@rfc-editor.org.

Russ


At 05:03 AM 2/3/2009, Denis Pinkas wrote:
 
I have some concerns to publish draft-santoni-timestampeddata-04.txt as an Informational RFC.
 
At present, the document has several major problems:
 
a) it does not contains any ASN.1 module at the end for the definition of TimeStampedData,
 
b) the definition of TimeStampedData does not allow a compiler to process it correctly
    (i.e. Evidence cannot compile correctly).
 
c) the definition of TimeStampedData should be modifed to allow the inclusion
    of the possible locations of the time-stamped file (i.e. hints about the location).
 
d) its scope should be targeted to time-stamp tokens and not be extended to
    "additional types of evidences to be registred with the IETF".
 
e) extending the validity of TimeStampedData should be addressed or discussed.
 
This document should also be redirected on the standard track, since it defines a new smime type
and thus should  be discussed at the WG level.
 
If it is agreed to consider the document at the standard track level,
I would consider to co-edit the document.
 
Denis
 
----- Message reçu -----
De : owner-ietf-pkix
À : ietf-pkix
Date : 2009-01-23, 22:38:42
Sujet : this document may of interest to PKIX members

>
>
>The IESG has no problem with the publication of 'Syntax for binding
>documents with time stamps' <draft-santoni-timestampeddata-04.txt> as an
>Informational RFC.
>
>The IESG would also like the IRSG or RFC-Editor to review the comments in
>
>the datatracker
>(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16302&rfc_flag=0" rel="nofollow"> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16302&rfc_flag=0 )
>related to this document and determine whether or not they merit
>incorporation into the document. Comments may exist in both the ballot
>and the comment log.
>
>The IESG contact person is Tim Polk.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-santoni-timestampeddata-04.txt" rel="nofollow"> http://www.ietf.org/internet-drafts/draft-santoni-timestampeddata-04.txt
>
>
>The process for such documents is described at
>http://www.rfc-editor.org/indsubs.html." rel="nofollow"> http://www.rfc-editor.org/indsubs.html.
>
>Thank you,
>
>The IESG Secretary
>
>Technical Summary
>
> This document describes a syntax which can be used to bind a generic
> document (or any set of data, not necessarily protected by means of
> cryptographic techniques) to one or more time-stamp tokens obtained
> for that document, where "time-stamp token" has the meaning defined
> in RFC 3161. Additional types of temporal evidence are also
> supported.
>
>Working Group Summary
>
> This document is not the product of any IETF WG.
>
>Protocol Quality
>
> The documents were reviewed by Tim Polk for the IESG. Carl Wallace
> also reviewed the document for conflicts with the LTANS working group.
>
>RFC Editor Note
>
> The IESG thinks that this work is related to IETF work done in the
> Long-Term Archive and Notary Services (ltans) WG, but this does not
> prevent publishing.
>
>IESG Note
>
> This RFC is not a candidate for any level of Internet Standard.
> The IETF disclaims any knowledge of the fitness of this RFC for
> any purpose and notes that the decision to publish is not based on
> IETF review apart from IESG review for conflict with IETF work. The
> standards track specification RFC 4998, Evidence Record Syntax (ERS),
> specifies an alternative mechanism. Readers are encouraged to also
> review RFC 4998 when evaluating the suitability of this mechanism.
> The RFC Editor has chosen to publish this document at its
> discretion. See RFC 3932 for more information.
>
>_______________________________________________
>IETF-Announce mailing list
> IETF-Announce@ietf.org
>https://www.ietf.org/mailman/listinfo/ietf-announce" rel="nofollow"> https://www.ietf.org/mailman/listinfo/ietf-announce