|
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:
owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx] On Behalf Of Carl Wallace 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----- |