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: owner-ietf-ltans@xxxxxxxxxxxx
[mailto:owner-ietf-ltans@xxxxxxxxxxxx] On
Behalf Of Carl Wallace
Sent: Thursday, November 08, 2007 7:01
PM
To:
ietf-ltans@xxxxxxx
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:idsubmission@xxxxxxxx]
> Sent:
Thursday, November 08, 2007 12:52 PM
> To: cwallace@xxxxxxxxxxxx
> Cc: ietf-ltans@xxxxxxx
> 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.
>
>