Re: WG Review: Long-Term Archive and Notary Services (ltans)

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 7 Oct 2003, The IESG wrote:
>  Long-term non-repudiation of digitally signed data is an important aspect
>  of PKI-related standards. Standard mechanisms are needed to handle routine
>  events, such as expiry of signer's public key certificate and expiry of
>  trusted time stamp authority certificate. A single timestamp is not
>  sufficient for this purpose. Additionally, the reliable preservation of
>  content across change of formats, application of electronic notarizations,
>  and subsequent notary services require standard solutions.
> 
>  The objective of the LTANS working group is to define requirements, data
>  structures and protocols for the secure usage of the necessary archive and
>  notary services. First, the requirements for the long-term archive will be
>  collected. Based on that information we will develop a protocol to access
>  archive services supplying long-term non-repudiation for signed documents
>  and define common data structures and formats. Upon completion of the
>  archive-related specifications, we will address 'notary services' in a
>  similar way. The term 'notary services' is not clearly defined. The working
>  group will determine which functions need standards, including transformation
>  of documents from one format to another without losing the value of evidence,
>  electronic notarization, and further verification of legal validity of signed
>  documents. We will determine the needs via the requirements paper and act
>  upon the results accordingly.

This seems like a potentially useful field to work on, but I don't think 
the proposed charter is sufficiently clear on what will be going on and 
what will be the priorities of the work.

Writing requirements is undeniably useful to gain more insight what 
actually needs to be done.  I guess data structures, or more importantly, 
service interfaces are the next important topic.  I'm not sure whether a 
protocol to store such data is necessarily needed though (e.g., consider 
doing it over HTTPS usingi a web form, or similar to how folks store route 
objects and other data in routing registries or databases such as RIPE).  
It is not clear whether all of this work is needed from the start.

So, I'd like to break the charter in a bit more digestible pieces, give 
the WG goals only in a "do this first, then we consider how to 
proceed; recharter or disband" fashion.

Otherwise, I fear this could result in too open-ended work being 
initiated.  Focus first, and once achieved, expand the view if needed.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings