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:
“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?
“- certification paths containing end entity certificates through trust anchors
- certification paths containing intermediate certificates through trust anchors”
“- 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.