Subject: つまんないよぉ(T_T)/~~~

From: [email-masked]
Date: Tue, 30 Dec 2003 21:03:49

かなり暇してるのぉ。メィルちょ。

Subject: =?ISO-2022-JP?B?GyRCJEQkXiRzJEokJCRoJCkbKEI=?=(T_T)/~~~
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Date: Tue, 30 Dec 2003 21:03:49

かなり暇してるのぉ。メィルちょ。

Subject: =?ISO-2022-JP?B?GyRCMj8kLDklJC0kSiROISkbKEI=?=
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Date: Thu, 25 Dec 2003 08:34:22

いいよ☆なんでも作ってあげるよ　今度会うときまでに決めておいてね(^_^)v

Subject: =?ISO-2022-JP?B?GyRCJCokTyRoGyhC?=
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Date: Sun, 21 Dec 2003 00:35:41

一人暮らしは寂しいね。彼氏もいないし…

Date: Fri, 19 Dec 2003 16:53:48 +0100 (MET)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft minutes
Cc: [email-masked]
Sender: [email-masked]

> 
> Did you intend to respond offlist?  If not, feel free to forward my response
> to the list.  Comments below...

A bug in my mail reader's reply function, it didn't detect the list. Thanks, Sun. 

> > > I think the comment was simply distinguishing between archiving in the
> sense
> > > this group is considering and a backup solution.
> >
> > The distinction seems not not to explain to me, technically the
> > difference may be very small.
> 
> Yes, the difference may be very small.  I was only giving my interpretation
> of what Russ said during the introduction.  I never considered unsigned data
> as beyond out concern.

ok.  

> 
> > "not worthy of consideration" is not exactly what I had in mind.  "Not
> being
> > able anymore by definition". the cryptographic validation of a signature
> > aginst a certificate as the ONLY means to validate it can only be done
> > rather shortly after the signature.
> 
> I took your point to be that we should define a solution that does not use
> any cryptographic mechanism that relies on secrets and agree completely.  I
> don't agree (at least not yet) that secret based, e.g. signature, mechanisms
> can not be part of the solution.

Ok.

> > Just an example:
> >   SMIME contains a linking of hashes, i.e.
> sign(hash(hash(data),attributes)),
> >   and if you consider that the data can be a hash+time, then there is
> >   even an additional indirection.
> > I don't think that so far, any of the hash linking patent holders has
> > tried to challenge this, or at least they lost as far as I remember.
> 
> OK.
.. 

> 
> > I know only one (other?) person convinced, and trying to convince that
> > refreshed time stamps are *THE* tool. The difference is whether it
> > is one of possible security measures, or whether this is consider
> > as a 100% secure measure and no others are necessary since no redunancy
> > problem exist.
> 
> I've not heard anyone assert that refreshed timestamps are *THE* tool, in
> the sense that they are sufficient alone to provide the solution.  I have
> heard folks who favor procedural controls over such mechanisms entirely.  In
> any case, there are multiple references, in IETF alone, asserting refreshed
> timestamps as *A* tool.

A slippery road. I tend to be careful to say anything abut the validity
of 30 or 100 years, except that microfilm and paper have known qualities.                                              
 
> > It doesn't seem very important to make a decision about whether
> > this or that mechanism is the right one, it would even be a disaster
> > since it seems desirable to able to change/add new technologies,
> > in order to avoid surprises like with "all you need is to
> > make magnetic tapes" or else.
> 
> It is important that we make decisions regarding mechanisms (and
> procedures/processes/etc?) if we intend to produce standards in this area.

I used bad wording. The decision cn be about a currently selection
of techniques and a framework allowing enhancements that won't make
previous techniques obsolete and may allow even migration. 

> 
> > 100 years later or, what counts
> > is the statement of the archiver/notariser telling whether a document
> > is valid. In general, you don't challenge the notary if it follows a
> > correct procedure etc.; it is in our interest to define architectures
> > and principles that have security characteristics similar to existing
> > paper techniques.
> 
> It is also in our interest to define evidence to support claims by
> archivers/notaries.
Yes. 
 
I think that we are sufficiently in phase now. 

I wonder whether the people who are mentioned in the minutes could
repeat or explain their comments (if they are subscribed to the list).
My capacity of listening distant conversations or telepathy are somewhat
limited.  :-)

regards

Subject: =?ISO-2022-JP?B?GyRCJCokTyRoGyhC?=
From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Date: Fri, 19 Dec 2003 01:24:08

一人暮らしは寂しいね。彼氏もいないし…

From: "Carl Wallace" <[email-masked]>
To: "'Peter Sylvester'" <[email-masked]>, <[email-masked]>
Subject: RE: draft minutes
Date: Wed, 17 Dec 2003 16:11:26 -0500
Importance: Normal
Sender: [email-masked]

Hi Peter,

Sorry the response is so delayed - some comments are inline below.

> Agenda 1) :
> > Stated that the group is concerned with signed data as opposed to
> > unsigned, general purpose archive.
> 
> What exactly is meant by 'signed data'. I think the purpose is to
>  
> 'archive and/or notarize authentifiable representations of
> information'.
> 
> If signed data means that the data to be archived need to
> have some characteristics that can be considered as an 
> equivalent of all aspects of what is called 'signature' for a 
> paper document, 
> then ok. 

I think the comment was simply distinguishing between archiving in the sense
this group is considering and a backup solution.  

> The difference between archive and notoarize may be floating.
> If the archive provider cares a little bit of the semnatics 
> of the document, for example when seome future conversion may 
> be planned, then this can be considered as the first step of 
> a notarisation operation; A real notarisation (depending on 
> which culture you think about) can just end here (public 
> notary) or continue to validate and assert the conformance to 
> some legal procedure (EU continent).
> 
> Agenda 3) :
> 
> Having siad the previous, I don't think that one should even
> try to address 
> the long term validaty of digital signature chains by using 
> any cryptographic 
> approach that includes secrets. Digital signatures are for 
> strong authentication (IMHO) and not a sufficintly stable 
> means for long term. 
> It seems important to me that the underlying service model 
> assumes that there is at least one additional redundant 
> mechanism that can be used to prove the "existance" of some 
> data at:before a certain
> time, e.g. physical protection with strong ordering of the 
> storage media.   

At what point would you deem verification of digital signatures not worthy
of consideration?  One of the comments in the minutes offered 7, 30 and 100
years as benchmarks.  Would any of those qualify?  Given that the accrual of
signatures is due to timestamp refresh (in the specs that served as input to
this group anyway), it may be sufficient to define archive structures that
are timestamp format agnostic to accommodate non-signature-based timestamp
solutions.  There seems to be some general agreement regarding refreshed
timestamps as a tool useful for archiving.  The applicability of the linking
hash approach to IETF work is not clear to me due to patent issues.
 
> > "Complicated problem of establishing validity of a chain of
> signatures
> > over 100 years."
> 
> Can someone give a paper equvalent example?

The "Long Term Archive Architecture" gave a comic counterexample.  In any
case, whether or not a chain of digital signatures would ever be verified to
prove the validity of a signature that is hundreds of years old or to make
claims regarding the content of the associated data isn't necessarily
relevant.  It's just an extreme extension of the mechanisms that have been
presented so far.  
 
<snip>