Re: TimeStampedData draft updated - please comment
2007-11-19 06:49:42
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>
|
- Re: TimeStampedData draft updated - please comment,
Denis Pinkas <=
|
|
|