Subject: RE: New Version Notification for draft-ietf-ltans-ers-scvp-04

From: Carl Wallace <[email-masked]>
Date: Thu, 8 Nov 2007 13:01:27 -0500

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]] 
> 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.
> 
>

---

From: "Tobias Gondrom" <[email-masked]>
Date: Wed, 14 Nov 2007 19:55:04 +0100

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.