David A. Cooper wrote:
Peter Sylvester wrote:
It seems that you have not addressed at all the inconsistencies
mentioned in:
http://www.imc.org/ietf-pkix/mail-archive/msg03248.html
Peter,
I looked over this message again and see that we did forget to
change "requestorName" to "responderName" in section 3.6. We can
correct this in authors' 48 hours. I do not believe that any other
changes need to be made to this document.
Paul Hoffman reponded yo the first sentence.
You are the editor, and you don't want to make more changes?
Most of your comments seem to be related to your claim that
statements of the form "value X MUST be set to TRUE" are incorrect
if the ASN.1 specifies a DEFAULT value of TRUE for X. This seems
to be confusing "DEFAULT" and "OPTIONAL", which are encoded
similarly in DER but have very different semantics. When the
ResponseFlags item appears in a request, each of its fields
(fullRequestInResponse, responseValidationPolByRef,
protectResponse, and cachedResponse) must be set to either TRUE or
FALSE. This is a requirement since none of the fields are
OPTIONAL. The fact that a DEFAULT value is defined for each of the
fields does not change this. The presence of DEFAULT values
affects how ResponseFlags is encoded using DER, but does not affect
the fact that each of these fields must be assigned a value of
either TRUE or FALSE. Note that the text never says "MUST be set
to TRUE in the encoding", it always says "MUST be set to TRUE".
Most of relate comments relate to different things than this small
propblem of
wording of how to encode a two value item. It would be nice iff you could
address them in a similar detailed way as this small detail:
Anyway:
SCVP clients that support delegated path validation (DPV) as defined
in [RQMTS] require an authenticated response. Unless a protected
transport mechanism (such a TLS) is used, such clients MUST always
set this value to TRUE or omit the responseFlags item entirely,
which requires the server to return a protected response.
Shouldn't the the 'or' be changed into 'i.e.' or he rest of the sentence
removed.
You might consider to add the explanations above to the text, since there are
people out that do not have 20 years of experience with ASN.1 and
its encodings.
This is not the first occurence of such wording, and people have
created errors
in encodings. (e.g. with 3161).
You may try to understand my suggestion as an attempt to avoid
misinterpretations of
using the verb 'set' concerning of the value of an item and how it is encoded.
You also claim that there is something in section 3.10 that is
inconsistent with RFC 3379. However, Tim Polk used the RFC 3379
compliance matrices to demonstrate that SCVP meets all the
requirements of RFC 3379. The text that appears in section 3.10
was discussed at length in late January and early February and at
that point there seemed to be agreement that the text addressed
item #14 in the requirements matrix.
Frankly, I don't care whether some religious or scientific person
had declared that the Sun is turning
around Earth.
paragraph 3.10
This is inconsistent with the 3379. 3379 does not allow a server
not to copy the field.
3379
The DPV server MUST be able, upon request, copy a text field provided
by the client into the DPV response. As an example, this field may
relate to the nature or reason for the DPV query.
SCVP draft
Conforming SCVP client implementations MAY support inclusion of this
item in requests. Conforming SCVP Server implementations MUST
accept requests that include this item. When generating non-cached
responses, conforming SCVP Server implementations MUST copy the
contents of this item into the requestorText item in the
corresponding response (see Section 4.13).
The SCVP text seems reasonable but the client expects that text to
be returned,
otherwise why bother to set it in the request. Or, one could deduce
that cached
responses cannot be produced in that case. If the client does not
indicate that
it doesn't want cached responses, it is not clear whether a conforming server
can respond with a cached response without copying the response.
Point 1 in paragraph 4
1. A success response to a request made over a protected transport
such as TLS. These responses SHOULD NOT be protected by the
server.
If the client indicates a TRUE value in a protectResponse, then the
previous seems not
good to me:
- When a TLS is used then a client MAY choose not indicate a FALSE
value for protectResponses.
- When TLS is used and protectResponses is FALSE then a server
SHOULD NOT not to protect the response. (I am not sure whether
this would even be better MAY NOT).
- When protectResponse is TRUE, the server MUST protect the response
independantly of the protection of the transport.
Dave
--
To verify the signature, see http://edelpki.edelweb.fr/ Cela vous
permet de charger le certificat de l'autorité; die Liste mit
zurückgerufenen Zertifikaten finden Sie da auch.