ietf-smime
[Top] [All Lists]

R: TimeStampedData draft updated - please comment

2007-11-21 01:16:55

Russ,

I am not sure if you were addressing your comment to me or to Denis...

At any rate, I would like to point out that the syntax I am proposing implies 
no MIME encoding at all. The data (like e.g. a patent, an offer, a contract, an 
income statement, a device driver, a security patch, a sensitive database, etc) 
is bundled in its native form, "as is". And thus, there is no MIME header to 
speak of. That's why I have provided for a 'mimeType' field: as a hint for the 
recipient/verifying application to guess what kind of data is carried within 
the TimeStampedData block, and what to do with it.

Adriano


-----Messaggio originale-----
Da: owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org] Per conto di Russ Housley
Inviato: martedì 20 novembre 2007 22.53
A: ietf-pkix(_at_)imc(_dot_)org; ietf-smime(_at_)imc(_dot_)org
Oggetto: Re: TimeStampedData draft updated - please comment


In S/MIME, the id-data content type is used when the content is MIME encoded.  
Then, then MIME header in the content is used to determine the format of the 
content.  Why does this suggest a different approach?

Russ

At 08:16 AM 11/19/2007, Denis Pinkas wrote:

Adriano,

Thank you for this new proposal. I skimmed through it.

It is interesting, but I fear that it is targeted to the wrong WG.
Since this would be an extension of CMS, this work item would rather 
belong to the S-MIME WG.
For this reason, I copy the S-MIME WG.

In addition, some polishing would be needed.

Rather than long words, you will find hereafter a rewriting of the 
ASN.1 with a few explanatory comments.

   TimeStampedData ::= SEQUENCE {
      version        [0] Version DEFAULT v1,
      fileName           UTF8String,
      mimeType           PrintableString,
      fileLocation       UTF8String OPTIONAL,
      -- fileLocation is only a hint.
      -- The file may or may not be stored at that location.
      content            OCTET STRING,
      temporalEvidences  TemporalEvidences }

   Version  ::=  INTEGER  { v1(0) }
   TemporalEvidences ::= SEQUENCE (SIZE(1..MAX)) OF TemporalEvidence

-- This structure allows multiple levels of temporal evidences.

   TemporalEvidence ::= SEQUENCE {
      evidences            Evidences,
      certificateLists     CertificateLists  OPTIONAL
}

   CertificateLists :: = SEQUENCE (SIZE(1..MAX)) OF CertificateList

   Evidence ::= CHOICE {
      timeStamps     [0] SEQUENCE (SIZE(1..MAX)) OF TimeStampToken }

-- For each level there can be one or more time-stamps tokens.

-- Before re-time stamping a set of former time-stamp tokens,
-- the CRLs of the previous level of time-stamps tokens can be captured
-- and inserted in the data structure.

Denis


Hello there,

here I am again with my TimeStampedData proposal.

I have submitted a new draft (also attached here) that takes into
account some of the remarks and suggestions received so far.

I have made room for additional types of temporal evidence, like
e.g. RFC 4998, while keeping RFC 3161 as the basis of interoperability.

I would like to invite everybody involved in time-stamping and
archiving e-documents to comment upon it: has it improved? 
something is missing?

In particular, please state:
- are you interested in this work?
- do you agree to adopt it as a new PKIX work item?
- are you going to use this format, once it is finished?

Is anybody willing to spend a few words on this draft during the
IETF meeting in Vancouver (as I cannot attend myself) ?

And finally, is anybody willing to invest a little time in
co-authoring this draft with me?

Adriano
Actalis S.p.A.
Milano, ITALY




-----Messaggio originale-----
Da: owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org] Per conto di Santoni 
Adriano
Inviato: lunedì 3 settembre 2007 10.42
A: ietf-pkix(_at_)imc(_dot_)org
Oggetto: R: R: Draft on TimeStampedData


Let me summarize the issues discussed so far:

1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 
3161)

In principle, I have no objections as long as we do not complicate
things too much and do not hamper interoperability.

There are at least two possible approaches to accomodate RFC 4998:

  a) explicitly provide for (one) ER in the TimeStampedData
syntax, as an alternative to the SET OF TimeStampToken;
  b) do not mention any specific standard for the "evidence", but
just mention RFC 3161 and RFC 4998 as two possibilities;

In any case, it must be possible for the verifying application to
easily detect which of the two (or more) kind of "evidence" has been 
used in the TimeStampedData envelope under examination. If we restrict 
the kinds of evidence to the two above, then a extra tagging may not 
be necessary, as an EvidenceRecord is a SEQUENCE, while the other 
choice would be a SET OF. Although unelegant, it would work. On the 
other hand, if we do not want to restrict the kinds of evidence to the 
two above, then of course we should somehow add an extra tagging 
level, because nobody knows at this time what syntax a third kind of 
evidence would conform to.

In any case, for the sake of interoperability, strong emphasis
should be given to RFC 3161 as today this is the most widely 
implemented type of evidence.

In conclusion: I agree with allowing RFC 4998 if we do that in a
way that does not modify the strong emphasis on RFC 3161 and does not 
hamper interoperability (which must be based on supporting RFC 3161, 
even though certain applications may also support RFC 4998).

2) filename vs. URI

Some remarked that an URI (or URI Reference) would be more
versatile than a simple filename. That is obviously true, but it 
implies that the 'content' field of TimeStampedData may be empty.
This is not what I was addressing in my original proposal. It would 
not just require the 'content' field to be declared OPTIONAL: it would 
make interoperability very difficult to achieve unless we restrict the 
URI schemes to a very small subset (e.g. http:, cid:, file:, ldap:) of 
the myriad possibilities. In any case, it would require ages of 
interoperability testing. And it would make life much harder for 
software implementors, without much of a benefit in view. I strongly 
believe in keeping things simple as much as possible.

3) multiple contents and RFC 4073

The 'content' field in the TimeStampedData envelope is not
structured, in my original proposal. It is just an OCTET STRING. 
That allows for any kind of content to be conveyed, even a 
ContentCollection according to RFC 4073.

Another remark has been made with reference to RFC 4073: the
ContentWithAttributes structure, also defined in RFC 4073, could in 
principle be used to bundle some content with the corrisponding 
evidence (the goal of my draft). Although this is true, it would 
require definining some additional OIDs, and mandating the presence of 
certain Attributes tagged by those OIDs. I frankly believe the 
TimeStampedData structure that I am proposing is better, first because 
it is dedicated and second because it "implements the ContentInfo 
interface", so to speak. It is simpler to manage for applications 
already able to parse different kinds of ContentInfo envelopes (there 
are a great many), possibly in a recursive way.

Adriano


-----Messaggio originale-----
Da: Young H Etheridge [mailto:yhe(_at_)yhetheridge(_dot_)org]
Inviato: venerdì 31 agosto 2007 17.48
A: Santoni Adriano
Cc: ietf-pkix(_at_)imc(_dot_)org
Oggetto: Re: R: Draft on TimeStampedData

Adriano,

To add to your thought processes:  I believe that a URI of
"file:///private.stuff" addresses your concern for privacy of the 
physical URI.  But, allowing URI in the syntax will make less private 
repositories, not necessarily file systems, more universally 
accessible.  The intent of the URI in RFC 3986 is to also allow for 
abstractly identifying a resource, not necessarily providing a 
physical resource.  In this manner the URI could then be used as an 
object identity in database(s).

Take care,

yhe

Santoni Adriano wrote:
To accomodate for RFC 4998, I would propose the following syntax:

TimeStampedData ::= SEQUENCE {
     version                 INTEGER { v1(1) },
     fileName                UTF8String,
     mimeType                PrintableString,
     content         OCTET STRING,
     evidence                Evidence
}

Evidence ::= CHOICE {
     timeStamps              [0] SET (SIZE(1..MAX)) OF TimeStampToken,
     evidenceRecord  [1] EvidenceRecord -- according to RFC 4998 }

(I am not sure whether it would be better to use explicit or 
implicit
tags...)

Regarding the idea of having an URI instead of a filename: I'd
prefer to think over things a little bit more, and maybe collect more 
feedback.

In my mind, I can send a TimeStampedData envelope to business
partners and/or public agencies via email. If the timestamped document 
is a local one, which I think is a meaningful and realistic scenario, 
then I do not want my company's hostnames and pathnames to be included 
in the envelope so that the recipient can see them.

Adriano



-----Messaggio originale-----
Da: owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org]
Per conto di Julien Stern
Inviato: venerdì 31 agosto 2007 13.43
A: ietf-pkix(_at_)imc(_dot_)org
Oggetto: Re: Draft on TimeStampedData


On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:

Adriano,


After pondering on this and other remarks, I cannot help but 
agree with Steve.

My original and essential goal is that of facilitating 
interoperability in a currently unregulated field. If we allow 
for several "degrees of freedom", than interoperability will be
hampered from the beginning.
So I'd better stick to RFC 3161 for now. We could include support 
for RFC 4998 Evidence Records later on, at the time when they 
become a widespread reality comparable to RFC 3161 
TimeStampTokens (which are widely implemented).

I would prefer to have both options: RFC 3161 and RFC 4998. For 
our customers evidence records are a widespread reality already.
A standardized way to put some data and their evidence record into 
a single file would be useful.


I strongly concur with this comment. Allowing the usage of ERS
as well as simple timestamps would allow the TimestampedData to 
leverage all the work of RFC 4998 regarding timestamps instead of 
reinventing the wheel in the future.

Regards,

--
Julien


Kind regards
Tilo



-----Messaggio originale-----
Da: Stephen Kent [mailto:kent(_at_)bbn(_dot_)com]
Inviato: giovedì 30 agosto 2007 23.05
A: Young H Etheridge
Cc: Santoni Adriano; ietf-pkix(_at_)imc(_dot_)org
Oggetto: Re: R: Draft on TimeStampedData

At 4:33 PM -0400 8/30/07, Young H Etheridge wrote:

...

Agreed, w.r.t. normative vs informative.  The above quote from
RFC-4998 merely underscores that this draft should also suggest, 
informatively, that the choice of Timestamp should be one that 
meets the normative syntax for Timestamp and not specify that 
which is in RFC-3161.  Nothing gets broken by being less 
restrictive and generally more informative to the community-at-large.

I have to disagree with your conclusion. If we require 3161
time stamps in an RFC of the sort Adriano proposed, then everyone can 
parse them if they comply with the RFC. If the RFC says "insert the 
time stamp from any standard you want here, and just tell us which one 
you used" then we have a problem. A compliant implementation can 
generate data structures containing time stamps that other compliant 
implementations cannot parse. That's the sort of interoperability 
problem we try to avoid in the IETF.


My notion of resilience does not mean "more encompassing" but 
that of providing the user community with choice and an enhanced 
safeguard against the possibility of the weakening of an algorithm.

Choices can be good, but they can create interoperability
problems in some cases, like this one. Also, we have algorithm agility 
as a requirement in all of our work, so the second concern you cite 
does not seem to apply here.

Steve

--
Tilo Kienitz
SecCommerce Informationssysteme GmbH Obenhauptstr. 5 D - 22335 
Hamburg
Germany                                   http://www.seccommerce.de

<Prev in Thread] Current Thread [Next in Thread>