Re: Specification Schema extract

[Jim Clark <jdc-icot@lcc.net>]

I would like to also stress Dales point. In many cases, there is a legal
requirement to maintain these records/archivals for a specified period of
time, such as 7 years or more.

Jim Clark


"Moberg, Dale" wrote:

> Marty Sachs::> Karsten,
> >
> > Here are my thoughts on the "reliability levels" extract from the
> > specification schema that you sent.
> > Covering note:  It seems to me that there is a big difference between
> > persistent and non-persistent security, which is spelled out in the
> > extract.
> > Persistent:  Must be encrypted at the application level
> > and delivered
> >    encrypted to the receiving application.  I think that this would be
> >    controlled in the Process Specification Document and not
> > in the delivery
> >    channel in the CPA.
> >    Non-persistent:  Encryption takes place in the transport
> > (e.g. SSL);
> >    decryption takes place in the receiving transport and the
> > document is
> >    passed in the clear to the receiving application.  I think
> > that this
> >    relates to the "need proper definition" notation in "Document Flow
> >    security".  If IsSecureTransportRequired is "yes" but
> > persistence is not
> >    required, the CPA must specify an encrypting transport.
>
> I agree with what Marty says above but would like to add a point
> that explains the "business significance" of the persistent
> and nonpersistent distinction. Consider auditing/archiving.
> If nonpersistent forms of confidentiality, authentication, non-repudiation
> and so on are used, no archival records of signatures, for example,
> may remain to provide evidence, if a dispute were to arise.
> Requiring persistent signatures means that such records will
> remain for some agreed upon time. That is one major reason why
> recommended implementations for nonrepudiation of origin or receipt
> tend to use PGP. S/MIME, or now XMLDsig-- these mechanisms lend
> themselves to fairly easy archiving for record keeping purposes.
> This is not _just_ a technical issue.
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-tp-request@lists.ebxml.org
begin:vcard 
n:Clark;James
tel;cell:936.524.4424
tel;work:936.264.3366
x-mozilla-html:FALSE
org:I.C.O.T.
adr:;;10987 Quinlan N Lake;Conroe;TX;77303;
version:2.1
email;internet:jdc-icot@lcc.net
title:Principal Consultant
fn:James Clark
end:vcard