Subject: RE: draft-ietf-ltans-ers-scvp-04 - minor editorial suggestions

From: Carl Wallace <[email-masked]>
Date: Fri, 16 Nov 2007 13:28:13 -0500

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.

> -----Original Message----- 
> 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. 
> 
>