Subject: I-D Action:draft-ietf-ltans-dssc-05.txt

From: [email-masked]
Date: Mon, 3 Nov 2008 07:45:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Long-Term Archive and Notary Services Working Group of the IETF.

	Title           : Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC)
	Author(s)       : T. Kunz, et al.
	Filename        : draft-ietf-ltans-dssc-05.txt
	Pages           : 41
	Date            : 2008-11-03

In many application areas it must be possible to prove the existence
and integrity of digital signed data.  This proof depends on the
security suitability of the cryptographic algorithms used to generate
or verify the digital signature.  Because algorithms can become weak
over the years, it is necessary to periodically evaluate their
security suitability.  When signing or verifying data, these
evaluations must be considered.  This document specifies a data
structure that enables automated analysis of the security suitability
of cryptographic algorithms.Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 12 Nov 2008 09:14:20 +0100

Comments on draft-ietf-ltans-dssc-05
 
1. The abstract is only related to digitally signed data. The abstract should be extended to mention encryption. 
It should also mention that the use of a weak cryptographic algorithm within a complex data structure 
can be protected using a strong cryptographic algorithm which then may render the whole data structure 
adequate for its intended use.
 
The current abstract is the following:
 
   of cryptographic algorithms.
 
Proposed change for the whole abstract to solve these two comments:
 
   Because cryptographic algorithms can become weak over the years, 
   it is necessary to evaluate their security suitability.
   When signing or verifying data, or when encrypting or decrypting 
   data, these evaluations must be considered.  This document specifies 
   a data structure that enables an automated analysis of the security 
   suitability of a given cryptographic algorithm at a given point of 
   time which may be in the past, at the present time or in the future.
 
   The automated processing of a cryptographic data structure that 
   uses several cryptographic algorithms cannot be performed only using 
   the previous automated analysis, since in some cases a weak 
   cryptographic algorithm can be protected by a strong cryptographic 
   algorithm which may make the whole data structure adequate for its 
   intended use.

2. Section 1.1. The text sates:
 
   If algorithms lack the required properties, signatures could be forged.
 
This sentence should be changed into:
 
   If algorithms lack the required properties, signatures could be 
   forged, unless they are protected by a strong cryptographic 
   algorithm, e.g. a time-stamp token that uses a strong cryptographic 
   algorithm.

3. Section 1.1. The text sates:
 
   Very few algorithms satisfy the security requirements and are 
   suitable for usage in signatures.
 
This is not fully correct.
 
This sentence should be changed into:
 
   Cryptographic algorithms that are used in signatures shall resist 
   during their period of use.  For signature keys included in public key 
   certificates, it is the validity period of the certificate.
 
   Cryptographic algorithms that are used for encryption shall resist 
   during the time during which it is planned to keep the information 
   confidential. 
 
4. Section 1.1. The text sates:
 
A digital signature using a "weak" algorithm has no probative value.
 
This is not fully correct.
 
This sentence should be changed into:
 
   A digital signature using a "weak" algorithm has no probative value, 
   unless the "weak" algorithm has been protected by a strong algorithm 
   before the time it was considered to be weak.

5. Section 1.1. The text sates:
 
   For this reason, it is important to periodically evaluate an
   algorithm's fitness and to consider the results of these evaluations
   when creating, verifying or renewing signatures.
 
This is not fully correct. A signature made by a human being that is dead cannot be "renewed".
 
This sentence should be changed into:
 
   For this reason, it is important to periodically evaluate an
   algorithm's fitness and to consider the results of these evaluations
   when creating and verifying signatures, or when maintaining the 
   validity of signatures made in the past.
 
6. Section 1.1. The text sates:
 
   This prediction can help to detect whether an insecure algorithm 
   is used in a signature or whether a signature has been properly 
   preserved.
 
This is not fully correct.
 
This sentence should be changed into:
 
   This prediction can help to detect whether a weak algorithm 
   is used in a signature and whether that signature has been properly 
   protected in due time by an another signature made using an algorithm 
   that is suitable at the present point of time.

7. Definition of flexibility:
 
The text states:
 
   Additionally the data structure must be designed independent of the 
   intended use, e.g., encryption, signing, verifying, and signature 
   renewing.  Thus, the interpretion of the data structure is same for 
   every use case.
Firstly there is typo on the word: interpretion
 
Secondly, the document does not define what is a signature algorithm. 

There are three possible answers to that question, that may be illustrated 
with the RSA algorithm:
 
   1) it is only the RSA algorithm,
   2) it is the RSA algorithm with a padding function,
   3) it is the RSA algorithm with a padding function and a hash function.
 
The text should clarify which case(s) are supported. If cases 2) or 3) are supported, 
then the above text is incorrect.

8. Section 2.2.:
 
The text states:
 
   An algorithm is suitable if it is contained in the current policy and
   the time of interest is within the validity period.
 
This sentence should be changed into:
 
   An algorithm is suitable *at a time of interest* if it is contained 
   in the current policy and the time of interest is within the validity 
   period.

9. Section 5.5. This section should first add another kind of output. Please add the following text:
 
   If the algorithm is not in the policy, an error "algorithm unknown" is 
   returned.

10. Section 5.5.
 
The text states:
 
   If the algorithm is not suitable relative to the time of interest, 
   return an error.
 
Change into:
 
   If the algorithm is not suitable relative to the time of interest, 
   an error "algorithm unsuitable" is returned.

11. Section 5.5.
 
The text states:
 
   If the algorithm is suitable, return the Evaluation elements that
   were not discarded.
 
Change into:
 
   If the algorithm is suitable, return the Evaluation elements that
   were not discarded, *in particular its validity period*.

12. Section 6. Security Considerations 
 
In the comments made on draft-04, it has been requested to add text to warn the user that 
the processing rule described in section 5 is about *one* algorithm *independently of the use case*. 
Depending upon the use case, an algorithm is no more suitable at the time of evaluation, may be 
no problem at all.
 
Proposed text:
 
   The processing rule described in section 5 is about one cryptographic 
   algorithm independently of the use case.  Depending upon the use case, 
   an algorithm that is no more suitable at the time of interest, does not 
   necessarily mean that the data structure where it is used is no more 
   secure.
 
   For example, an RSA signer's key of 1024 bits is being used in year 
   2009.  The validity period of the signature key included in a public key 
   certificate is three years.  The signature is time-stamped in year 2009 
   with a time-stamp token that uses an RSA key of 2048 bits.
 
   This data structure is revaluated in year 2020. Let us suppose that in 
   year 2015 an RSA key size of 1024 bits will be broken.  The fact that 
   the signature key of 1024 bits is no more suitable in year 2015 and 
   a fortiori in year 2020 does not mean that the whole structure is no 
   more secure, if an RSA key size of 2048 bits is still suitable in 
   year 2020.
 
   In addition, to the key size considerations, other considerations 
   apply, like whether the time-stamp token has been provided by a 
   trusted authority.  It means that the simple use of a suitability 
   policy is not the single element to consider when evaluating the 
   security of a complex data structure using several cryptographic 
   algorithms.
 
13. Section 6. Security Considerations . This section should include text to cover the case of encryption.
 
Proposed text:
 
   Re-encrypting documents that were originally encrypted using an 
   algorithm that is no more suitable, will not protect the semantics 
   of the document, if the document has been intercepted.  However, 
   for documents stored in an encrypted form, re-encryption must be 
   considered, unless the document has lost its original value due to 
   time erosion.

14. Appendix A.1. It should be indicated *in the title* that this appendix is informative.

Denis
----- Message reçu ----- 
De : owner-ietf-ltans 
À : i-d-announce 
Date : 2008-11-03, 16:45:01
Sujet : I-D Action:draft-ietf-ltans-dssc-05.txt

Pièce(s) Jointe(s) au message original :
  (1). draft-ietf-ltans-dssc-05.txt

---

From: Susanne Okunick <[email-masked]>
Date: Mon, 24 Nov 2008 14:18:03 +0100

Denis,

We agree with most of your comments and will try to consider them in
our next
version. More comments inline...

7.
Definition of flexibility:

The
text states:

Additionally
the data structure must be designed independent of the

intended
use, e.g., encryption, signing, verifying, and signature

renewing.  Thus, the interpretion of the data structure is
same for

every
use case.

Firstly there is
typo on the word: interpretion

ok.

Secondly, the document does not define what is a signature
algorithm.

There are three
possible answers to that question, that may be illustrated

with the RSA algorithm:

3) it is the RSA algorithm with a padding function and a hash
function.

The text
should clarify which case(s) are supported. If cases 2) or 3) are
supported,

Every kind of signature algorithm is supported.

However the analysis
is the same for every use case. In case 1) the datastructure is used to
find out whether e.g. "RSA with key length 1024" is suitable at any
point of time (e.g. now). In case 3) additionally the suitability of
any hash algorithm is checked. The datastructure ist interpreted one or
more times in the same way.

Secondly, the data structure ist flexible enough to support combined
algorithms such like "SHA1withRSA" (example in appendix E). Also in
this case the data structure is analysed in the same way.

We think, the text is correct.

We try to give a better definition of algorithm.

12. Section 6. Security
Considerations

In the
comments made on draft-04, it has been requested to add text to warn
the user that

the processing rule described in section 5 is about *one* algorithm
*independently of the use case*.

Depending upon the use case, an algorithm is no more suitable at the
time of evaluation, may be

no problem at all.

Proposed text:

The processing rule described in section 5 is
about one cryptographic

algorithm
independently of the use case.  Depending upon
the use case,

an algorithm that is no more suitable at the time
of interest, does not

necessarily mean that the data structure where it
is used is no more

secure.

For example, an RSA signer's key of 1024 bits is
being used in year

2009.  The validity period
of the signature key included in a public key

certificate is three years.  The
signature is time-stamped in year 2009

with a time-stamp token that uses an RSA key of
2048 bits.

This data structure is revaluated in year 2020.
Let us suppose that in

year 2015 an RSA key size of 1024 bits will be
broken.  The fact that

the signature key of 1024 bits is no more suitable
in year 2015 and

a fortiori in year 2020 does not mean that the
whole structure is no

more secure, if an RSA key size of 2048 bits is
still suitable in

year 2020.

In addition, to the key size considerations, other
considerations

apply, like whether the time-stamp token has been
provided by a

trusted authority.  It
means that the simple use of a suitability

policy is not the single element to consider when
evaluating the

security of a complex data structure using several
cryptographic

algorithms.

13. Section 6. Security
Considerations . This section should
include text to cover the case of encryption.

Proposed text:

Re-encrypting documents
that were originally encrypted using an

algorithm
that is no more suitable, will not protect the semantics

of the
document, if the document has been intercepted.  However,

for
documents stored in an encrypted form, re-encryption must be

considered,
unless the document has lost its original value due to

time
erosion.

We don't see the need to warn the user in detail: We expect the user is
familiar with these issues. Additionally in Appendix A we linked to the
ERS.

Many thanks for your comments!

Susanne

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAODIP1X033372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 06:18:25 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAODIPOa033371; Mon, 24 Nov 2008 06:18:25 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id mAODIC1f033352 for ; Mon, 24 Nov 2008 06:18:23 -0700 (MST) (envelope-from [email-masked])
Received: (qmail invoked by alias); 24 Nov 2008 13:18:08 -0000
Received: from drms-4d00690f.pool.mediaWays.net (EHLO Macintosh.local) [77.0.105.15] by mail.gmx.net (mp015) with SMTP; 24 Nov 2008 14:18:08 +0100
X-Authenticated: #1167296
X-Provags-ID: V01U2FsdGVkX18D8kVDr8oDgnBEqqB7EzrKiVGoov4F6p04nnm0Ie H+azLijFCM0Ib0
Message-ID: <[email-masked]>
Date: Mon, 24 Nov 2008 14:18:03 +0100
From: Susanne Okunick
User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105)
MIME-Version: 1.0
To: [email-masked]
CC: [email-masked]
Subject: Re: I-D Action:draft-ietf-ltans-dssc-05.txt
References: <[email-masked]>
In-Reply-To:
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.61
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Denis,

We agree with most of your comments and will try to consider them in
our next
version. More comments inline...

7.
Definition of flexibility:

The
text states:

Additionally
the data structure must be designed independent of the

intended
use, e.g., encryption, signing, verifying, and signature

renewing.  Thus, the interpretion of the data structure is
same for

every
use case.

Firstly there is
typo on the word: interpretion

ok.

Secondly, the document does not define what is a signature
algorithm.

There are three
possible answers to that question, that may be illustrated

with the RSA algorithm:

3) it is the RSA algorithm with a padding function and a hash
function.

The text
should clarify which case(s) are supported. If cases 2) or 3) are
supported,

Every kind of signature algorithm is supported.

However the analysis
is the same for every use case. In case 1) the datastructure is used to
find out whether e.g. "RSA with key length 1024" is suitable at any
point of time (e.g. now). In case 3) additionally the suitability of
any hash algorithm is checked. The datastructure ist interpreted one or
more times in the same way.

Secondly, the data structure ist flexible enough to support combined
algorithms such like "SHA1withRSA" (example in appendix E). Also in
this case the data structure is analysed in the same way.

We think, the text is correct.

We try to give a better definition of algorithm.

12. Section 6. Security
Considerations

In the
comments made on draft-04, it has been requested to add text to warn
the user that

the processing rule described in section 5 is about *one* algorithm
*independently of the use case*.

Depending upon the use case, an algorithm is no more suitable at the
time of evaluation, may be

no problem at all.

Proposed text:

The processing rule described in section 5 is
about one cryptographic

algorithm
independently of the use case.  Depending upon
the use case,

an algorithm that is no more suitable at the time
of interest, does not

necessarily mean that the data structure where it
is used is no more

secure.

For example, an RSA signer's key of 1024 bits is
being used in year

2009.  The validity period
of the signature key included in a public key

certificate is three years.  The
signature is time-stamped in year 2009

with a time-stamp token that uses an RSA key of
2048 bits.

This data structure is revaluated in year 2020.
Let us suppose that in

year 2015 an RSA key size of 1024 bits will be
broken.  The fact that

the signature key of 1024 bits is no more suitable
in year 2015 and

a fortiori in year 2020 does not mean that the
whole structure is no

more secure, if an RSA key size of 2048 bits is
still suitable in

year 2020.

In addition, to the key size considerations, other
considerations

apply, like whether the time-stamp token has been
provided by a

trusted authority.  It
means that the simple use of a suitability

policy is not the single element to consider when
evaluating the

security of a complex data structure using several
cryptographic

algorithms.

13. Section 6. Security
Considerations . This section should
include text to cover the case of encryption.

Proposed text:

Re-encrypting documents
that were originally encrypted using an

algorithm
that is no more suitable, will not protect the semantics

of the
document, if the document has been intercepted.  However,

for
documents stored in an encrypted form, re-encryption must be

considered,
unless the document has lost its original value due to

time
erosion.

We don't see the need to warn the user in detail: We expect the user is
familiar with these issues. Additionally in Appendix A we linked to the
ERS.

Many thanks for your comments!

Susanne

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIG0jFc057894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 09:00:45 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAIG0jRh057893; Tue, 18 Nov 2008 09:00:45 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAIG0XFn057884 for ; Tue, 18 Nov 2008 09:00:44 -0700 (MST) (envelope-from [email-masked])
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ppGJwBgFMmaNRKZmFFOGU3aCRhZvoRqR6U9MqjJfy05ChREf5kkZXQEHzEWl1uej; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=[192.168.0.32]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1L2T0D-0007qr-M7; Tue, 18 Nov 2008 11:00:33 -0500
Message-ID: <[email-masked]>
Date: Tue, 18 Nov 2008 08:00:43 -0800
From: TSG
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Jesus Maria Mendez Perez
CC: [email-masked]
Subject: Re: XSD Schema considerations
References:
In-Reply-To:
Content-Type: multipart/alternative; boundary="------------070708030506010501000300"
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79052e0ccc85a7a4f59afba669dfd21613350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is a multi-part message in MIME format.
--------------070708030506010501000300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Jesus Maria Mendez Perez wrote:
> Hello,
>
> I have checked lastest versions of LTANS drafts, and i have some
> questions about xsd´s schemas.
>
> In xmlers.xsd, inside EvidenceRecord element we can add this new
> elements to save up certificates and information of revocation.
>
> ----- defined in
> xmldisg-core-schema.xsd
> type="xa:CompleteRevocationRefsType"/> ----- defined in XAdES.xsd
>
> and change the complextype TimeStamp
>
>
>
> maxOccurs="unbounded"/>
>
>
>
> by this which is defined in oasis-dss-core-schema-v1.0-os.xsd:
>
>
>
>
> type="xsd:base64Binary"/>
>
>
>
>
>
>
> maxOccurs="unbounded"/>
>
>
>
> I want to know your opinion about these changes.

What are the specific use models intended? It will make a difference.
There is no one-size-fits-all type of evidence container yet, so the use
models are specific to the evidence structures.

Also any use model must be brought into alignment with the US Federal
Rules of Evidence's five-point test for determining the strength and
admissibility of the data contained therein, otherwise this is just
another IETF game which will not produce a legally defensible data model
IMHO.
>
> Thanks.
>
>
>
>
>
> ------------------------------------------------------------------------
>
>
> Internal Virus Database is out of date.
> Checked by AVG - http://www.avg.com
> Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008 7:53 AM
>
>

--------------070708030506010501000300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jesus Maria Mendez Perez wrote:

Hello,

I have checked lastest versions of LTANS drafts, and i have some
questions about xsd´s schemas.

In xmlers.xsd, inside EvidenceRecord element we can add this new
elements to save up certificates and information of revocation.

<xsd:element name="KeyInfo" type="ds:KeyInfoType"/>  -----
defined in xmldisg-core-schema.xsd

<xsd:element name="CompleteRevocationRefs"
type="xa:CompleteRevocationRefsType"/> ----- defined in XAdES.xsd

and change the complextype TimeStamp

<xsd:complexType name="TimeStamp">

<xsd:sequence>

<xsd:any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

by this which is defined in oasis-dss-core-schema-v1.0-os.xsd:

<xsd:complexType name="TimeStampType">

<xsd:choice>

<xsd:element ref="ds:Signature"/>

<xsd:element name="RFC3161TimeStampToken"
type="xsd:base64Binary"/>

<xsd:element name="Other" type="tn:AnyType"/>

</xsd:choice>

</xsd:complexType>

<xsd:complexType name="AnyType">

<xsd:sequence>

<xsd:any processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

I want to know your opinion about these changes.

What are the specific use models intended? It will make a difference.
There is no one-size-fits-all type of evidence container yet, so the
use models are specific to the evidence structures.

Also any use model must be brought into alignment with the US Federal
Rules of Evidence's five-point test for determining the strength and
admissibility of the data contained therein, otherwise this is just
another IETF game which will not produce a legally defensible data
model IMHO.

Thanks.

Internal Virus Database is out of date.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.9.0/1779 - Release Date: 11/10/2008 7:53 AM

--------------070708030506010501000300--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI8YVwf030132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2008 01:34:31 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAI8YViJ030131; Tue, 18 Nov 2008 01:34:31 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.247]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAI8YKXg030122 for ; Tue, 18 Nov 2008 01:34:30 -0700 (MST) (envelope-from [email-masked])
Received: by rv-out-0708.google.com with SMTP id c5so2771941rvf.34 for ; Tue, 18 Nov 2008 00:34:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=eaJDE4otgg/ZDY7n9EMg1VFNhTiB6jpKxHgPQnninHs=; b=cCCbT142CDRUFO5eHRl1LTVTiOoWldMagT2xndq8PL2vt1yHZOrCfi9pgDh7zteQfh VmC5gbL1SEdo8MYOwMQxgacotD1WrCqMSFG7SQgWBiu4zE8adQ3W9IiBjmV7s2Sq1iEF diSaOQM6THw8vhn89R1mP7vH7moKd2LNte2zY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=RTz1+9BXay/GMyw16jyDHKvxU/VhUc0pgbGPDSuWcGYIDoqYJRStk8Wk8P5VxiMBhL 6i4of1trXWrdZ7b+bAqNMLjlrWleTkif4PbfDoNwhEsi5RysNSIYtvAblhbyWwL/U8l4 hsRahX/6NqR7gUc/p7i2QSl50ZYLd14RpFe7w=
Received: by 10.142.165.14 with SMTP id n14mr2473329wfe.24.1226997259637; Tue, 18 Nov 2008 00:34:19 -0800 (PST)
Received: by 10.142.229.18 with HTTP; Tue, 18 Nov 2008 00:34:19 -0800 (PST)
Message-ID:
Date: Tue, 18 Nov 2008 09:34:19 +0100
From: "Jesus Maria Mendez Perez"
To: [email-masked]
Subject: XSD Schema considerations
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_93635_20618816.1226997259621"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

------=_Part_93635_20618816.1226997259621
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I have checked lastest versions of LTANS drafts, and i have some questions
about xsd=B4s schemas.

In xmlers.xsd, inside EvidenceRecord element we can add this new elements t=
o
save up certificates and information of revocation.

----- defined in
xmldisg-core-schema.xsd
----- defined in XAdES.xsd

and change the complextype TimeStamp

by this which is defined in oasis-dss-core-schema-v1.0-os.xsd:

I want to know your opinion about these changes.

Thanks.

------=_Part_93635_20618816.1226997259621
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

I have checked lastest versions of LTANS drafts, and i have s=
ome questions about xsd=B4s schemas.

In xmlers.xsd, inside EvidenceR=
ecord element we can add this new elements to save up certificates and info=
rmation of revocation.

<xsd:element name=3D"KeyInfo" type=3D"ds:KeyInfoType&=
quot;/>  ----- defined in xmldisg-core-schema.xsd
<xsd:elemen=
t name=3D"CompleteRevocationRefs" type=3D"xa:CompleteRevocat=
ionRefsType"/> ----- defined in XAdES.xsd

and change the complextype TimeStamp

<xsd:=
complexType name=3D"TimeStamp">
&n=
bsp; <xsd:sequence>
&n=
bsp;  <xsd:any namespace=3D"##other" minOccurs=3D"0&=
quot; maxOccurs=3D"unbounded"/>

</xsd:sequence>
</=
xsd:complexType>

by this which is defined in oasis-dss-core-schem=
a-v1.0-os.xsd:

<xsd:complexType name=3D"TimeStampType"&=
gt;
<xsd:choice>

<xsd:element re=
f=3D"ds:Signature"/>
=
<xsd:element name=3D"RFC3161TimeStampToken"=
type=3D"xsd:base64Binary"/>
=
;      <xsd:element name=3D"Other" type=3D=
"tn:AnyType"/>

</xsd:choice>
</xsd:compl=
exType>

<xsd:complexType name=3D"AnyTy=
pe">
<xsd:sequence><=
br>            <xsd:any pro=
cessContents=3D"lax" minOccurs=3D"0" maxOccurs=3D"=
unbounded"/>

</xsd:sequence>
</xsd:com=
plexType>

I want to know your opinion about these changes.
Thanks.

------=_Part_93635_20618816.1226997259621--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAC8EZXm033785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2008 01:14:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mAC8EZuJ033784; Wed, 12 Nov 2008 01:14:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mAC8ENoU033773 for ; Wed, 12 Nov 2008 01:14:34 -0700 (MST) (envelope-from [email-masked])
Received: from MSGA-001.frcl.bull.fr (msga-mcl1.frcl.bull.fr [129.184.87.20]) by odin2.bull.net (Bull S.A.) with ESMTP id 1DB92789A for ; Wed, 12 Nov 2008 09:08:32 +0100 (CET)
Received: from FRMYA-SIA24 ([129.182.109.121]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008111209142057:263144 ; Wed, 12 Nov 2008 09:14:20 +0100
Reply-To: [email-masked]
From: "Denis Pinkas"
To: "IETF LTANS"
Subject: Re: I-D Action:draft-ietf-ltans-dssc-05.txt
Date: Wed, 12 Nov 2008 09:14:20 +0100
Message-Id:
References: <[email-masked]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Mailer: DreamMail 4.4.1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 12/11/2008 09:14:20, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 12/11/2008 09:14:21, Serialize complete at 12/11/2008 09:14:21
Content-Type: multipart/alternative; boundary="----=_NextPart_08111209141887344650666_002"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

------=_NextPart_08111209141887344650666_002
Content-Type: text/plain;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

Comments on draft-ietf-ltans-dssc-05
=20
1. The abstract is only related to digitally signed data. The abstract sh=
ould be extended to mention encryption.=20
It should also mention that the use of a weak cryptographic algorithm wit=
hin a complex data structure=20
can be protected using a strong cryptographic algorithm which then may re=
nder the whole data structure=20
adequate for its intended use.
=20
The current abstract is the following:
=20
In many application areas it must be possible to prove the existence
and integrity of digital signed data. This proof depends on the
security suitability of the cryptographic algorithms used to generate
or verify the digital signature. Because algorithms can become weak
over the years, it is necessary to periodically evaluate their
security suitability. When signing or verifying data, these
evaluations must be considered. This document specifies a data
structure that enables automated analysis of the security suitability=20
of cryptographic algorithms.
=20
Proposed change for the whole abstract to solve these two comments:
=20
Because cryptographic algorithms can become weak over the years,=20
it is necessary to evaluate their security suitability.
When signing or verifying data, or when encrypting or decrypting=20
data, these evaluations must be considered. This document specifies=20
a data structure that enables an automated analysis of the security=20
suitability of a given cryptographic algorithm at a given point of=20
time which may be in the past, at the present time or in the future.
=20
The automated processing of a cryptographic data structure that=20
uses several cryptographic algorithms cannot be performed only using=20
the previous automated analysis, since in some cases a weak=20
cryptographic algorithm can be protected by a strong cryptographic=20
algorithm which may make the whole data structure adequate for its=20
intended use.
=20
=20
2. Section 1.1. The text sates:
=20
If algorithms lack the required properties, signatures could be forged=
.
=20
This sentence should be changed into:
=20
If algorithms lack the required properties, signatures could be=20
forged, unless they are protected by a strong cryptographic=20
algorithm, e.g. a time-stamp token that uses a strong cryptographic=20
algorithm.
=20
=20
3. Section 1.1. The text sates:
=20
Very few algorithms satisfy the security requirements and are=20
suitable for usage in signatures.
=20
This is not fully correct.
=20
This sentence should be changed into:
=20
Cryptographic algorithms that are used in signatures shall resist=20
during their period of use. For signature keys included in public key=
=20
certificates, it is the validity period of the certificate.
=20
Cryptographic algorithms that are used for encryption shall resist=20
during the time during which it is planned to keep the information=20
confidential.=20
=20
4. Section 1.1. The text sates:
=20
A digital signature using a "weak" algorithm has no probative value.
=20
This is not fully correct.
=20
This sentence should be changed into:
=20
A digital signature using a "weak" algorithm has no probative value,=20
unless the "weak" algorithm has been protected by a strong algorithm=20
before the time it was considered to be weak.
=20
=20
5. Section 1.1. The text sates:
=20
For this reason, it is important to periodically evaluate an
algorithm's fitness and to consider the results of these evaluations
when creating, verifying or renewing signatures.
=20
This is not fully correct. A signature made by a human being that is dead=
cannot be "renewed".
=20
This sentence should be changed into:
=20
For this reason, it is important to periodically evaluate an
algorithm's fitness and to consider the results of these evaluations
when creating and verifying signatures, or when maintaining the=20
validity of signatures made in the past.
=20
6. Section 1.1. The text sates:
=20
This prediction can help to detect whether an insecure algorithm=20
is used in a signature or whether a signature has been properly=20
preserved.
=20
This is not fully correct.
=20
This sentence should be changed into:
=20
This prediction can help to detect whether a weak algorithm=20
is used in a signature and whether that signature has been properly=20
protected in due time by an another signature made using an algorithm=20
that is suitable at the present point of time.
=20
=20
7. Definition of flexibility:
=20
The text states:
=20
Additionally the data structure must be designed independent of the=20
intended use, e.g., encryption, signing, verifying, and signature=20
renewing. Thus, the interpretion of the data structure is same for=20
every use case.
Firstly there is typo on the word: interpretion
=20
Secondly, the document does not define what is a signature algorithm.=20

There are three possible answers to that question, that may be illustrate=
d=20
with the RSA algorithm:
=20
1) it is only the RSA algorithm,
2) it is the RSA algorithm with a padding function,
3) it is the RSA algorithm with a padding function and a hash function=
.
=20
The text should clarify which case(s) are supported. If cases 2) or 3) ar=
e supported,=20
then the above text is incorrect.
=20
=20
8. Section 2.2.:
=20
The text states:
=20
An algorithm is suitable if it is contained in the current policy and
the time of interest is within the validity period.
=20
This sentence should be changed into:
=20
An algorithm is suitable *at a time of interest* if it is contained=20
in the current policy and the time of interest is within the validity=20
period.
=20
=20
9. Section 5.5. This section should first add another kind of output. Ple=
ase add the following text:
=20
If the algorithm is not in the policy, an error "algorithm unknown" is=
=20
returned.
=20
=20
10. Section 5.5.
=20
The text states:
=20
If the algorithm is not suitable relative to the time of interest,=20
return an error.
=20
Change into:
=20
If the algorithm is not suitable relative to the time of interest,=20
an error "algorithm unsuitable" is returned.
=20
=20
11. Section 5.5.
=20
The text states:
=20
If the algorithm is suitable, return the Evaluation elements that
were not discarded.
=20
Change into:
=20
If the algorithm is suitable, return the Evaluation elements that
were not discarded, *in particular its validity period*.
=20
=20
12. Section 6. Security Considerations=20
=20
In the comments made on draft-04, it has been requested to add text to wa=
rn the user that=20
the processing rule described in section 5 is about *one* algorithm *inde=
pendently of the use case*.=20
Depending upon the use case, an algorithm is no more suitable at the time=
of evaluation, may be=20
no problem at all.
=20
Proposed text:
=20
The processing rule described in section 5 is about one cryptographic=20
algorithm independently of the use case. Depending upon the use case,=
=20
an algorithm that is no more suitable at the time of interest, does no=
t=20
necessarily mean that the data structure where it is used is no more=20
secure.
=20
For example, an RSA signer's key of 1024 bits is being used in year=20
2009. The validity period of the signature key included in a public k=
ey=20
certificate is three years. The signature is time-stamped in year 200=
9=20
with a time-stamp token that uses an RSA key of 2048 bits.
=20
This data structure is revaluated in year 2020. Let us suppose that in=
=20
year 2015 an RSA key size of 1024 bits will be broken. The fact that=20
the signature key of 1024 bits is no more suitable in year 2015 and=20
a fortiori in year 2020 does not mean that the whole structure is no=20
more secure, if an RSA key size of 2048 bits is still suitable in=20
year 2020.
=20
In addition, to the key size considerations, other considerations=20
apply, like whether the time-stamp token has been provided by a=20
trusted authority. It means that the simple use of a suitability=20
policy is not the single element to consider when evaluating the=20
security of a complex data structure using several cryptographic=20
algorithms.
=20
13. Section 6. Security Considerations . This section should include text=
to cover the case of encryption.
=20
Proposed text:
=20
Re-encrypting documents that were originally encrypted using an=20
algorithm that is no more suitable, will not protect the semantics=20
of the document, if the document has been intercepted. However,=20
for documents stored in an encrypted form, re-encryption must be=20
considered, unless the document has lost its original value due to=20
time erosion.
=20
=20
14. Appendix A.1. It should be indicated *in the title* that this appendi=
x is informative.

Denis
----- Message re=E7u -----=20
De : owner-ietf-ltans=20
=C0 : i-d-announce=20
Date : 2008-11-03, 16:45:01
Sujet : I-D Action:draft-ietf-ltans-dssc-05.txt

Pi=E8ce(s) Jointe(s) au message original :
(1). draft-ietf-ltans-dssc-05.txt

Title : Data Structure for the Security Suitability of Cryptographic Al=
gorithms (DSSC)
Author(s) : T. Kunz, et al.
Filename : draft-ietf-ltans-dssc-05.txt
Pages : 41
Date : 2008-11-03

------=_NextPart_08111209141887344650666_002
Content-Type: text/html;
charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

1.=20
The abstract is only related to digitally signed data. The abstract shoul=
d be=20
extended to mention encryption.

It=20
should also mention that the use of a=20
weak cryptographic=20
algorithm within a complex data structure
can=20
be protected using a strong cryptographic=20
algorithm which then may render the whole data structure
adequate for=
its=20
intended use.

The=20
current abstract is the following:

=
In many=20
application areas it must be possible to prove the=20
existence

=
and integrity of digital signed=20
data.  This proof depends o=
n=20
the

=
security=20
suitability of the cryptographic algorithms used to=20
generate

=
or verify=20
the digital signature.  Bec=
ause=20
algorithms can become weak

=
over the=20
years, it is necessary to periodically evaluate=20
their

=
security=20
suitability.  When signing =
or=20
verifying data, these

=
=20
evaluations must be considered.&=
nbsp;=20
This document specifies a data

=
structure=20
that enables automated analysis of the security suitability=20

=
of=20
cryptographic algorithms.

=

Proposed change for the whole abstract to solve =
these two=20
comments:

=
Because=20
cryptographic algorithms can become weak over the years,=20

=
it is=20
necessary to evaluate their security suitability.

=
When=20
signing or verifying data, or when encrypting or decrypting=20

=
data,=20
these evaluations must be considered.&n=
bsp;=20
This document specifies

=
a data=20
structure that enables an automated analysis of the security=20

=
=20
suitability of a given cryptographic algorithm at a given point of=
=20

=
time=20
which may be in the past, at the present time or in the=20
future.

=

=
The automated processing of a cryptographi=
c data=20
structure that

uses several cryptographi=
c=20
algorithms cannot be performed only using

the previous =
automated=20
analysis, since in some cases a weak

=
cryptographic algorithm =
can be=20
protected by a strong cryptographic

algorithm which may make =
the whole=20
data structure adequate for its

intended use=
.=

2. Section 1.1. The text=20
sates:

=
If=20
algorithms lack the required properties, signatures could be=20
forged.

This=20
sentence should be changed into:

=
If=20
algorithms lack the required properties, signatures could be=20

=
forged, unless they are p=
rotected=20
by a strong cryptographic

=
algorithm,=20
e.g. a time-stamp token that uses a strong cryptographic

=
algorithm.

3. Section 1.1. The text=20
sates:

=
Very few=20
algorithms satisfy the security requirements and are=20

=
suitable for usage in=20
signatures.

This=20
is not fully correct.

This=20
sentence should be changed into:

Cryptographic algorithms =
that are=20
used in signatures shall resist

during their period of us=
e.  For signature keys included in =
public=20
key

certificates, it is the v=
alidity=20
period of the certificate.

Cryptographic algorithms =
that are=20
used for encryption shall resist

during the time during wh=
ich it is=20
planned to keep the information

confidential.=20

4. Section 1.1. The text=20
sates:

=
A digital signature using a "weak" algorithm has no =
probative=20
value.

This=20
is not fully correct.

This=20
sentence should be changed into:

=
A digital=20
signature using a "weak" algorithm has no probative value,=20

=
unless=20
the "weak" algorithm has been protected by a strong algorithm=20

=
before=20
the time it was considered to be weak.

5. Section 1.1. The text=20
sates:

=
For this reason, it is important=
to=20
periodically evaluate an

=
=20
algorithm's fitness and to consider the results of these=20
evaluations

=
when creating, verifying =
or=20
renewing signatures.

This=20
is not fully correct. A signature made by a human being that is dead cann=
ot be=20
"renewed".

This=20
sentence should be changed into:

=
For this=20
reason, it is important to periodically evaluate an

=
=20
algorithm's fitness and to consider the results of these=20
evaluations

=
when=20
creating and verifying signatures, or when maintaining the=20

=
validity of signatures ma=
de in the=20
past.

6. Section 1.1. The text=20
sates:

=
This=20
prediction can help to detect whether an insecure algorithm=20

=
is used=20
in a signature or whether a signature has been properly=20

=
preserved.

This=20
is not fully correct.

This=20
sentence should be changed into:

=
This=20
prediction can help to detect whether a weak algorithm=20

=
is used=20
in a signature and whether that signature has been properly=20

=
protected=20
in due time by an another signature made using an algorithm=20

=
that is suitable at the p=
resent=20
point of time.

7.=20
Definition of flexibility:

The=20
text states:

=
=20
Additionally the data structure must be designed independent of th=
e=20

=
intended=20
use, e.g., encryption, signing, verifying, and signature=20

=
=20
renewing.  Thus, the=
=20
interpretion of the data structure is same for <=
/P>

=
every use=20
case.

Firstly=20
there is typo on the word: =
interpretion

Secondly, the document does not define what is a si=
gnature=20
algorithm.

There=20
are three possible answers to that question, that may be illustrated
=
with=20
the RSA algorithm:

1) it is only the RSA=20
algorithm,

2) it is the RSA algorith=
m with a=20
padding function,

3) it is the RSA algorith=
m with a=20
padding function and a hash function.

The=20
text should clarify which case(s) are supported. If cases 2) or 3) are=20
supported,
then the above text is=20
incorrect.

8.=20
Section 2.2.:

The=20
text states:

=
An=20
algorithm is suitable if it is contained in the current policy=20
and

=
the time of interest is w=
ithin the=20
validity period.

This=20
sentence should be changed into:

=
An=20
algorithm is suitable *at a time of interest* if it is contained=20

=
in the=20
current policy and the time of interest is within the validity=20

=
period.

9. Section 5.5. This section should firs=
t add=20
another kind of output. Please add the following=20
text:

If the algorithm is not i=
n the=20
policy, an error "algorithm unknown" is

returned.

10. Section=20
5.5.

The=20
text states:

=
If the=20
algorithm is not suitable relative to the time of interest,=20

=
return an=20
error.

Change into:

=
If the=20
algorithm is not suitable relative to the time of interest,=20

an error "algorithm unsui=
table" is=20
returned.=

11. Section=20
5.5.

The=20
text states:

=
If the=20
algorithm is suitable, return the Evaluation elements=20
that

=
were not=20
discarded.

Change into:

=
If the=20
algorithm is suitable, return the Evaluation elements=20
that

=
were not=20
discarded, *in particular its validity period*.<=
/P>

12. Section 6. =
Security=20
Considerations

In=20
the comments made on draft-04, it has been requested to add text to warn =
the=20
user that
the processing rule described in section 5 is about *one*=20
algorithm *independently of the use case*.
Depending upon the use cas=
e, an=20
algorithm is no more suitable at the time of evaluation, may be
no pr=
oblem=20
at all.

Proposed text:

The processing rule descr=
ibed in=20
section 5 is about one =
cryptographic=20

=
algorithm=20
independently of the use case. =20
Depending upon the use case,

an algorithm that is no m=
ore=20
suitable at the time of interest, does not

necessarily mean that the=
data=20
structure where it is used is no more

secure.=

For example, an RSA signe=
r's key=20
of 1024 bits is being used in year

2009.  The validity period of the sign=
ature key=20
included in a public key

certificate is three year=
s.  The signature is time-stamped i=
n year=20
2009

with a time-stamp token t=
hat uses=20
an RSA key of 2048 bits.

This data structure is re=
valuated=20
in year 2020. Let us suppose that in

year 2015 an RSA key size=
of 1024=20
bits will be broken.  The f=
act that=20

the signature key of 1024=
bits is=20
no more suitable in year 2015 and

a fortiori in year 2020 d=
oes not=20
mean that the whole structure is no

more secure, if an RSA ke=
y size of=20
2048 bits is still suitable in

year 2020.

In addition, to the key s=
ize=20
considerations, other considerations

apply, like whether the t=
ime-stamp=20
token has been provided by a

trusted authority.  It means that the simple use of=
a=20
suitability

policy is not the single =
element=20
to consider when evaluating the

security of a complex dat=
a=20
structure using several cryptographic

algorithms.

13. Section 6. =
Security=20
Considerations

Proposed text:

=
=
Re-encrypting documents that we=
re=20
originally encrypted using an

=
algorithm=20
that is no more suitable, will not protect the semantics=20

=
of the=20
document, if the document has been intercepted.  However,

=
for=20
documents stored in an encrypted form, re-encryption must be=20

=
=20
considered, unless the document has lost its original value due to=
=20

=
time=20
erosion.

14. Appendix A.1. It should be indicated =
*in the=20
title* that this appendix is informative.

Denis<=
/P>

-----=20
Message re=E7u -----

De=20
: owner-ietf-ltan=
s=20

=C0=20
: i-d-announce

Date=20
: 2008-11-03, 16:45:01

Sujet=20
: I-D Action:draft-ietf-ltans-dssc-05.txt

Pi=E8ce(s) Jointe(s) au message original :=

Title : Data Structure for the Security Suitability of=
=20
Cryptographic Algorithms (DSSC)
Author(s) : T. Kunz, et=20
al.
Filename :=20
draft-ietf-ltans-dssc-05.txt
Pages : 41
D=
ate :=20
2008-11-03

In many application areas it must be possible to prov=
e the=20
existence
and integrity of digital signed data. This proof depends o=
n=20
the
security suitability of the cryptographic algorithms used to=20
generate
or verify the digital signature. Because algorithms can bec=
ome=20
weak
over the years, it is necessary to periodically evaluate=20
their
security suitability. When signing or verifying data,=20
these
evaluations must be considered. This document specifies a=20
data
structure that enables automated analysis of the security=20
suitability
of cryptographic algorithms.Conventions used in this=20
document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", =
"SHALL=20
NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" i=
n=20
this
document are to be interpreted as described in [RFC2119].
A URL=20
for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-05.txt
Internet-Drafts=20
are also available by anonymous FTP=20
at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data whi=
ch will=20
enable a MIME compliant mail reader
implementation to automatically=20
retrieve the ASCII version of=20
the
Internet-Draft.

------=_NextPart_08111209141887344650666_002--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3Fj0ga053060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 08:45:00 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA3Fj0Po053057; Mon, 3 Nov 2008 08:45:00 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA3Fj0vt053037 for ; Mon, 3 Nov 2008 08:45:00 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 6B3173A69E9; Mon, 3 Nov 2008 07:45:01 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ltans-dssc-05.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Mon, 3 Nov 2008 07:45:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--NextPart

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-ltans-dssc-05.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA2IF0Mh056225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Nov 2008 11:15:00 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id mA2IF06d056224; Sun, 2 Nov 2008 11:15:00 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id mA2IF02r056218 for ; Sun, 2 Nov 2008 11:15:00 -0700 (MST) (envelope-from [email-masked])
Received: by core3.amsl.com (Postfix, from userid 0) id 457BC3A67D0; Sun, 2 Nov 2008 10:15:00 -0800 (PST)
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ltans-ltap-07.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[email-masked]>
Date: Sun, 2 Nov 2008 10:15:01 -0800 (PST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

--NextPart

Title : Long-term Archive Protocol (LTAP)
Author(s) : A. Jerman-Blazic, et al.
Filename : draft-ietf-ltans-ltap-07.txt
Pages : 64
Date : 2008-11-02

This document describes a service operated as a trusted third party
to securely archive electronic documents called a long-term archive
service (LTA). We describe an architecture framework and a protocol
allowing clients to interact with such a service. Bindings to
concrete transport and security protocol layers are given.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ltans-ltap-07.txt

--NextPart
Content-Type: Message/External-body;
name="draft-ietf-ltans-ltap-07.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--