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

From: [email-masked]
Date: Wed, 8 Oct 2008 00:45:01 -0700 (PDT)

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 Security Suitabilities of Cryptographic Algorithms (DSSC)
	Author(s)       : T. Kunz, et al.
	Filename        : draft-ietf-ltans-dssc-04.txt
	Pages           : 41
	Date            : 2008-10-08

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 these
security suitabilities.  When signing or verifying data, these
evaluations must be considered.  This document specifies a data
structure that enables automated analysis of the security
suitabilities 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-04.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: "Carl Wallace" <[email-masked]>
Date: Wed, 8 Oct 2008 08:15:59 -0400

This draft is the result of some offlist comments submitted during WG
last call for the -03 draft.  Last call for this version will start
today and end on October 24th.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, October 08, 2008 3:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ltans-dssc-04.txt 

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 Security Suitabilities of
Cryptographic Algorithms (DSSC)
	Author(s)       : T. Kunz, et al.
	Filename        : draft-ietf-ltans-dssc-04.txt
	Pages           : 41
	Date            : 2008-10-08

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 these security
suitabilities.  When signing or verifying data, these evaluations must
be considered.  This document specifies a data structure that enables
automated analysis of the security suitabilities of cryptographic
algorithms.Conventions used in this document

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 21 Oct 2008 08:51:15 +0200

Comments on draft-ietf-ltans-dssc-04
 
1. The title of the document is: “Data Structure for Security Suitabilities of Cryptographic 
Algorithms”.
 
The document states that the data structure is independent of the intended use (page 8); 
therefore, it cannot be said if an algorithm is *suitable* for any intended purpose. Note that 
“Suitabilities” should always be used with the singular: Suitability. 
 
Replace with: “Data Structure to Estimate the Validity Period of Cryptographic Algorithms”.

2. The acronym DSSC should be changed into: DSEC (Data Structure to Estimate 
Cryptographic algorithms).

3. The start of the abstract is only related to digitally signed data. However, the fourth use 
case is about re-encryption, but such a use case is not mentioned in the abstract. The abstract 
should be extended to mention encryption.

4. This draft defines a data structure which estimates the validity period of cryptographic 
algorithms independently of the intended use. The text states in the abstract: “This document 
specifies a data structure that enables automated analysis of the security suitabilities of 
cryptographic algorithms”.
 
This sentence should be corrected. The document states that the data structure is independent 
of the intended use (page 8); therefore, it cannot be said if an algorithm is *suitable* for any 
intended purpose. See the comment on the security considerations section for further 
explanations.
 
Proposed replacement:
 
“This document specifies a data structure that enables an automated estimation of the validity 
period of a single cryptographic algorithm at a time. The automated processing of a 
cryptographic data structure that includes one or more cryptographic algorithms needs to be 
tailored to a specific use case and is outside the scope of this document”.

5. On page 5, the term "security suitability policy" is being used. The data structure is a set of 
rules which allows to estimate the validity period of various cryptographic algorithms. The 
wording "security suitability policy" should not be used, because the word “suitable” implies 
that the algorithm would be suitable in a specific context and there is no such context.
 
Replace the term "security suitability policy” by “cryptographic resistance policy”.
 
The word “suitable” should be replaced in many instances in this document.

6. In the requirements section (2.1), it is mentioned that the integrity and authenticity of a 
published "data structure" must be assured. Since the previous requirement is source 
authentication, this requirement should not be mandatory. In fact, the document considers the 
signature of the data structure as an option, which is fine.

7. In the requirements section (2.1), a requirement is missing: the date of issue of the data 
structure shall be indicated. In fact, the document considers the date of issue as mandatory, 
which is fine.

8. In the assumptions section (2.2), it is mentioned that "an algorithm is valid if it is contained 
in the current policy and the time of interest is within the validity period". This assumption is 
incorrect. The data structure should be usable to tell "until when" a given algorithm was or 
will be usable, instead of simply telling "valid".
 
When estimating the cryptographic resistance of an algorithm with this data structure, the 
output should not simply be "valid" or "invalid", but "valid until XXXX".

9. Section 3.12 is about the validity element. The last sentence of the paragraph defines a 
processing rule which is the following:
 
"If the end of the validity period is in the past, the algorithm is not suitable".
 
This sentence should be replaced with: 
 
"If the end of the validity period is in the past, the algorithm was suitable until that date".

10. Section 5 is about "Processing".
 
The text states: “In the following, a process is described that can be used to determine if an 
algorithm was valid at a particular point of time”.
 
“Valid” is not the right word. The algorithm was resistant against estimated attacks at a 
particular point of time”.
 
Replace with: “In the following, a process is described that can be used to determine if one 
algorithm was resistant against real or estimated attacks at a particular point of time”.

11. Section 5.3 states: "To determine if an algorithm is valid ...". This sentence should be 
changed into: "To determine the validity period of an algorithm...". Similar changes need to 
be made in the text that follows.

12. Section 5.5 mentions that if the algorithm is not valid, an error is returned. It would be 
more adequate to return the Evaluation elements so that a decision can be made, which is 
dependent both upon the context of use and the data structure where the algorithm is being 
used.
 
Both sentences from this section should be replaced by.
" If the algorithm is in the table, the Evaluation elements are returned. 
Otherwise an error "algorithm unknown" is returned".

13. Section 6. This section should be expanded to warn the user that the processing rules 
described in section 5 are about *one* algorithm at a time *independently of the use case*. 
Depending upon the use case, if an algorithm is no more resistant at the time of evaluation, 
this may be no problem at all.
 
Let us take an example: an RSA signer's key of 900 bits is being used. If an evaluation is 
made in year 2015, this key size will probably be broken. Is the algorithm unsuitable in 2015? 
This fully depends upon the use case and upon the elements of the data structure that are 
evaluated. Example: if the signature was time-stamped with an RSA signature key of 2048 
bits, before an RSA key size of 900 bits was broken, then the data structure is fine. If it was 
not, the *data structure* is no more resistant at the time of evaluation.
 
Another example is the use of a MD5 hash function. If this hash function is being used in a 
data structure, but the data has been rehashed with SHA-256 before MD5 was "broken", then 
the data structure is fine.

14. Section 8. The informative reference [ETSI-TS101903] is obsolete. The last version is:
ETSI TS 101 903 V1.3.2 (2006-03).

15. Section 8. The informative reference [ETSI-TS102176-1-2005] is obsolete. The last 
version is: ETSI TS 102 176-1 V2.0.0 (2007-11).

16. Appendix A.1. It should be indicated that this appendix is informative.

17. Appendix A.1 is a specific use case. If a hash function in the inner timestamp is no more 
resistant, does it means that the whole structure is invalid ? If yes, does ERS provides a way 
to protect against this threat ? More explanations should be provided.

18. Appendix A.2. It should be indicated that this appendix is normative.

19. Appendix B. It should be indicated that this appendix is normative.

20. Appendix C. It should be indicated that this appendix is informative.

21. Appendix D. It should be indicated that this appendix is normative.
 
Denis

---

From: Thomas Kunz <[email-masked]>
Date: Thu, 23 Oct 2008 10:19:27 +0200

Thanks for your comments.
We will try to consider the comments in the draft.

- Thomas

---

From: Thomas Kunz <[email-masked]>
Date: Wed, 29 Oct 2008 11:37:19 +0100

Comments inline...

Denis Pinkas schrieb:
> 1. The title of the document is: “Data Structure for Security 
> Suitabilities of Cryptographic Algorithms”.
> The document states that the data structure is independent of the 
> intended use (page 8); therefore, it cannot be said if an algorithm 
 > is *suitable* for any intended purpose.
 >
> Note that “Suitabilities” should always be used with the singular: Suitability.
> 
We don't agree with your suggested title. The data structure is used to 
express policies which are *not* independent of the intended use (see 
the definition in the terminology). For this reason, the data structure 
contains the "Usage" element. The data structure itself can be used in 
different use cases. But one policy doesn't necessarily express that an 
algorithm is suitable for any intended purpose.
We will try to clarify this issue in the draft.

> 
> 2. The acronym DSSC should be changed into: DSEC (Data Structure to 
> Estimate Cryptographic algorithms).
> 
For the above mentioned reasons, will will keep the acronym DSSC and 
will only change "Suitabilities" to "Suitability".

> 
> 3. The start of the abstract is only related to digitally signed data. 
> However, the fourth use case is about re-encryption, but such a 
 > use case is not mentioned in the abstract. The abstract
OK, we will try to include this in the abstract.

> 
> 4. This draft defines a data structure which estimates the validity 
> period of cryptographic algorithms independently of the intended use. 
 > The text states in the abstract: “This document
> specifies a data structure that enables automated analysis of the 
> security suitabilities of cryptographic algorithms”.
> This sentence should be corrected. The document states that the data 
> structure is independent of the intended use (page 8); therefore, it cannot be said if an 
> algorithm is *suitable* for any intended purpose. See the comment 
 > on the security considerations section
> for further explanations.
>  
see above

>  
> 
> 6. In the requirements section (2.1), it is mentioned that the integrity 
> and authenticity of a published "data structure" must be assured. Since the previous 
> requirement is source authentication, this requirement should not be mandatory. In fact, the 
> document considers the
OK

> 
> 7. In the requirements section (2.1), a requirement is missing: the date 
> of issue of the data structure shall be indicated. In fact, the document considers the date 
> of issue as mandatory, which is fine.
> 
Good point, we will add this requirement.

> 
> 8. In the assumptions section (2.2), it is mentioned that "an algorithm 
> is valid if it is contained in the current policy and the time of interest 
 > is within the validity period". This assumption is
> incorrect. The data structure should be usable to tell "until when" a 
> given algorithm was or will be usable, instead of simply telling "valid".
> 
We think the assumption is correct. An algorithm is valid or suitable if 
it is contained in the current policy and the time of interest
is within the validity period. Of course the data structure is able to 
tell until when an algorithm was or will be valid, but this has nothing 
to do with this assumption.
In the "processing" section, we give the time of interest as input (i.e. 
we ask if an algorithm is or was valid at this point of time; we don't 
ask until when an algorithm was or will be valid).

>  
> 
> 9. Section 3.12 is about the validity element. The last sentence of the 
> paragraph defines a processing rule which is the following:
OK.

> The text states: “In the following, a process is described that can be 
> used to determine if an algorithm was valid at a particular point of time”.
> “Valid” is not the right word. The algorithm was resistant against 
> estimated attacks at a particular point of time”.
> 
> Replace with: “In the following, a process is described that can be used 
> to determine if one algorithm was resistant against real or estimated attacks at a 
In our context we use "valid" and "suitable" synonymic to each other. We 
will try to clarify this in the terminology.

>  
> 
> 13. Section 6. This section should be expanded to warn the user that the 
> processing rules described in section 5 are about *one* algorithm at a time 
> *independently of the use case*.
> Depending upon the use case, if an algorithm is no more resistant at the 
> time of evaluation, this may be no problem at all.
> 
> Let us take an example: an RSA signer's key of 900 bits is being used. 
> If an evaluation is made in year 2015, this key size will probably be 
 > broken. Is the algorithm unsuitable in 2015?
> This fully depends upon the use case and upon the elements of the data 
> structure that are evaluated. Example: if the signature was time-stamped 
 > with an RSA signature key of 2048
> bits, before an RSA key size of 900 bits was broken, then the data 
> structure is fine. If it was not, the *data structure* is no more resistant 
 > at the time of evaluation.

> Another example is the use of a MD5 hash function. If this hash function 
> is being used in a data structure, but the data has been rehashed with 
 > SHA-256 before MD5 was "broken", then the data structure is fine.
> 
We don't see the need for this warning. The data structure is solely 
about evaluating algorithms, not about evaluating data structures which 
use these algorithms. To take your example, the data structure is used 
to verify if RSA with 900 bit was valid at the point of time when the 
signature was time-stamped with 2048 bit key.
We think the document sufficiently illustrate this issue.

Thomas

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 29 Oct 2008 11:13:32 -0700

Guys
----- Original Message ----- 
From: "Thomas Kunz" <[email-masked]>
To: <[email-masked]>
Cc: "IETF LTANS" <[email-masked]>
Sent: Wednesday, October 29, 2008 3:37 AM
Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt

> We don't agree with your suggested title.

I love the title it means that there is a likelyhood that Deni's masterpiece 
is already covered by my Patent issuance. However I also suggest changing 
it.

> The data structure is used to
> contains the "Usage" element.

Agreed

> The data structure itself can be used in
> different use cases.

As a policy control object - with a reliable source of information relative 
to time and location - that for sure is covered under our patent.

> But one policy doesn't necessarily express that an

OK.

> OK, we will try to include this in the abstract.

No folks... ABSOLUTELY NO... From an "evidentiary perspecitve" the interior 
content (i.e. the Crypto-payload) cannot be resigned except in the form of 
newly included encapsulation or it will break every digital evidence 
standard on this planet. Simply put the resigning of the content unless it 
is a layered encapsulation will IMHO destroy the provable Chain of Custody 
such that the content's anti-spoliation controls would be meaningless before 
a Court with any attorney's that get it.

 If however you had a "Ceremony in Software" that would allow that data to 
be 'de-signed' and reduced to its original state there might be a process 
for this but that is included in my new amendment to the existing patent so 
it also is protected.

>> and authenticity of a published "data structure" must be assured. \

that's actually supposed to be a MUST not a 'must'.

> > Since the previous

Which again destroys the integrity of the CHAIN OF CUSTODY making the 
evidence produced hear-say at best.

> Good point, we will add this requirement.

Depending on what the DATE control is used for there are a number other 
issues including of all things McNeil's and my patent.

>> given algorithm was or will be usable, instead of simply telling "valid".

This is an issue - there is an ASSUMPTION here which should not be. NOTHING 
about EVIDENCE and its protection can be assumed. Proof for each assertion 
MUST be part of the control process.

>> suitable until that date".

Uh - expired time-stamps and ALG Identifiers are ONLY persuant to how an 
individual record was 'stored' - the expiry of this is worthless unless 
something actually happens. So what is it that this expiry is setup for?

> We think the document sufficiently illustrate this issue.

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.4/1754 - Release Date: 10/29/2008 
7:45 AM

From: "TS Glassey" <[email-masked]>
To: "Thomas Kunz" <[email-masked]>, <[email-masked]>
Cc: "IETF LTANS" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt
Date: Wed, 29 Oct 2008 11:13:32 -0700
Sender: [email-masked]

Guys
----- Original Message ----- 
From: "Thomas Kunz" <[email-masked]>
To: <[email-masked]>
Cc: "IETF LTANS" <[email-masked]>
Sent: Wednesday, October 29, 2008 3:37 AM
Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt

> We don't agree with your suggested title.

I love the title it means that there is a likelyhood that Deni's masterpiece 
is already covered by my Patent issuance. However I also suggest changing 
it.

> The data structure is used to
> contains the "Usage" element.

Agreed

> The data structure itself can be used in
> different use cases.

As a policy control object - with a reliable source of information relative 
to time and location - that for sure is covered under our patent.

> But one policy doesn't necessarily express that an

OK.

> OK, we will try to include this in the abstract.

No folks... ABSOLUTELY NO... From an "evidentiary perspecitve" the interior 
content (i.e. the Crypto-payload) cannot be resigned except in the form of 
newly included encapsulation or it will break every digital evidence 
standard on this planet. Simply put the resigning of the content unless it 
is a layered encapsulation will IMHO destroy the provable Chain of Custody 
such that the content's anti-spoliation controls would be meaningless before 
a Court with any attorney's that get it.

 If however you had a "Ceremony in Software" that would allow that data to 
be 'de-signed' and reduced to its original state there might be a process 
for this but that is included in my new amendment to the existing patent so 
it also is protected.

>> and authenticity of a published "data structure" must be assured. \

that's actually supposed to be a MUST not a 'must'.

> > Since the previous

Which again destroys the integrity of the CHAIN OF CUSTODY making the 
evidence produced hear-say at best.

> Good point, we will add this requirement.

Depending on what the DATE control is used for there are a number other 
issues including of all things McNeil's and my patent.

>> given algorithm was or will be usable, instead of simply telling "valid".

This is an issue - there is an ASSUMPTION here which should not be. NOTHING 
about EVIDENCE and its protection can be assumed. Proof for each assertion 
MUST be part of the control process.

>> suitable until that date".

Uh - expired time-stamps and ALG Identifiers are ONLY persuant to how an 
individual record was 'stored' - the expiry of this is worthless unless 
something actually happens. So what is it that this expiry is setup for?

> We think the document sufficiently illustrate this issue.

--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.8.4/1754 - Release Date: 10/29/2008 
7:45 AM

Date: Wed, 29 Oct 2008 11:37:19 +0100
From: Thomas Kunz <[email-masked]>
To: [email-masked]
CC: IETF LTANS <[email-masked]>
Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt
Sender: [email-masked]

Comments inline...

see above

OK

OK.

Thomas

Date: Thu, 23 Oct 2008 10:19:27 +0200
From: Thomas Kunz <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D Action:draft-ietf-ltans-dssc-04.txt
Sender: [email-masked]

- Thomas

Denis Pinkas schrieb:
> Suitabilities of Cryptographic
> 
> Algorithms”.
> 
>  
> 
> intended use (page 8);
> Estimate
> However, the fourth use
> period of cryptographic
> security suitabilities of
> 
> structure is independent
> and authenticity of a
> of issue of the data
> is valid if it is contained
> 
> given algorithm was or
> paragraph defines a
> used to determine if an
> estimated attacks at a
> to determine if one
> processing rules
> time of evaluation,
> If an evaluation is
> structure that are
> structure is fine. If it was
> 
> is being used in a

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "owner-ietf-ltans"<[email-masked]>, "IETF LTANS"<[email-masked]>
Subject: RE: I-D Action:draft-ietf-ltans-dssc-04.txt
Date: Tue, 21 Oct 2008 08:51:15 +0200
Sender: [email-masked]

------=_NextPart_08102108510267074778150_002
Content-Transfer-Encoding: 8Bit
Content-Type: text/plain; 
	charset="ISO-8859-1"

 

 
 
Proposed replacement:

 

 

 

 

 

 

 
Denis

-----Original Message-----

------=_NextPart_08102108510267074778150_002
Content-Transfer-Encoding: 8bit
Content-Type: text/html; 
	charset="ISO-8859-1"

<HTML><HEAD><TITLE></TITLE>
<META content="KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, © Kurt Senfer" 
name=GENERATOR>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1"></HEAD>
<BODY style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=5 topMargin=5 
#ffffff>
<DIV>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Comments on 
draft-ietf-ltans-dssc-04<?xml:namespace prefix = o ns = 
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New"></FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">1. The title of the 
document is: “Data Structure for Security Suitabilities of Cryptographic 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT 
face="Courier New">Algorithms”.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">The document states 
that the data structure is independent of the intended use (page 8); 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">therefore, it cannot 
be said if an algorithm is *suitable* for any intended purpose. Note that 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">“Suitabilities” should 
always be used with the singular: Suitability. <o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Replace with: “Data 
Structure to Estimate the Validity Period of Cryptographic 
Algorithms”.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">2. The acronym DSSC 
should be changed into: DSEC (Data Structure to Estimate 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Cryptographic 
algorithms).<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">3. The start of the 
abstract is only related to digitally signed data. However, the fourth use 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">case is about 
re-encryption, but such a use case is not mentioned in the abstract. The 
abstract <o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">should be extended to 
mention encryption.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">4. This draft defines 
a data structure which estimates the validity period of cryptographic 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">algorithms 
independently of the intended use. The text states in the abstract: “This 
document <o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">specifies a data 
structure that enables automated analysis of the security suitabilities of 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">cryptographic 
algorithms”.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">This sentence should 
be corrected. The document states that the data structure is independent 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">of the intended use 
(page 8); therefore, it cannot be said if an algorithm is *suitable* for any 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">intended purpose. See 
the comment on the security considerations section for further 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT 
face="Courier New">explanations.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Proposed 
replacement:<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">“This document 
specifies a data structure that enables an automated estimation of the validity 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">period of a single 
cryptographic algorithm at a time. The automated processing of a 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">cryptographic data 
structure that includes one or more cryptographic algorithms needs to be 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">tailored to a specific 
use case and is outside the scope of this 
document”.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">5. On page 5, the term 
"security suitability policy" is being used. The data structure is a set of 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">rules which allows to 
estimate the validity period of various cryptographic algorithms. The 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">wording "security 
suitability policy" should not be used, because the word “suitable” implies 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">that the algorithm 
would be suitable in a specific context and there is no such 
context.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Replace the term 
"security suitability policy” by “cryptographic resistance 
policy”.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">The word “suitable” 
should be replaced in many instances in this 
document.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">6. In the requirements 
section (2.1), it is mentioned that the integrity and authenticity of a 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">published "data 
structure" must be assured. Since the previous requirement is source 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">authentication, this 
requirement should not be mandatory. In fact, the document considers the 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">signature of the data 
structure as an option, which is fine.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">7. In the requirements 
section (2.1), a requirement is missing: the date of issue of the data 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">structure shall be 
indicated. In fact, the document considers the date of issue as mandatory, 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">which is 
fine.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">8. In the assumptions 
section (2.2), it is mentioned that "an algorithm is valid if it is contained 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">in the current policy 
and the time of interest is within the validity period". This assumption is 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">incorrect. The data 
structure should be usable to tell "until when" a given algorithm was or 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">will be usable, 
instead of simply telling "valid".<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">When estimating the 
cryptographic resistance of an algorithm with this data structure, the 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">output should not 
simply be "valid" or "invalid", but "valid until 
XXXX".<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">9. Section 3.12 is 
about the validity element. The last sentence of the paragraph defines a 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">processing rule which 
is the following:<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">"If the end of the 
validity period is in the past, the algorithm is not 
suitable".<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">This sentence should 
be replaced with: <o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">"If the end of the 
validity period is in the past, the algorithm was suitable until that 
date".<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">10. Section 5 is about 
"Processing".<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">The text states: “In 
the following, a process is described that can be used to determine if an 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">algorithm was valid at 
a particular point of time”.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">“Valid” is not the 
right word. The algorithm was resistant against estimated attacks at a 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">particular point of 
time”.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Replace with: “In the 
following, a process is described that can be used to determine if one 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">algorithm was 
resistant against real or estimated attacks at a particular point of 
time”.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">11. Section 5.3 
states: "To determine if an algorithm is valid ...". This sentence should be 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">changed into: "To 
determine the validity period of an algorithm...". Similar changes need to 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">be made in the text 
that follows.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">12. Section 5.5 
mentions that if the algorithm is not valid, an error is returned. It would be 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">more adequate to 
return the Evaluation elements so that a decision can be made, which is 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">dependent both upon 
the context of use and the data structure where the algorithm is being 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT 
face="Courier New">used.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Both sentences from 
this section should be replaced by.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">" If the algorithm is 
in the table, the Evaluation elements are returned. 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Otherwise an error 
"algorithm unknown" is returned".<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">13. Section 6. This 
section should be expanded to warn the user that the processing rules 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">described in section 5 
are about *one* algorithm at a time *independently of the use case*. 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Depending upon the use 
case, if an algorithm is no more resistant at the time of evaluation, 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">this may be no problem 
at all.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Let us take an 
example: an RSA signer's key of 900 bits is being used. If an evaluation is 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">made in year 2015, 
this key size will probably be broken. Is the algorithm unsuitable in 2015? 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">This fully depends 
upon the use case and upon the elements of the data structure that are 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">evaluated. Example: if 
the signature was time-stamped with an RSA signature key of 2048 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">bits, before an RSA 
key size of 900 bits was broken, then the data structure is fine. If it was 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">not, the *data 
structure* is no more resistant at the time of 
evaluation.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">Another example is the 
use of a MD5 hash function. If this hash function is being used in a 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">data structure, but 
the data has been rehashed with SHA-256 before MD5 was "broken", then 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">the data structure is 
fine.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">14. Section 8. The 
informative reference [ETSI-TS101903] is obsolete. The last version 
is:<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">ETSI TS 101 903 V1.3.2 
(2006-03).<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">15. Section 8. The 
informative reference [ETSI-TS102176-1-2005] is obsolete. The last 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">version is: ETSI TS 
102 176-1 V2.0.0 (2007-11).<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">16. Appendix A.1. It 
should be indicated that this appendix is 
informative.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">17. Appendix A.1 is a 
specific use case. If a hash function in the inner timestamp is no more 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">resistant, does it 
means that the whole structure is invalid ? If yes, does ERS provides a way 
<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">to protect against 
this threat ? More explanations should be provided.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">18. Appendix A.2. It 
should be indicated that this appendix is 
normative.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">19. Appendix B. It 
should be indicated that this appendix is 
normative.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">20. Appendix C. It 
should be indicated that this appendix is 
informative.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><FONT face="Courier New">21. Appendix D. It 
should be indicated that this appendix is 
normative.<o:p></o:p></FONT></SPAN></P>
<P class=MsoPlainText style="MARGIN: 0cm 0cm 0pt"><SPAN lang=EN-GB 
style="mso-ansi-language: EN-GB"><o:p><FONT 
face="Courier New">&nbsp;</FONT></o:p></SPAN></P></DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal">----- 
  Message reçu ----- </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: black"><B>De 
  :</B> <A href="mailto :[email-masked]">owner-ietf-ltans</A> 
  </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>À 
  :</B> <A href="mailto :[email-masked]">ietf-ltans</A> </DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Date 
  :</B> 2008-10-08, 14:15:59</DIV>
  <DIV 
  style="FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal"><B>Sujet 
  :</B> RE: I-D Action:draft-ietf-ltans-dssc-04.txt</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV>
  <DIV>This draft is the result of some offlist comments submitted during 
  WG<BR>last call for the -03 draft. Last call for this version will 
  start<BR>today and end on October 24th.<BR><BR>-----Original 
  Message-----<BR>From: <A 
  href="mailto: [email-masked]">[email-masked]</A><BR>[mailto:<A 
  href="mailto: [email-masked]">[email-masked]</A>] 
  On Behalf Of<BR><A 
  href="mailto: [email-masked]">[email-masked]</A><BR>Sent: 
  Wednesday, October 08, 2008 3:45 AM<BR>To: <A 
  href="mailto: [email-masked]">[email-masked]</A><BR>Cc: <A 
  href="mailto: [email-masked]">[email-masked]</A><BR>Subject: I-D 
  Action:draft-ietf-ltans-dssc-04.txt <BR><BR>A New Internet-Draft is available 
  from the on-line Internet-Drafts<BR>directories.<BR>This draft is a work item 
  of the Long-Term Archive and Notary Services<BR>Working Group of the 
  IETF.<BR><BR><BR>&nbsp;&nbsp;Title : Data Structure for Security Suitabilities 
  of<BR>Cryptographic Algorithms (DSSC)<BR>&nbsp;&nbsp;Author(s) : T. Kunz, et 
  al.<BR>&nbsp;&nbsp;Filename : 
  draft-ietf-ltans-dssc-04.txt<BR>&nbsp;&nbsp;Pages : 41<BR>&nbsp;&nbsp;Date : 
  2008-10-08<BR><BR>In many application areas it must be possible to prove the 
  existence and<BR>integrity of digital signed data. This proof depends on the 
  security<BR>suitability of the cryptographic algorithms used to generate or 
  verify<BR>the digital signature. Because algorithms can become weak over 
  the<BR>years, it is necessary to periodically evaluate these 
  security<BR>suitabilities. When signing or verifying data, these evaluations 
  must<BR>be considered. This document specifies a data structure that 
  enables<BR>automated analysis of the security suitabilities of 
  cryptographic<BR>algorithms.Conventions used in this document<BR><BR>The key 
  words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",<BR>"SHOULD", 
  "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this<BR>document are to 
  be interpreted as described in [RFC2119].<BR><BR>A URL for this Internet-Draft 
  is:<BR><A 
  href="http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-04.txt">http://www.ietf.org/internet-drafts/draft-ietf-ltans-dssc-04.txt</A><BR><BR>Internet-Drafts 
  are also available by anonymous FTP 
  at:<BR>ftp://ftp.ietf.org/internet-drafts/<BR><BR>Below is the data which will 
  enable a MIME compliant mail reader<BR>implementation to automatically 
  retrieve the ASCII version of 
the<BR>Internet-Draft.<BR><BR><BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_08102108510267074778150_002--

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-ltans-dssc-04.txt 
Date: Wed, 8 Oct 2008 08:15:59 -0400
From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

-----Original Message-----
Subject: I-D Action:draft-ietf-ltans-dssc-04.txt=20

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ltans-dssc-04.txt 
Date: Wed,  8 Oct 2008 00:45:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

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

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

--NextPart--