Subject: Re: this document may of interest to PKIX members

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 3 Feb 2009 11:03:01 +0100

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)
>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
>
>
>The process for such documents is described at
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Russ Housley <[email-masked]>
Date: Tue, 03 Feb 2009 10:28:29 -0500

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
[email-masked].

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.

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

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

Denis

----- Message reçu -----

De :
owner-ietf-pkix

À : ietf-pkix

>documents with time stamps'
<draft-santoni-timestampeddata-04.txt> as an

>(
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16302&rfc_flag=0
)

[email-masked]

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 11 Feb 2009 17:33:38 +0100

Just taking two specific things (mimetype and filename)
into a fixed structure seem rather restricted ... while
at the same time allowing an extendable choice of validity
assertions.

The author had been asked whether the intended purpose cannot be
achieved using a technique based in RFC 4073
using

      ContentWithAttributes ::= SEQUENCE {
           content     ContentInfo,
           attrs       SEQUENCE SIZE (1..MAX) OF Attribute }

as a base construct. All what would be needed are a definition
of attributes concerning mimetype, filename and timestamp.
It could be but there was no intent to follow the idea.

RFC 4073's goal is to eliminate MIME encapsulations. One may
argue that it is in fact not 100% successful,
since useful mime headers cannot be easily transformed.
For example a Mime-type or a part of a Content-Description
which may have a filename but also a more useful description
of the data.

I am not sure whether a generic attribute to map a 'Mimeheader'
into some small ASN1 structure is necessary.

    SEQUENCE {
       header IA5TEXT,
       params SEQUENCE OF
          param SEQUENCE {key IA5TEXT, value}

(with maybe some constraints about IA5TEXT so that one
can easily map this into
    header: p1=v1 ; p2= v2 ...

To Denis: registering a content-type is not necessarily
related to the nature of the document.

Besides that one can ask the question whether a mimetype
would not be an important part of the data to be timestamped,
similar to the content-type which is included as an attribute
in a signed-data.

Peter