Subject: ERS - using hash tree?

From: "Jesus Maria Mendez Perez" <[email-masked]>
Date: Thu, 22 Nov 2007 18:48:21 +0100

Hello,

I´m Jesus and I don´t understand some aspects about using the
hash-tree to preserving data objects.

According to ERS if you have 4 data objects the working will be the next one:

			------		------		------		------
			| d1 |        | d2 |	      | d3 |	     | d4 |
			------		------		------		------
			   |		    |		    |		    |
			   |		    |		    |		    |
			------		------		------		------
			| h1 |        | h2 |	      | h3 |	     | h4 |
			------		------		------		------
			    |	            |		   |		    |
				 |       |			|      |
				    |				   |
				--------			------
				| h12 |			     | h34 |
				--------			------
				    |			           |		
				          |		    |
				    		    |
						-----------
						| h1234 |
						-----------
		   				     |
						--------------
						| TSh1234 |
				  		--------------

where "d" are the data objects and "h" are the hash of the data
objects and "TS" is the timestamp.

In this case you´ll have to do 7 hashes and the additional timestamping.

Then, what is the meaning of building the hash tree if you really
after of building it you can´t add or remove any data object?.

You can simply add the 4 hashes of the 4 data objects and do the finish hash.
Then we´ll have to do 5 hashes and the additonal timestamping versus 7
hashes we had before.

			------		------		------		------
			| d1 |        | d2 |	     | d3 |         | d4 |
			------		------		------		------
			   |		    |		    |		    |
			   |		    |		    |		    |
			------		------		------		------
			| h1 |   +   | h2 |   +	   | h3 |   +	  | h4 |
			------		------		------		------
			       |           |		   |		  |
				    |        |            |           |
					|	|       |	  |
					-------------------------
					| 	h1234         |
					-------------------------
						    |
					----------------------------
					|        TSh1234      |
					---------------------------

I dont know if we could do it this last way or if i don´t understand
the processing of Generation and Verification at all..

Thanks.

---

From: "Tobias Gondrom" <[email-masked]>
Date: Thu, 22 Nov 2007 19:27:01 +0100

Hello Jesus, 

1. 
> after of building it you can´t add or remove any data object?.

Yes, after you completed the hashtree and protect it with a timestamp you can not add further nodes. (Comment: Typical ERS-systems build one hashtree per day for all documents that were archived during that day and sign the hashtree every evening with a timestamp.)

2. Arity (number of branches at each node) of the hashtree: 
Actually the arity of the hash tree is not restricted by the ERS standard and can be decided by the implementer. 
Several performance and efficiency tests I have seen, have shown that typically a tertiary (or binary) hashtree offers the highest efficiency and performance when handling larger numbers of documents. 

E.g. hashtree for about 2000 documents
With tertiary: 
2187 nodes on the lowest level
729 nodes on 2nd level
243 nodes on 3rd level
81 nodes on 4th level
27 nodes on 5th level
9 nodes on 6th level
3 nodes on 7th level
And the timestamp at the top. 

That way the reduced ERS for one specific document is a lot smaller as it does not need to contain all 2000 nodes of all neighbours, but a lot less.

Plus other operational parameters have also been more efficient. 
(Typically I would recommend a tertiary tree.)

But if you like you can also use a tree with arity n, e.g. n=1000 or n=1.000.000. 

Hope this helps, Tobias

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Jesus Maria Mendez Perez
> Sent: Thursday, November 22, 2007 6:48 PM
> To: [email-masked]
> Subject: ERS - using hash tree?
> 
> 
> Hello,
>

---

From: "Jesus Maria Mendez Perez" <[email-masked]>
Date: Tue, 27 Nov 2007 16:54:59 +0100

> Yes, after you completed the hashtree and protect it with a timestamp you can not add further nodes. (Comment: Typical ERS-systems build one hashtree per day for all documents that were archived du…

Then, if I want to preserve some documents in the same day, for
example 3, and to archive them during differents periods of time, the
first one (d1) until 01-12-07, the second (d2) until 15-12-07 and the
last one (d3) until 01-01-08 for example and I send independently to
the TAS server.

How have they been manage?
What evidences are the TAS server archiving?
Has the TAS server to built 2 evidences? (first to preserve each
document separately (Fig 1))

 		        -----                    ------        	             ------
                       | d1 |           	| d2 |         	           |
d3 |
                       ------                    ------        	
      ------
                          |                	   |
    |
                          |                        |
        |
                       ------         	         -------       	
    ------
                       | h1 |        	        | h2 |   	         | h3 |
                       ------                    -----       	
   ------
		          |                         |         	               |
                 ----------------          -------------------
---------------------
               | TS(01-12-07) |      |  TS(15-12-07 |     | TS(01-01-08) |
                ------------------         -------------------
--------------------
                                         Fig 1

and after that a second evidence to include them in the evening
hash-tree (Fig 2)?
Suppose another user, send during the same day the document
"anotherd4". In the same day only were sent d1,d2,d3 and anotherd4.

      		        ------          ------          ------          ---------------
                       | d1 |        | d2 |          | d3 |         |
anotherd4 |
                       ------          ------          ------
----------------
                          |                |               |               |
                          |                |               |               |
                       ------          ------          ------          ------
                       | h1 |        | h2 |          | h3 |         | h4 |
                       ------          ------          ------          ------
                           |               |              |                |
                                |       |                      |      |
                                   |                              |
                               --------                        ------
                               | h12 |                      | h34 |
                               --------                        ------
                                   |                              |
                                         |                 |
                                                   |
                                               -----------
                                               | h1234 |
                                               -----------
                                                    |
                                               --------------
                                               | TSh1234 |
                                               --------------
		 	    Fig 2

And what is the evening's timestamp during?

Another doubt: But then can I send a group of documents to preserving
and preserve it independently all other (Fig 3), (without including
them in the evening hash-tree)?
Can I decide what groups of documents form the evening-hash-tree? Can
the TAS server archive "little" hash-trees, like folders and in every
folder contains the hash tree of a group of documents?

                   ------          ------               |
                  | d1 |        | d2 |         	      |
                   ------          ------          	|
                     |                |                 |
  And, in this side
                     |                |                 |
 the evenging hash tree
                   ------          ------               |
                   | h1 |        | h2 |               |
                   ------          ------               |
                      |               |                 |
                         |       |                      |
                            |                           |
                        --------                        |
                       | h12 |                        |
                        --------                       |
                          |                            |
                          |                            |
		      ------------                     |
		     |  TS12    |                   |
	              ------------

I try to explain the best I can..

Thanks Tobias

---

From: "Tobias Gondrom" <[email-masked]>
Date: Wed, 28 Nov 2007 15:54:13 +0100

Hello Jesus, 

Hm, am not sure I understand your question completely, but let me explain a bit more about ERS. (if you like we can also talk in at the Vancouver meeting next week, or you can give me a short call, as this is maybe a lot easier in person or via phone.) 

However: 
Typically you will build one hashtree per time interval (e.g. lets say per day) for all your documents independent of how long you want to keep the individual documents. 

Lets say you get one day 2 groups of 3 documents each and a set of 5 individual documents (d1...d5). 
Then you would e.g. group them on the lowest level in four groups: group-1 group-2 and a generic group-3 (d-1, d2, d-3) and a generic group-4 (d4, d-5, hash(of null or random)) 

You get your timestamp and keep the whole ER until the last of the documents can be deleted. 

Let's look at the retention: 
Let's say d-1 passes its retention time first: then you delete d-1 normally. You leave the ER intact as it only contains the hash value of d-1 but not the document itself. If for the other documents a ERS is requested you send back the specific ER for this document. 

Personal comment: a few systems I know of actually do not care about the possible semantics of data object groups in ERS, but only look at the individual data objects. They just group the received data objects in binary ascending order and then bundle them together to groups (based on a system wide defined/customized arity of the hashtree). (you give away the advantage of the semantics of the data object group, but can parse and build the ER structures a lot faster as you always know the exact arity/group sizes on every level.)

Hope this explains it a bit more. 

Tobias

Ps.: can you maybe tell me a bit more about your goal: e.g. a verification tool would have to be much more flexible in respect to e.g. what arities and node geometry it accepts of ER hashtrees, compared to if you build a TAS, in which case you could e.g. define a fixed arity for your system generated trees, decide whether to offer users "data object groups" and other parameters of your system as you like. 

Pss.: I'll be at the IETF conf in Vancouver next week and back on Dec-10. So if you like you can give me a short call tomorrow, meet next week at the LTANS meeting, or call me after Dec-10th. 

__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked] 
Internet: http://www.opentext.com/  

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler

> From: Jesus Maria Mendez Perez [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2007 4:55 PM
> To: Tobias Gondrom
> Cc: [email-masked]
> Subject: Re: ERS - using hash tree?
> 
> > Yes, after you completed the hashtree and protect it with a timestamp
> you can not add further nodes. (Comment: Typical ERS-systems build one
> hashtree per day for all documents that were archived during that day and
> sign the hashtree every evening with a timestamp.)
> 
>  		        -----                    ------        	             --
> ----
> ---------------
> > Actually the arity of the hash tree is not restricted by the ERS
> standard and can be decided by the implementer.
> > Several performance and efficiency tests I have seen, have shown that
> typically a tertiary (or binary) hashtree offers the highest efficiency
> and performance when handling larger numbers of documents.
> >
> > That way the reduced ERS for one specific document is a lot smaller as
> it does not need to contain all 2000 nodes of all neighbours, but a lot
> less.
> >
> > > According to ERS if you have 4 data objects the working will be the
> next
> > > one:
> > >
> > >                       ------          ------          ------
> ---
> > > ---
> > >                       | d1 |        | d2 |          | d3 |         |
> d4 |
> > >                       ------          ------          ------
> ---
> > > ---
> > >                          |                |               |
> |
> > >                          |                |               |
> |
> > >                       ------          ------          ------
> ---
> > > ---
> > >                       | h1 |        | h2 |          | h3 |         |
> h4 |
> > >                       ------          ------          ------
> ---
> > > ---
> > >                           |               |              |
> |
> > >                                |       |                      |      |
> > >                                   |                              |
> > >                               --------                        ------
> > >                               | h12 |                      | h34 |
> > >                               --------                        ------
> > >                                   |                              |
> > >                                         |                 |
> > >                                                   |
> > >                                               -----------
> > >                                               | h1234 |
> > >                                               -----------
> > >                                                    |
> > >                                               --------------
> > >                                               | TSh1234 |
> > >                                               --------------
> > >
> > > You can simply add the 4 hashes of the 4 data objects and do the
> finish
> > > hash.
> ---
> > > ---
> ---
> > > ---
> ---
> > > ---
> ---
> > > ---

Content-class: urn:content-classes:message
Subject: RE: ERS - using hash tree?
Date: Wed, 28 Nov 2007 15:54:13 +0100
From: "Tobias Gondrom" <[email-masked]>
To: "Jesus Maria Mendez Perez" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hello Jesus, 

Hm, am not sure I understand your question completely, but let me explain a bit more about ERS. (if you like we can also talk in at the Vancouver meeting next week, or you can give me a short call, as this is maybe a lot easier in person or via phone.) 

However: 
Typically you will build one hashtree per time interval (e.g. lets say per day) for all your documents independent of how long you want to keep the individual documents. 

Lets say you get one day 2 groups of 3 documents each and a set of 5 individual documents (d1...d5). 
Then you would e.g. group them on the lowest level in four groups: group-1 group-2 and a generic group-3 (d-1, d2, d-3) and a generic group-4 (d4, d-5, hash(of null or random)) 

You get your timestamp and keep the whole ER until the last of the documents can be deleted. 

Let's look at the retention: 
Let's say d-1 passes its retention time first: then you delete d-1 normally. You leave the ER intact as it only contains the hash value of d-1 but not the document itself. If for the other documents a ERS is requested you send back the specific ER for this document. 

Personal comment: a few systems I know of actually do not care about the possible semantics of data object groups in ERS, but only look at the individual data objects. They just group the received data objects in binary ascending order and then bundle them together to groups (based on a system wide defined/customized arity of the hashtree). (you give away the advantage of the semantics of the data object group, but can parse and build the ER structures a lot faster as you always know the exact arity/group sizes on every level.)

Hope this explains it a bit more. 

Tobias

Ps.: can you maybe tell me a bit more about your goal: e.g. a verification tool would have to be much more flexible in respect to e.g. what arities and node geometry it accepts of ER hashtrees, compared to if you build a TAS, in which case you could e.g. define a fixed arity for your system generated trees, decide whether to offer users "data object groups" and other parameters of your system as you like. 

Pss.: I'll be at the IETF conf in Vancouver next week and back on Dec-10. So if you like you can give me a short call tomorrow, meet next week at the LTANS meeting, or call me after Dec-10th. 

__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked] 
Internet: http://www.opentext.com/  

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler

> From: Jesus Maria Mendez Perez [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2007 4:55 PM
> To: Tobias Gondrom
> Cc: [email-masked]
> Subject: Re: ERS - using hash tree?
> 
> > Yes, after you completed the hashtree and protect it with a timestamp
> you can not add further nodes. (Comment: Typical ERS-systems build one
> hashtree per day for all documents that were archived during that day and
> sign the hashtree every evening with a timestamp.)
> 
>  		        -----                    ------        	             --
> ----
> ---------------
> > Actually the arity of the hash tree is not restricted by the ERS
> standard and can be decided by the implementer.
> > Several performance and efficiency tests I have seen, have shown that
> typically a tertiary (or binary) hashtree offers the highest efficiency
> and performance when handling larger numbers of documents.
> >
> > That way the reduced ERS for one specific document is a lot smaller as
> it does not need to contain all 2000 nodes of all neighbours, but a lot
> less.
> >
> > But if you like you can also use a tree with arity n, e.g. n00 or
> n=1.000.000.
> >
> > Hope this helps, Tobias
> >
> >
> >
> >
> >
> > > According to ERS if you have 4 data objects the working will be the
> next
> > > one:
> > >
> > >                       ------          ------          ------
> ---
> > > ---
> > >                       | d1 |        | d2 |          | d3 |         |
> d4 |
> > >                       ------          ------          ------
> ---
> > > ---
> > >                          |                |               |
> |
> > >                          |                |               |
> |
> > >                       ------          ------          ------
> ---
> > > ---
> > >                       | h1 |        | h2 |          | h3 |         |
> h4 |
> > >                       ------          ------          ------
> ---
> > > ---
> > >                           |               |              |
> |
> > >                                |       |                      |      |
> > >                                   |                              |
> > >                               --------                        ------
> > >                               | h12 |                      | h34 |
> > >                               --------                        ------
> > >                                   |                              |
> > >                                         |                 |
> > >                                                   |
> > >                                               -----------
> > >                                               | h1234 |
> > >                                               -----------
> > >                                                    |
> > >                                               --------------
> > >                                               | TSh1234 |
> > >                                               --------------
> > >
> > > You can simply add the 4 hashes of the 4 data objects and do the
> finish
> > > hash.
> ---
> > > ---
> ---
> > > ---
> ---
> > > ---
> ---
> > > ---

Date: Tue, 27 Nov 2007 16:54:59 +0100
From: "Jesus Maria Mendez Perez" <[email-masked]>
To: "Tobias Gondrom" <[email-masked]>
Subject: Re: ERS - using hash tree?
Cc: [email-masked]
Sender: [email-masked]

 		        -----                    ------        	             ------
                       | d1 |           	| d2 |         	           |
d3 |
                       ------                    ------        	
      ------
                          |                	   |
    |
                          |                        |
        |
                       ------         	         -------       	
    ------
                       | h1 |        	        | h2 |   	         | h3 |
                       ------                    -----       	
   ------
		          |                         |         	               |

                   ------          ------               |
                  | d1 |        | d2 |         	      |
                   ------          ------          	|
                     |                |                 |
  And, in this side
                     |                |                 |
 the evenging hash tree
                   ------          ------               |
                   | h1 |        | h2 |               |
                   ------          ------               |
                      |               |                 |
                         |       |                      |
                            |                           |
                        --------                        |
                       | h12 |                        |
                        --------                       |
                          |                            |
                          |                            |
		      ------------                     |
		     |  TS12    |                   |
	              ------------

Thanks Tobias

> But if you like you can also use a tree with arity n, e.g. n00 or n=1.000.000.
>
> Hope this helps, Tobias
>
>
>
>
>

Content-class: urn:content-classes:message
Subject: RE: ERS - using hash tree?
Date: Thu, 22 Nov 2007 19:27:01 +0100
From: "Tobias Gondrom" <[email-masked]>
To: "Jesus Maria Mendez Perez" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Hello Jesus, 

1. 

But if you like you can also use a tree with arity n, e.g. n00 or n=1.000.000. 

Hope this helps, Tobias

> According to ERS if you have 4 data objects the working will be the next

Date: Thu, 22 Nov 2007 18:48:21 +0100
From: "Jesus Maria Mendez Perez" <[email-masked]>
To: [email-masked]
Subject: ERS - using hash tree?
Sender: [email-masked]

Hello,

Thanks.

Content-class: urn:content-classes:message
Subject: LTANS meeting in Vancouver - agenda items
Date: Tue, 20 Nov 2007 17:12:05 +0100
Importance: high
From: "Tobias Gondrom" <[email-masked]>
To: <[email-masked]>
Cc: "Carl Wallace" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C82B90.182878E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all, 

Carl and myself have to prepare the agenda for our meeting in Vancouver. 
So if you have any proposals for items, please contact Carl and me until the end of this week (Nov-23). 
Please provide item name, requested time and speaker name. 
If you have a presentation, but can not attend in person, we can also offer to find s.o. to present on your behalf (while you attend via audio and jabber). 

My current draft agenda (still searching for a few presenter names) looks like this:
0. org stuff
1. ers-scvp - final status
2. dssc - status and final feedback, WG LC?
3. ltap - status
4. ersxml - status
5. validate - status and feedback

Hopefully we will be able to finish ers-scvp and dssc in Vancouver and make significant progress on the other drafts. 

Tobias

__________________________________________
Tobias Gondrom
Head of Open Text Security Team
Director, Product Security

Open Text
Technopark 2
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn

Phone: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:[email-masked] 
Internet: http://www.opentext.com/  

Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler

This email is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This email may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above ("Authorized Recipient") for the purpose for which it was sent by OTC. All other rights and licenses to this email are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this email in its entirety without printing, copying, using, and/or re-transmitting this email, either in whole or in part. The transmission of this email by OTC is not to be construed as a waiver by OTC and/or the individual sending this email on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising.

------_=_NextPart_001_01C82B90.182878E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>LTANS meeting in Vancouver - agenda items</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P ALIGN=LEFT><SPAN LANG="de"><FONT SIZE=2 FACE="Arial">Hello all, </FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">Carl and myself</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> have to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">prepare</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> the agenda for our meeting in Vancouver.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> </SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">So if you have any proposal</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">s</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> for items, please contact Carl and me until the end of this week (Nov-</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">23). </FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">Please provide i</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">tem</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> name</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">, requested time and speaker name.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> </SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">If you have a presentation</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">,</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> but can not attend in person, we</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">can</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> also</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">offer to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">find s.o. to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">present on your behalf</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> (while you attend via audio and jabber).</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> </SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">My current draft</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">agenda</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">(still searching for</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> a few</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">presenter names)</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> looks like this</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">:</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">0. org stuff</FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">1.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">ers-scvp</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">&#8211;</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> final status</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">2.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">dssc -</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">status and</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">final</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">feedback</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">, WG LC?</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">3.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> ltap</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">&#8211;</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> status</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">4.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">ersxml</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> - status</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">5.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> validate</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"></FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">&#8211;</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> status and feedback</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">H</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">opefully we will be able to</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">finish</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> <FONT SIZE=2 FACE="Arial">ers-scvp and dssc i</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">n</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> Va</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">n</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">couver</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> and make significant progress on the other</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial"> drafts</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">.</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"> </SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"><FONT SIZE=2 FACE="Arial">Tobias</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="en-gb"></SPAN></P>
<BR>
<BR>

<P ALIGN=LEFT><B><SPAN LANG="de-de"></SPAN></B><A NAME=""><B><SPAN LANG="de-de"><FONT SIZE=2 FACE="Arial">__________________________________________</FONT></SPAN></B></A><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR>
</SPAN><SPAN LANG="de"><B></B></SPAN><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Tobias Gondrom</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR>
</SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Head of Open Text Security Team<BR>
Director, Product Security<BR>
</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR>
</SPAN><SPAN LANG="de"><B></B></SPAN><SPAN LANG="de"><B></B></SPAN><B><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Open Text</FONT></SPAN></B><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR>
</SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><FONT COLOR="#000000">Technopark 2<BR>
Werner-von-Siemens-Ring 20<BR>
D-85630 Grasbrunn</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><BR>
</SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Phone: +49 (0) 89 4629-1816<BR>
Mobile: +49 (0) 173 5942987<BR>
Telefax: +49 (0) 89 4629-33-1816<BR>
eMail:</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"> <FONT SIZE=2 FACE="Arial"><A HREF="mailto:[email-masked]">mailto:[email-masked]</A><BR>
</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"><FONT COLOR="#000000" SIZE=2 FACE="Arial">Internet:</FONT></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de"></SPAN><SPAN LANG="de-de"> <FONT SIZE=2 FACE="Arial"><A HREF="http://www.opentext.com/">http://www.opentext.com/</A>&nbsp; </FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="de-de"><FONT SIZE=1 FACE="Arial">Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH, Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89 4629 0 | Fax: +49 (0) 89 4629 1199 | Register Court / Registergericht: München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John Shackleton, Walter Köhler</FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="de-de"><FONT SIZE=1 FACE="Arial">This email is protected by domestic and international copyright laws and treaties and is the property of Open Text Corporation, it may contain confidential and/or trade secret information of the Open Text Corporation and/or its subsidiaries (OTC), and may be subject to legal privilege in favor of OTC. This email may only be lawfully received, accessed, displayed on a computer screen, printed, copied, and/or used by the specific addressee(s) named above (&quot;Authorized Recipient&quot;) for the purpose for which it was sent by OTC. All other rights and licenses to this email are fully reserved to OTC. If you are not an Authorized Recipient, you are required to immediately delete this email in its entirety without printing, copying, using, and/or re-transmitting this email, either in whole or in part. The transmission of this email by OTC is not to be construed as a waiver by OTC and/or the individual sending this email on behalf of OTC of any of their respective rights or privileges at law or otherwise, howsoever arising.</FONT></SPAN></P>

<P ALIGN=LEFT><SPAN LANG="en-gb"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C82B90.182878E0--

To: [email-masked]
From: [email-masked]
Date: Fri, 16 Nov 2007 13:30:02 -0500
Cc: [email-masked]
Subject: I-D Action:draft-ietf-ltans-ers-scvp-05.txt 
Reply-To: [email-masked]
Sender: [email-masked]

--NextPart

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           : Using SCVP to Convey Long-term Evidence Records
	Author(s)       : C. Wallace
	Filename        : draft-ietf-ltans-ers-scvp-05.txt
	Pages           : 17
	Date            : 2007-11-16

The Simple Certificate Validation Protocol (SCVP) defines an
extensible means of delegating the development and validation of
certification paths to a server.  It can be used to support the
development and validation of certification paths well after the
expiration of the certificates in the path by specifying a time of
interest in the past.  The Evidence Record Syntax (ERS) defines
structures, called evidence records, to support non-repudiation of
existence of data.  Evidence records can be used to preserve
materials that comprise a certification path such that trust in the
certificates can be established after the expiration of the
certificates in the path and after the cryptographic algorithms used
to sign the certificates in the path are no longer secure.  This
document describes an application of SCVP to serve this purpose using
the WantBack feature of SCVP to convey evidence records.

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-ltans-ers-scvp-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ltans-ers-scvp-05.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ltans-ers-scvp-05.txt

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

Content-Type: text/plain
Content-ID: <2007-11-16132804.I-D\@ietf.org>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ltans-ers-scvp-05.txt 
Date: Fri, 16 Nov 2007 13:30:02 -0500
Sender: [email-masked]

--NextPart

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           : Using SCVP to Convey Long-term Evidence Records
	Author(s)       : C. Wallace
	Filename        : draft-ietf-ltans-ers-scvp-05.txt
	Pages           : 17
	Date            : 2007-11-16

The Simple Certificate Validation Protocol (SCVP) defines an
extensible means of delegating the development and validation of
certification paths to a server.  It can be used to support the
development and validation of certification paths well after the
expiration of the certificates in the path by specifying a time of
interest in the past.  The Evidence Record Syntax (ERS) defines
structures, called evidence records, to support non-repudiation of
existence of data.  Evidence records can be used to preserve
materials that comprise a certification path such that trust in the
certificates can be established after the expiration of the
certificates in the path and after the cryptographic algorithms used
to sign the certificates in the path are no longer secure.  This
document describes an application of SCVP to serve this purpose using
the WantBack feature of SCVP to convey evidence records.

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-ltans-ers-scvp-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ltans-ers-scvp-05.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ltans-ers-scvp-05.txt

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

Content-Type: text/plain
Content-ID:     <2007-11-16132804.I-D\@ietf.org>

--OtherAccess--

--NextPart--

From: Carl Wallace <[email-masked]>
To: [email-masked], Tobias Gondrom <[email-masked]>
Subject: RE: draft-ietf-ltans-ers-scvp-04 - minor editorial suggestions
Date: Fri, 16 Nov 2007 13:28:13 -0500
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C8287E.727CFCC3
Content-Type: text/plain

Thanks for the thorough review Tobias.  I made almost all of the changes you
recommended.  Responses are in line below.  I posted a new draft immediately
because the deadline is so soon.  I can post a follow-up after the IETF
meeting if there're any additional changes required.  

  _____  

From: Tobias Gondrom [mailto:[email-masked]] 
Sent: Wednesday, November 14, 2007 1:55 PM
To: Carl Wallace
Cc: [email-masked]
Subject: draft-ietf-ltans-ers-scvp-04 - minor editorial suggestions

Hello Carl, 

thank you very much for the update.

To prepare for the next finishing steps of ers-scvp (to go to IETF LC), I
also did a last review again and would propose just a few small editorial
changes. 

Don't be shocked by the number of 18 items, it's all just very minor wording
things and three questions rather for my own personal understanding. 

I like the draft very much and think it will be ready for IETF LC. Please
consider my comments below only as suggestions. 

1. in the Abstract: 

Old: 

"Evidence records can be used to preserve materials that comprise a
certification path such that trust can be established in the certificates
after the expiration of the certificates in the path and after the
cryptographic algorithms used to sign the certificates in the path are no
longer secure."

Should this be changed to: 

"Evidence records can be used to preserve materials that comprise a
certification path, such that trust in the certificates can be established
after the expiration of the certificates in the path and after the
cryptographic algorithms used to sign the certificates in the path are no
longer secure." 

[CRW] Fixed 

2. Section 1 Introduction: first paragraph

Should it be?

s/When verifying digital signatures many/To verify digital signatures many

[CRW] Fixed 

3. Section 1 Introduction: second paragraph

s/server for the purposes of preserving evidence records/server for the
purpose of preserving evidence records

[CRW] Fixed 

4. section 2: list after second paragraph 

The list covers two items where I wonder if they should not be slightly
reworded?

Old: 

"- certification paths containing end entity certificates through trust
anchors

- certification paths containing intermediate certificates through trust
anchors"

New: 

"- certification paths containing end entity certificates up to their trust
anchors

- certification paths containing intermediate certificates up to their trust
anchors"

[CRW] Changed using slightly different wording.  "containing an end entity
certificate up to a trust anchor" and similar for intermediate bullet.

5. section 2: list at end of section: 

s/- SCVP server returns a response with status as of time of interest and
including requested evidence records/- SCVP server returns a response with
status as of time of interest and includes requested evidence records 

[CRW] Fixed 

6. section 3: second paragraph: 

s/CA who issued the end entity certificate through a trust anchor/CA who
issued the end entity certificate up to its trust anchor/ 

[CRW] I didn't change this one.   Paths may exist from the end entity
certificate to more than one trust anchor.  

7. section 4: first paragraph: 

This is just a proposal/question whether it might be better??? But maybe a
"MUST" is too strong here?

s/For id-swb-ers-pkc-cert, the evidence record is calculated over the value
of the cert field in the CertReply object./For id-swb-ers-pkc-cert, the
evidence record MUST be calculated over the value of the cert field in the
CertReply object.

And maybe also a "MUST" instead of the "is" in the sentence following this
one?

[CRW]  I agree.  Changed to MUST.   Changed both of the instances you cited
plus one more in the best-cert-path section. 

8. section 4: second paragraph:  

s/If the server can not return an EvidenceRecord for the requested
information/If the server can not return an EvidenceRecord for the requested
information item

[CRW] Fixed 

9.section 4: second paragraph: 

And this is only a personal question just for my understanding: 

Is the "empty field" sufficient compared to a possible field value e.g. "Not
available". Could there be cases where an "empty field" can result and not
mean the value can not be provided, e.g. value is unclear or undefined? But
probably this is a quite theoretical question? 

[CRW] I think the current text is sufficient.  The reply will either have an
evidence record or it won't.  Since the field is a non-optional OCTET
STRING, empty is used when no evidence record is available. 

10. section 5: equal in first paragraph of 5.1, 5.2, 5.3 and 5.4

These paragraphs all state analogue to 

"Requests containing id-swb-ers-best-cert-path as a WantBack MUST also
contain id-swb-best-cert-path."

Question: What happens if not both are in the request but only
"id-swb-ers-best-cert-path"? 

[CRW] I added the following to the beginning of section 5:

Each wantBack for an evidence record requires a corresponding wantBack for
the object covered by the evidence record to be present in the request. Upon
receipt of a request missing the corresponding wantBack for the object
covered by a requested evidence record, the server MUST indicate
wantBackUnsatisfied in the ReplyStatus. Clients MAY ignore evidence record
wantBacks when the wantBack for the corresponding object is not present.

11. section 5.4: title:

s/Evidence record for a revocation information/Evidence record for
revocation information

[CRW] Fixed 

12. section 5.4: second paragraph:

And again a personal question for my understanding. (Probably I just miss
the point?)

Why can the generation of cumulative CRLs simplify the maintenance of
evidence records? 

[CRW] It helps by avoiding the need to hang on to all CRLs.  An archive
could simply maintain the final CRL generated by a CA provided it contained
expired certs.   

13. section 5.5: first paragraph: 

s/all information returned via in the replyWantBacks field/all information
returned via the replyWantBacks field

 [CRW] Fixed 

14. section 5.5: last paragraph: 

s/indicates the type of replyWantBack is covered by the associated
EvidenceRecord./indicates the type of replyWantBack covered by the
associated EvidenceRecord.

 [CRW] Fixed 

15. section 5.5: last paragraph: 

s/does not have an EvidenceRecord for particular replyWantBack object/does
not have an EvidenceRecord for a particular replyWantBack object

 [CRW] Fixed  

16. section 5.6: first paragraph: 

I am not sure I understand the first two sentences: 

"The id-swb-partial-cert-path is an alternative to id-swb-best-cert-path.
This is the only OID defined in this document for which an EvidenceRecord is
not returned in the response."

This sounds to me like a contradiction to section 5.2 which I understood
that an Evidence record to be returned in the response??? 

[CRW] Section 5.2 discusses the id-swb-ers-partial-cert-path wantBack, which
corresponds to the  id-swb-partial-cert-path wantBack.
id-swb-partial-cert-path returns a CertBundle and
id-swb-ers-partial-cert-path returns an EvidenceRecord.  

17. section 5.6: second paragraph: 

Is this a spelling mistake?

s/SCVP clients can include id-swb-pkc-partial-cert-path/SCVP clients can
include id-swb-partial-cert-path

[CRW] Fixed. 

18. section 6: second paragraph: 

Should this be a capital "SHOULD" in the sense of RFC2119?

s/Relying parties should ignore trust anchors contained in unsigned SCVP
responses./Relying parties SHOULD ignore trust anchors contained in unsigned
SCVP responses.

[CRW] Fixed. 

Thanks, Tobias

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Carl Wallace
Sent: Thursday, November 08, 2007 7:01 PM
To: [email-masked]
Subject: RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 

The primary change in this version changes the handling of revocation
information by passing an evidence record for each revocation information
object instead of one covering the set.  The original intent was for the ER
wantBack to cover any corresponding wantBack but that approach wasn't viable
due to the way the certificate value is returned.  Given that this property
has been lost, it's easier in practice to maintain ERs for each CRL
independently vs. as a set for inclusion in a wantBack.

> From: IETF I-D Submission Tool [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, November 08, 2007 12:52 PM 
> To: [email-masked] 
> Cc: [email-masked] 
> Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 
> 
> 
> A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has 
> been successfuly submitted by Carl Wallace and posted to the 
> IETF repository. 
> 
> Filename:      draft-ietf-ltans-ers-scvp 
> Revision:      04 
> Title:                 Using SCVP to Convey Long-term Evidence Records 
> Creation_date:         2007-11-08 
> WG ID:                 ltans 
> Number_of_pages: 18 
> 
> Abstract: 
> The Simple Certificate Validation Protocol (SCVP) defines an 
> extensible means of delegating the development and validation 
> of certification paths to a server.  It can be used to 
> support the development and validation of certification paths 
> well after the expiration of the certificates in the path by 
> specifying a time of interest in the past.  The Evidence 
> Record Syntax (ERS) defines structures, called evidence 
> records, to support non-repudiation of existence of data.  
> Evidence records can be used to preserve materials that 
> comprise a certification path such that trust can be 
> established in the certificates after the expiration of the 
> certificates in the path and after the cryptographic 
> algorithms used to sign the certificates in the path are no 
> longer secure.  This document describes an application of 
> SCVP to serve this purpose using the WantBack feature of SCVP 
> to convey evidence records. 
>                                                               
>                     
> 
> 
> The IETF Secretariat. 
> 
> 

------_=_NextPart_001_01C8287E.727CFCC3
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = 
"urn:schemas-microsoft-com:vml" xmlns:o = 
"urn:schemas-microsoft-com:office:office" xmlns:w = 
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>RE: New Version Notification for draft-ietf-ltans-ers-scvp-04</TITLE>

<META content="MSHTML 6.00.2900.3199" name=GENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 70.85pt 70.85pt 2.0cm 70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: "Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=DE vLink=blue link=blue>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN 
class=346395911-16112007>Thanks for the thorough review Tobias.&nbsp; I made 
almost all of the changes you recommended.&nbsp; Responses are in line 
below.&nbsp; I posted a new draft immediately because the deadline is so 
soon.&nbsp; I can post a follow-up after the IETF meeting if there're any 
additional changes required.&nbsp; </SPAN></FONT></DIV><BR>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> Tobias Gondrom 
  [mailto:[email-masked]] <BR><B>Sent:</B> Wednesday, November 14, 2007 
  1:55 PM<BR><B>To:</B> Carl Wallace<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> draft-ietf-ltans-ers-scvp-04 - minor 
  editorial suggestions<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=Section1>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hello Carl, 
  <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">thank you very much 
  for the update.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">To prepare for the 
  next finishing steps of ers-scvp (to go to IETF LC), I also did a last review 
  again and would propose just a few small editorial changes. 
  <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Don&#8217;t be shocked by 
  the number of 18 items, it&#8217;s all just very minor wording things and three 
  questions rather for my own personal understanding. 
  <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I like the draft very 
  much and think it will be ready for IETF LC. Please consider my comments below 
  only as suggestions. <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">1. in the Abstract: 
  <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Old: 
  <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&#8220;Evidence records can 
  be used to preserve materials that comprise a certification path such that 
  trust can be established in the certificates after the expiration of the 
  certificates in the path and after the cryptographic algorithms used to sign 
  the certificates in the path are no longer 
  secure.&#8221;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Should this be 
  changed to: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&#8220;Evidence records can 
  be used to preserve materials that comprise a certification path, such that 
  trust in the certificates can be established after the expiration of the 
  certificates in the path and after the cryptographic algorithms used to sign 
  the certificates in the path are no longer secure.&#8221;<FONT color=#0000ff><SPAN 
  class=346395911-16112007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN 
  class=346395911-16112007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] 
  Fixed&nbsp;</SPAN><o:p></o:p></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">2. Section 1 
  Introduction: first paragraph<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Should it 
  be?<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/When verifying 
  digital signatures many/To verify digital signatures 
  many<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P><FONT 
  face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] 
  Fixed&nbsp;</SPAN><o:p></o:p></FONT></SPAN></FONT></P>
  <P class=MsoNormal>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">3. Section 1 
  Introduction: second paragraph<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/server for the 
  purposes of preserving evidence records/server for the purpose of preserving 
  evidence records<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P><FONT 
  face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] 
  Fixed&nbsp;</SPAN><o:p></o:p></FONT></SPAN></FONT></P></o:p></SPAN></FONT>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">4. section 2: list 
  after second paragraph <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">The list covers two 
  items where I wonder if they should not be slightly 
  reworded?<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Old: 
  <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&#8220;- certification 
  paths containing end entity certificates through trust 
  anchors<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">- certification paths 
  containing intermediate certificates through trust 
  anchors&#8221;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">New: 
  <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&#8220;- certification 
  paths containing end entity certificates up to their trust 
  anchors<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">- certification paths 
  containing intermediate certificates up to their trust 
  anchors&#8221;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P><FONT 
  face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] Changed using slightly 
  different wording.&nbsp; "containing an end entity certificate up to a trust 
  anchor" and similar for intermediate bullet.</SPAN></FONT></SPAN></FONT></P>
  <P class=MsoNormal>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">5. section 2: list at 
  end of section: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/- SCVP server 
  returns a response with status as of time of interest and including requested 
  evidence records/- SCVP server returns a response with status as of time of 
  interest and includes requested evidence records<FONT color=#0000ff><SPAN 
  class=346395911-16112007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>&nbsp;</P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] 
  Fixed&nbsp;</SPAN><o:p></o:p></FONT></SPAN></FONT></P></SPAN><o:p></o:p></FONT></SPAN></FONT>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">6. section 3: second 
  paragraph: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/CA who issued the 
  end entity certificate through a trust anchor/CA who issued the end entity 
  certificate up to its trust anchor/<FONT color=#0000ff><SPAN 
  class=346395911-16112007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN 
  class=346395911-16112007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] I didn't change this 
  one.&nbsp;&nbsp;&nbsp;Paths may exist from the end entity certificate to more 
  than one trust anchor.&nbsp; </SPAN></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">7. section 4: first 
  paragraph: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This is just a 
  proposal/question whether it might be better??? But maybe a &#8220;MUST&#8221; is too 
  strong here?<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/For 
  id-swb-ers-pkc-cert, the evidence record is calculated over the value of the 
  cert field in the CertReply object./For id-swb-ers-pkc-cert, the evidence 
  record MUST be calculated over the value of the cert field in the CertReply 
  object.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">And maybe also a 
  &#8220;MUST&#8221; instead of the &#8220;is&#8221; in the sentence following this 
  one?<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN 
  class=346395911-16112007><FONT color=#0000ff>[CRW]&nbsp; I agree.&nbsp; 
  Changed to MUST.</FONT></SPAN>&nbsp;<SPAN class=346395911-16112007><FONT 
  color=#0000ff>&nbsp; Changed both of the instances you cited plus one more in 
  the best-cert-path section.&nbsp;</FONT></SPAN></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">8. section 4: second 
  paragraph: &nbsp;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/If the server can 
  not return an EvidenceRecord for the requested information/If the server can 
  not return an EvidenceRecord for the requested information 
  item<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] 
  Fixed&nbsp;</SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">9.section 4: second 
  paragraph: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">And this is only a 
  personal question just for my understanding: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Is the &#8220;empty field&#8221; 
  sufficient compared to a possible field value e.g. &#8220;Not available&#8221;. Could 
  there be cases where an &#8220;empty field&#8221; can result and not mean the value can 
  not be provided, e.g. value is unclear or undefined? But probably this is a 
  quite theoretical question?<FONT color=#0000ff><SPAN 
  class=346395911-16112007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN 
  class=346395911-16112007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW]&nbsp;I think the current 
  text is sufficient.&nbsp; The reply will either have an evidence record or it 
  won't.&nbsp; Since the field is a non-optional OCTET STRING, empty is 
  used&nbsp;when no evidence record is 
  available.&nbsp;</SPAN><o:p></o:p></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">10. section 5: equal 
  in first paragraph of 5.1, 5.2, 5.3 and 5.4<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">These paragraphs all 
  state analogue to <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&#8220;Requests containing 
  id-swb-ers-best-cert-path as a WantBack MUST also contain 
  id-swb-best-cert-path.&#8221;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Question: What 
  happens if not both are in the request but only 
  &#8220;id-swb-ers-best-cert-path&#8221;?<FONT color=#0000ff><SPAN 
  class=346395911-16112007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN 
  class=346395911-16112007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW]&nbsp;I added the following 
  to the beginning of section 5:</SPAN></FONT></SPAN></FONT></P><FONT 
  color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT><SPAN 
  class=346395911-16112007><FONT color=#0000ff size=2><FONT size=2>
  <P>Each wantBack for an evidence record requires a corresponding wantBack for 
  the object covered by the evidence record to be present in the request. Upon 
  receipt of a request missing the corresponding wantBack for the object covered 
  by a requested evidence record, the server MUST indicate wantBackUnsatisfied 
  in the ReplyStatus. Clients MAY ignore evidence record wantBacks when the 
  wantBack for the corresponding object is not present.</P></FONT><SPAN 
  class=346395911-16112007><FONT face=Arial size=2><FONT 
  size=2></FONT></FONT></SPAN></FONT></SPAN></FONT></SPAN></FONT>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">11. section 5.4: 
  title:<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/Evidence record for 
  a revocation information/Evidence record for revocation 
  information<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] 
  Fixed&nbsp;</SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">12. section 5.4: 
  second paragraph:<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">And again a personal 
  question for my understanding. (Probably I just miss the 
  point?)<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Why can the 
  generation of cumulative CRLs simplify the maintenance of evidence 
  records?<FONT color=#0000ff><SPAN 
  class=346395911-16112007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN 
  class=346395911-16112007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] It helps by avoiding the 
  need to hang on to all CRLs.&nbsp; An archive could simply maintain 
  the&nbsp;final CRL generated by a CA provided it contained&nbsp;expired 
  certs.&nbsp;&nbsp;&nbsp;</SPAN><o:p></o:p></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">13. section 5.5: 
  first paragraph: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/all information 
  returned via in the replyWantBacks field/all information returned via the 
  replyWantBacks field<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;<SPAN 
  lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN 
  lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN 
  lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] 
  Fixed&nbsp;</SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></o:p></SPAN></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">14. section 5.5: last 
  paragraph: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/indicates the type 
  of replyWantBack is covered by the associated EvidenceRecord./indicates the 
  type of replyWantBack covered by the associated 
  EvidenceRecord.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;<SPAN 
  lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN 
  lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN 
  lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] 
  Fixed&nbsp;</SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></o:p></SPAN></o:p></SPAN></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">15. section 5.5: last 
  paragraph: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/does not have an 
  EvidenceRecord for particular replyWantBack object/does not have an 
  EvidenceRecord for a particular replyWantBack 
  object<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;<SPAN 
  lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN 
  lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN 
  lang=EN-GB style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] 
  Fixed&nbsp;</SPAN><o:p></o:p></FONT></SPAN></o:p></SPAN></o:p></SPAN></o:p></SPAN>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">16. section 5.6: 
  first paragraph: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I am not sure I 
  understand the first two sentences: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&#8220;The 
  id-swb-partial-cert-path is an alternative to id-swb-best-cert-path. This is 
  the only OID defined in this document for which an EvidenceRecord is not 
  returned in the response.&#8221;<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">This sounds to me 
  like a contradiction to section 5.2 which I understood that an Evidence record 
  to be returned in the response???<FONT color=#0000ff><SPAN 
  class=346395911-16112007>&nbsp;</SPAN></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN 
  class=346395911-16112007></SPAN></FONT></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT 
  color=#0000ff><SPAN class=346395911-16112007>[CRW] Section 5.2 discusses the 
  id-swb-ers-partial-cert-path wantBack, which corresponds to the&nbsp;<FONT 
  color=#000080> id-swb-partial-cert-path wantBack.&nbsp;&nbsp; 
  id-swb-partial-cert-path returns a CertBundle and </FONT><FONT 
  color=#0000ff>id-swb-ers-partial-cert-path returns an EvidenceRecord.&nbsp; 
  </FONT></P>
  <P class=MsoNormal>&nbsp;</SPAN><o:p></o:p></FONT></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">17. section 5.6: 
  second paragraph: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Is this a spelling 
  mistake?<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/SCVP clients can 
  include id-swb-pkc-partial-cert-path/SCVP clients can include 
  id-swb-partial-cert-path<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT color=navy><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN 
  class=346395911-16112007><FONT color=#0000ff>[CRW] 
  Fixed.</FONT></SPAN>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p></o:p></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">18. section 6: second 
  paragraph: <o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Should this be a 
  capital &#8220;SHOULD&#8221; in the sense of RFC2119?<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">s/Relying parties 
  should ignore trust anchors contained in unsigned SCVP responses./Relying 
  parties SHOULD ignore trust anchors contained in unsigned SCVP 
  responses.<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=#0000ff size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p><SPAN 
  class=346395911-16112007><FONT 
  color=#0000ff>[CRW]&nbsp;Fixed.</FONT></SPAN>&nbsp;</o:p></SPAN></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thanks, 
  Tobias<o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=MsoNormal><FONT face=Arial color=navy size=2><SPAN lang=EN-GB 
  style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV 
  style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0cm; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0cm; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0cm; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center><FONT 
  face="Times New Roman" size=3><SPAN lang=EN-US style="FONT-SIZE: 12pt">
  <HR tabIndex=-1 align=center width="100%" SIZE=2>
  </SPAN></FONT></DIV>
  <P class=MsoNormal><B><FONT face=Tahoma size=2><SPAN lang=EN-US 
  style="FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">From:</SPAN></FONT></B><FONT 
  face=Tahoma size=2><SPAN lang=EN-US 
  style="FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> [email-masked] 
  [mailto:[email-masked]] <B><SPAN style="FONT-WEIGHT: bold">On 
  Behalf Of </SPAN></B>Carl Wallace<BR><B><SPAN 
  style="FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, November 08, 2007 7:01 
  PM<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> 
  [email-masked]<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> 
  RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 
  </SPAN></FONT><SPAN lang=EN-US><o:p></o:p></SPAN></P></DIV>
  <P class=MsoNormal><FONT face="Times New Roman" size=3><SPAN 
  style="FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">The 
  primary change in this version changes the handling of revocation information 
  by passing an evidence record for each revocation information object instead 
  of one covering the set.&nbsp; The original intent was for the ER wantBack to 
  cover any corresponding wantBack but that approach wasn't viable due to the 
  way the certificate value is returned.&nbsp; Given that this property has been 
  lost, it's easier in practice to maintain ERs for each CRL independently vs. 
  as a set for inclusion in a wantBack.</SPAN></FONT><o:p></o:p></P>
  <P><FONT face="Times New Roman" size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  -----Original Message-----</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; From: IETF I-D Submission Tool [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; Sent: 
  Thursday, November 08, 2007 12:52 PM</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; To: [email-masked]</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; Cc: [email-masked]</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; Subject: New Version 
  Notification for draft-ietf-ltans-ers-scvp-04 </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; A new version of I-D, 
  draft-ietf-ltans-ers-scvp-04.txt has </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; been successfuly submitted by Carl Wallace and 
  posted to the </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; IETF repository.</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; Filename:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  draft-ietf-ltans-ers-scvp</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  04</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Using SCVP to Convey 
  Long-term Evidence Records</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; 
  Creation_date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  2007-11-08</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  WG ID:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ltans</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; Number_of_pages: 18</SPAN></FONT> 
  <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; Abstract:</SPAN></FONT> <BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; The Simple Certificate Validation 
  Protocol (SCVP) defines an </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; extensible means of delegating the development 
  and validation </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; of certification paths to a server.&nbsp; It can 
  be used to </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  support the development and validation of certification paths 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; well after 
  the expiration of the certificates in the path by </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; specifying a time of interest in the 
  past.&nbsp; The Evidence </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; Record Syntax (ERS) defines structures, called 
  evidence </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  records, to support non-repudiation of existence of data.&nbsp; 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; Evidence 
  records can be used to preserve materials that </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; comprise a certification path such 
  that trust can be </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; established in the certificates after the 
  expiration of the </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; certificates in the path and after the 
  cryptographic </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt; algorithms used to sign the certificates in the 
  path are no </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  longer secure.&nbsp; This document describes an application of 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; SCVP to 
  serve this purpose using the WantBack feature of SCVP </SPAN></FONT><BR><FONT 
  size=2><SPAN style="FONT-SIZE: 10pt">&gt; to convey evidence 
  records.</SPAN></FONT> <BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN></FONT><BR><FONT size=2><SPAN 
  style="FONT-SIZE: 10pt">&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; The IETF 
  Secretariat.</SPAN></FONT> <BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  </SPAN></FONT><BR><FONT size=2><SPAN style="FONT-SIZE: 10pt">&gt; 
  </SPAN></FONT><o:p></o:p></P></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C8287E.727CFCC3--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ltans-validate-02.txt 
Date: Fri, 16 Nov 2007 11:30:01 -0500
Sender: [email-masked]

--NextPart

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           : Validation and long term verification data for Evidence Records and signed documents
	Author(s)       : T. Gondrom
	Filename        : draft-ietf-ltans-validate-02.txt
	Pages           : 11
	Date            : 2007-11-16

Digitally signed documents and data in a LTANS service receive the
signature renwal procedures and non-repudiation services.  As
documents can be stored for very long (theoretically inifinite)
times, it is very important to understand which data is and will be
necessary for the verification of the contained digital signatures
and the applied timestamps and the evidence records.  This document
shall describe various pieces of information which SHOULD and MUST be
provided to effectively verify evidence records and their protected
data and signatures.

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-validate-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-ltans-validate-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ltans-validate-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ltans-validate-02.txt

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

Content-Type: text/plain
Content-ID:     <2007-11-16112204.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: draft-ietf-ltans-ers-scvp-04 - minor editorial suggestions
Date: Wed, 14 Nov 2007 19:55:04 +0100
From: "Tobias Gondrom" <[email-masked]>
To: "Carl Wallace" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C826EF.DE95B6B0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hello Carl, 

thank you very much for the update.

To prepare for the next finishing steps of ers-scvp (to go to IETF LC),
I also did a last review again and would propose just a few small
editorial changes. 

Don't be shocked by the number of 18 items, it's all just very minor
wording things and three questions rather for my own personal
understanding. 

I like the draft very much and think it will be ready for IETF LC.
Please consider my comments below only as suggestions. 

1. in the Abstract: 

Old: 

"Evidence records can be used to preserve materials that comprise a
certification path such that trust can be established in the
certificates after the expiration of the certificates in the path and
after the cryptographic algorithms used to sign the certificates in the
path are no longer secure."

Should this be changed to: 

"Evidence records can be used to preserve materials that comprise a
certification path, such that trust in the certificates can be
established after the expiration of the certificates in the path and
after the cryptographic algorithms used to sign the certificates in the
path are no longer secure."

2. Section 1 Introduction: first paragraph

Should it be?

s/When verifying digital signatures many/To verify digital signatures
many

3. Section 1 Introduction: second paragraph

s/server for the purposes of preserving evidence records/server for the
purpose of preserving evidence records

4. section 2: list after second paragraph 

The list covers two items where I wonder if they should not be slightly
reworded?

Old: 

"- certification paths containing end entity certificates through trust
anchors

- certification paths containing intermediate certificates through trust
anchors"

New: 

"- certification paths containing end entity certificates up to their
trust anchors

- certification paths containing intermediate certificates up to their
trust anchors"

5. section 2: list at end of section: 

s/- SCVP server returns a response with status as of time of interest
and including requested evidence records/- SCVP server returns a
response with status as of time of interest and includes requested
evidence records

6. section 3: second paragraph: 

s/CA who issued the end entity certificate through a trust anchor/CA who
issued the end entity certificate up to its trust anchor/

7. section 4: first paragraph: 

This is just a proposal/question whether it might be better??? But maybe
a "MUST" is too strong here?

s/For id-swb-ers-pkc-cert, the evidence record is calculated over the
value of the cert field in the CertReply object./For
id-swb-ers-pkc-cert, the evidence record MUST be calculated over the
value of the cert field in the CertReply object.

And maybe also a "MUST" instead of the "is" in the sentence following
this one?

8. section 4: second paragraph:  

s/If the server can not return an EvidenceRecord for the requested
information/If the server can not return an EvidenceRecord for the
requested information item

9.section 4: second paragraph: 

And this is only a personal question just for my understanding: 

Is the "empty field" sufficient compared to a possible field value e.g.
"Not available". Could there be cases where an "empty field" can result
and not mean the value can not be provided, e.g. value is unclear or
undefined? But probably this is a quite theoretical question?

10. section 5: equal in first paragraph of 5.1, 5.2, 5.3 and 5.4

These paragraphs all state analogue to 

"Requests containing id-swb-ers-best-cert-path as a WantBack MUST also
contain id-swb-best-cert-path."

Question: What happens if not both are in the request but only
"id-swb-ers-best-cert-path"?

11. section 5.4: title:

s/Evidence record for a revocation information/Evidence record for
revocation information

12. section 5.4: second paragraph:

And again a personal question for my understanding. (Probably I just
miss the point?)

Why can the generation of cumulative CRLs simplify the maintenance of
evidence records?

13. section 5.5: first paragraph: 

s/all information returned via in the replyWantBacks field/all
information returned via the replyWantBacks field

14. section 5.5: last paragraph: 

s/indicates the type of replyWantBack is covered by the associated
EvidenceRecord./indicates the type of replyWantBack covered by the
associated EvidenceRecord.

15. section 5.5: last paragraph: 

s/does not have an EvidenceRecord for particular replyWantBack
object/does not have an EvidenceRecord for a particular replyWantBack
object

16. section 5.6: first paragraph: 

I am not sure I understand the first two sentences: 

"The id-swb-partial-cert-path is an alternative to
id-swb-best-cert-path. This is the only OID defined in this document for
which an EvidenceRecord is not returned in the response."

This sounds to me like a contradiction to section 5.2 which I understood
that an Evidence record to be returned in the response???

17. section 5.6: second paragraph: 

Is this a spelling mistake?

s/SCVP clients can include id-swb-pkc-partial-cert-path/SCVP clients can
include id-swb-partial-cert-path

18. section 6: second paragraph: 

Should this be a capital "SHOULD" in the sense of RFC2119?

s/Relying parties should ignore trust anchors contained in unsigned SCVP
responses./Relying parties SHOULD ignore trust anchors contained in
unsigned SCVP responses.

Thanks, Tobias

________________________________

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Thursday, November 08, 2007 7:01 PM
To: [email-masked]
Subject: RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 

The primary change in this version changes the handling of revocation
information by passing an evidence record for each revocation
information object instead of one covering the set.  The original intent
was for the ER wantBack to cover any corresponding wantBack but that
approach wasn't viable due to the way the certificate value is returned.
Given that this property has been lost, it's easier in practice to
maintain ERs for each CRL independently vs. as a set for inclusion in a
wantBack.

> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Thursday, November 08, 2007 12:52 PM 
> To: [email-masked] 
> Cc: [email-masked] 
> Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 
> 
> 
> A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has 
> been successfuly submitted by Carl Wallace and posted to the 
> IETF repository. 
> 
> Filename:      draft-ietf-ltans-ers-scvp 
> Revision:      04 
> Title:                 Using SCVP to Convey Long-term Evidence Records

> Creation_date:         2007-11-08 
> WG ID:                 ltans 
> Number_of_pages: 18 
> 
> Abstract: 
> The Simple Certificate Validation Protocol (SCVP) defines an 
> extensible means of delegating the development and validation 
> of certification paths to a server.  It can be used to 
> support the development and validation of certification paths 
> well after the expiration of the certificates in the path by 
> specifying a time of interest in the past.  The Evidence 
> Record Syntax (ERS) defines structures, called evidence 
> records, to support non-repudiation of existence of data.  
> Evidence records can be used to preserve materials that 
> comprise a certification path such that trust can be 
> established in the certificates after the expiration of the 
> certificates in the path and after the cryptographic 
> algorithms used to sign the certificates in the path are no 
> longer secure.  This document describes an application of 
> SCVP to serve this purpose using the WantBack feature of SCVP 
> to convey evidence records. 
>                                                               
>                     
> 
> 
> The IETF Secretariat. 
> 
> 

------_=_NextPart_001_01C826EF.DE95B6B0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 </title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=DE link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hello Carl, <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>thank you very much for
the update.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>To prepare for the next
finishing steps of ers-scvp (to go to IETF LC), I also did a last review again and
would propose just a few small editorial changes. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Don&#8217;t be shocked by
the number of 18 items, it&#8217;s all just very minor wording things and three
questions rather for my own personal understanding. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>I like the draft very
much and think it will be ready for IETF LC. Please consider my comments below only
as suggestions. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>1. in the Abstract: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Old: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>&#8220;Evidence records
can be used to preserve materials that comprise a certification path such that
trust can be established in the certificates after the expiration of the certificates
in the path and after the cryptographic algorithms used to sign the
certificates in the path are no longer secure.&#8221;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Should this be changed to:
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>&#8220;Evidence records
can be used to preserve materials that comprise a certification path, such that
trust in the certificates can be established after the expiration of the certificates
in the path and after the cryptographic algorithms used to sign the
certificates in the path are no longer secure.&#8221;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>2. Section 1
Introduction: first paragraph<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Should it be?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/When verifying digital
signatures many/To verify digital signatures many<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>3. Section 1
Introduction: second paragraph<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/server for the purposes
of preserving evidence records/server for the purpose of preserving evidence
records<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>4. section 2: list after
second paragraph <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>The list covers two items
where I wonder if they should not be slightly reworded?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Old: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>&#8220;- certification
paths containing end entity certificates through trust anchors<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>- certification paths
containing intermediate certificates through trust anchors&#8221;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>New: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>&#8220;- certification
paths containing end entity certificates up to their trust anchors<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>- certification paths
containing intermediate certificates up to their trust anchors&#8221;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>5. section 2: list at end
of section: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/- SCVP server returns a
response with status as of time of interest and including requested evidence
records/- SCVP server returns a response with status as of time of interest and
includes requested evidence records<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>6. section 3: second
paragraph: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/CA who issued the end
entity certificate through a trust anchor/CA who issued the end entity
certificate up to its trust anchor/<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>7. section 4: first
paragraph: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>This is just a
proposal/question whether it might be better??? But maybe a &#8220;MUST&#8221;
is too strong here?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/For
id-swb-ers-pkc-cert, the evidence record is calculated over the value of the
cert field in the CertReply object./For id-swb-ers-pkc-cert, the evidence
record MUST be calculated over the value of the cert field in the CertReply
object.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>And maybe also a &#8220;MUST&#8221;
instead of the &#8220;is&#8221; in the sentence following this one?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>8. section 4: second paragraph:
&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/If the server can not
return an EvidenceRecord for the requested information/If the server can not
return an EvidenceRecord for the requested information item<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>9.section 4: second
paragraph: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>And this is only a personal
question just for my understanding: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Is the &#8220;empty field&#8221;
sufficient compared to a possible field value e.g. &#8220;Not available&#8221;.
Could there be cases where an &#8220;empty field&#8221; can result and not mean
the value can not be provided, e.g. value is unclear or undefined? But probably
this is a quite theoretical question?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>10. section 5: equal in first
paragraph of 5.1, 5.2, 5.3 and 5.4<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>These paragraphs all
state analogue to <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>&#8220;Requests
containing id-swb-ers-best-cert-path as a WantBack MUST also contain
id-swb-best-cert-path.&#8221;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Question: What happens if
not both are in the request but only &#8220;id-swb-ers-best-cert-path&#8221;?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>11. section 5.4: title:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/Evidence record for a
revocation information/Evidence record for revocation information<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>12. section 5.4: second paragraph:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>And again a personal
question for my understanding. (Probably I just miss the point?)<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Why can the generation of
cumulative CRLs simplify the maintenance of evidence records?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>13. section 5.5: first
paragraph: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/all information
returned via in the replyWantBacks field/all information returned via the
replyWantBacks field<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>14. section 5.5: last
paragraph: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/indicates the type of
replyWantBack is covered by the associated EvidenceRecord./indicates the type
of replyWantBack covered by the associated EvidenceRecord.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>15. section 5.5: last
paragraph: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/does not have an
EvidenceRecord for particular replyWantBack object/does not have an
EvidenceRecord for a particular replyWantBack object<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>16. section 5.6: first
paragraph: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>I am not sure I
understand the first two sentences: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>&#8220;The
id-swb-partial-cert-path is an alternative to id-swb-best-cert-path. This is
the only OID defined in this document for which an EvidenceRecord is not
returned in the response.&#8221;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>This sounds to me like a
contradiction to section 5.2 which I understood that an Evidence record to be returned
in the response???<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>17. section 5.6: second
paragraph: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Is this a spelling
mistake?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/SCVP clients can
include id-swb-pkc-partial-cert-path/SCVP clients can include id-swb-partial-cert-path<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>18. section 6: second
paragraph: <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Should this be a capital &#8220;SHOULD&#8221;
in the sense of RFC2119?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>s/Relying parties should
ignore trust anchors contained in unsigned SCVP responses./Relying parties SHOULD
ignore trust anchors contained in unsigned SCVP responses.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'>Thanks, Tobias<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span lang=EN-GB
style='font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style='font-weight:bold'>On Behalf Of </span></b>Carl Wallace<br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, November 08, 2007
7:01 PM<br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: New Version
Notification for draft-ietf-ltans-ers-scvp-04 </span></font><span lang=EN-US><o:p></o:p></span></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>The
primary change in this version changes the handling of revocation information
by passing an evidence record for each revocation information object instead of
one covering the set.&nbsp; The original intent was for the ER wantBack to
cover any corresponding wantBack but that approach wasn't viable due to the way
the certificate value is returned.&nbsp; Given that this property has been
lost, it's easier in practice to maintain ERs for each CRL independently vs. as
a set for inclusion in a wantBack.</span></font><o:p></o:p></p>

<p><font size=2 face="Times New Roman"><span style='font-size:10.0pt'>&gt;
-----Original Message-----</span></font> <br>
<font size=2><span style='font-size:10.0pt'>&gt; From: IETF I-D Submission Tool
[<a href="mailto:[email-masked]">mailto:[email-masked]</a>] </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; Sent: Thursday, November 08,
2007 12:52 PM</span></font> <br>
<font size=2><span style='font-size:10.0pt'>&gt; To: [email-masked]</span></font>
<br>
<font size=2><span style='font-size:10.0pt'>&gt; Cc: [email-masked]</span></font>
<br>
<font size=2><span style='font-size:10.0pt'>&gt; Subject: New Version Notification
for draft-ietf-ltans-ers-scvp-04 </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; A new version of I-D,
draft-ietf-ltans-ers-scvp-04.txt has </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; been successfuly submitted by
Carl Wallace and posted to the </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; IETF repository.</span></font>
<br>
<font size=2><span style='font-size:10.0pt'>&gt; </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt;
Filename:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-ietf-ltans-ers-scvp</span></font>
<br>
<font size=2><span style='font-size:10.0pt'>&gt; Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
04</span></font> <br>
<font size=2><span style='font-size:10.0pt'>&gt;
Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Using SCVP to Convey Long-term
Evidence Records</span></font> <br>
<font size=2><span style='font-size:10.0pt'>&gt;
Creation_date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2007-11-08</span></font>
<br>
<font size=2><span style='font-size:10.0pt'>&gt; WG
ID:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ltans</span></font> <br>
<font size=2><span style='font-size:10.0pt'>&gt; Number_of_pages: 18</span></font>
<br>
<font size=2><span style='font-size:10.0pt'>&gt; </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; Abstract:</span></font> <br>
<font size=2><span style='font-size:10.0pt'>&gt; The Simple Certificate
Validation Protocol (SCVP) defines an </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; extensible means of delegating
the development and validation </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; of certification paths to a
server.&nbsp; It can be used to </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; support the development and
validation of certification paths </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; well after the expiration of
the certificates in the path by </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; specifying a time of interest
in the past.&nbsp; The Evidence </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; Record Syntax (ERS) defines
structures, called evidence </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; records, to support
non-repudiation of existence of data.&nbsp; </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; Evidence records can be used
to preserve materials that </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; comprise a certification path
such that trust can be </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; established in the
certificates after the expiration of the </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; certificates in the path and
after the cryptographic </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; algorithms used to sign the
certificates in the path are no </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; longer secure.&nbsp; This
document describes an application of </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; SCVP to serve this purpose
using the WantBack feature of SCVP </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; to convey evidence records.</span></font>
<br>
<font size=2><span style='font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; The IETF Secretariat.</span></font>
<br>
<font size=2><span style='font-size:10.0pt'>&gt; </span></font><br>
<font size=2><span style='font-size:10.0pt'>&gt; </span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C826EF.DE95B6B0--

From: Carl Wallace <[email-masked]>
To: [email-masked]
Subject: RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 
Date: Thu, 8 Nov 2007 13:01:27 -0500 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C82231.61FDE1C7
Content-Type: text/plain

The primary change in this version changes the handling of revocation
information by passing an evidence record for each revocation information
object instead of one covering the set.  The original intent was for the ER
wantBack to cover any corresponding wantBack but that approach wasn't viable
due to the way the certificate value is returned.  Given that this property
has been lost, it's easier in practice to maintain ERs for each CRL
independently vs. as a set for inclusion in a wantBack.

> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Thursday, November 08, 2007 12:52 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 
> 
> 
> A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has 
> been successfuly submitted by Carl Wallace and posted to the 
> IETF repository.
> 
> Filename:	 draft-ietf-ltans-ers-scvp
> Revision:	 04
> Title:		 Using SCVP to Convey Long-term Evidence Records
> Creation_date:	 2007-11-08
> WG ID:		 ltans
> Number_of_pages: 18
> 
> Abstract:
> The Simple Certificate Validation Protocol (SCVP) defines an 
> extensible means of delegating the development and validation 
> of certification paths to a server.  It can be used to 
> support the development and validation of certification paths 
> well after the expiration of the certificates in the path by 
> specifying a time of interest in the past.  The Evidence 
> Record Syntax (ERS) defines structures, called evidence 
> records, to support non-repudiation of existence of data.  
> Evidence records can be used to preserve materials that 
> comprise a certification path such that trust can be 
> established in the certificates after the expiration of the 
> certificates in the path and after the cryptographic 
> algorithms used to sign the certificates in the path are no 
> longer secure.  This document describes an application of 
> SCVP to serve this purpose using the WantBack feature of SCVP 
> to convey evidence records.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
> 

------_=_NextPart_001_01C82231.61FDE1C7
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.34">
<TITLE>RE: New Version Notification for draft-ietf-ltans-ers-scvp-04 </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>The primary change in this version changes the handling of revocation information by passing an evidence record for each revocation information object instead of one covering the set.&nbsp; The original intent was for the ER wantBack to cover any corresponding wantBack but that approach wasn't viable due to the way the certificate value is returned.&nbsp; Given that this property has been lost, it's easier in practice to maintain ERs for each CRL independently vs. as a set for inclusion in a wantBack.</FONT></P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: IETF I-D Submission Tool [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, November 08, 2007 12:52 PM</FONT>
<BR><FONT SIZE=2>&gt; To: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Cc: [email-masked]</FONT>
<BR><FONT SIZE=2>&gt; Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has </FONT>
<BR><FONT SIZE=2>&gt; been successfuly submitted by Carl Wallace and posted to the </FONT>
<BR><FONT SIZE=2>&gt; IETF repository.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Filename:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; draft-ietf-ltans-ers-scvp</FONT>
<BR><FONT SIZE=2>&gt; Revision:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 04</FONT>
<BR><FONT SIZE=2>&gt; Title:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Using SCVP to Convey Long-term Evidence Records</FONT>
<BR><FONT SIZE=2>&gt; Creation_date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2007-11-08</FONT>
<BR><FONT SIZE=2>&gt; WG ID:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ltans</FONT>
<BR><FONT SIZE=2>&gt; Number_of_pages: 18</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Abstract:</FONT>
<BR><FONT SIZE=2>&gt; The Simple Certificate Validation Protocol (SCVP) defines an </FONT>
<BR><FONT SIZE=2>&gt; extensible means of delegating the development and validation </FONT>
<BR><FONT SIZE=2>&gt; of certification paths to a server.&nbsp; It can be used to </FONT>
<BR><FONT SIZE=2>&gt; support the development and validation of certification paths </FONT>
<BR><FONT SIZE=2>&gt; well after the expiration of the certificates in the path by </FONT>
<BR><FONT SIZE=2>&gt; specifying a time of interest in the past.&nbsp; The Evidence </FONT>
<BR><FONT SIZE=2>&gt; Record Syntax (ERS) defines structures, called evidence </FONT>
<BR><FONT SIZE=2>&gt; records, to support non-repudiation of existence of data.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; Evidence records can be used to preserve materials that </FONT>
<BR><FONT SIZE=2>&gt; comprise a certification path such that trust can be </FONT>
<BR><FONT SIZE=2>&gt; established in the certificates after the expiration of the </FONT>
<BR><FONT SIZE=2>&gt; certificates in the path and after the cryptographic </FONT>
<BR><FONT SIZE=2>&gt; algorithms used to sign the certificates in the path are no </FONT>
<BR><FONT SIZE=2>&gt; longer secure.&nbsp; This document describes an application of </FONT>
<BR><FONT SIZE=2>&gt; SCVP to serve this purpose using the WantBack feature of SCVP </FONT>
<BR><FONT SIZE=2>&gt; to convey evidence records.</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The IETF Secretariat.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C82231.61FDE1C7--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ltans-ers-scvp-04.txt 
Date: Thu, 08 Nov 2007 13:00:02 -0500
Sender: [email-masked]

--NextPart

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           : Using SCVP to Convey Long-term Evidence Records
	Author(s)       : C. Wallace
	Filename        : draft-ietf-ltans-ers-scvp-04.txt
	Pages           : 18
	Date            : 2007-11-08

The Simple Certificate Validation Protocol (SCVP) defines an
extensible means of delegating the development and validation of
certification paths to a server.  It can be used to support the
development and validation of certification paths well after the
expiration of the certificates in the path by specifying a time of
interest in the past.  The Evidence Record Syntax (ERS) defines
structures, called evidence records, to support non-repudiation of
existence of data.  Evidence records can be used to preserve
materials that comprise a certification path such that trust can be
established in the certificates after the expiration of the
certificates in the path and after the cryptographic algorithms used
to sign the certificates in the path are no longer secure.  This
document describes an application of SCVP to serve this purpose using
the WantBack feature of SCVP to convey evidence records.

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-ltans-ers-scvp-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ltans-ers-scvp-04.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ltans-ers-scvp-04.txt

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

Content-Type: text/plain
Content-ID:     <2007-11-08125140.I-D\@ietf.org>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: IETF I-D Submission Tool <[email-masked]>
Subject: New Version Notification for draft-ietf-ltans-ers-scvp-04 
Date: Thu, 08 Nov 2007 12:51:44 -0500
Sender: [email-masked]

A new version of I-D, draft-ietf-ltans-ers-scvp-04.txt has been successfuly submitted by Carl Wallace and posted to the IETF repository.

Filename:	 draft-ietf-ltans-ers-scvp
Revision:	 04
Title:		 Using SCVP to Convey Long-term Evidence Records
Creation_date:	 2007-11-08
WG ID:		 ltans
Number_of_pages: 18

Abstract:
The Simple Certificate Validation Protocol (SCVP) defines an
extensible means of delegating the development and validation of
certification paths to a server.  It can be used to support the
development and validation of certification paths well after the
expiration of the certificates in the path by specifying a time of
interest in the past.  The Evidence Record Syntax (ERS) defines
structures, called evidence records, to support non-repudiation of
existence of data.  Evidence records can be used to preserve
materials that comprise a certification path such that trust can be
established in the certificates after the expiration of the
certificates in the path and after the cryptographic algorithms used
to sign the certificates in the path are no longer secure.  This
document describes an application of SCVP to serve this purpose using
the WantBack feature of SCVP to convey evidence records.

The IETF Secretariat.