Russ Housley wrote:
This does not make sense to me. Why do you want to require the inclusion of an OPTIONAL field when the the semantic result is the same?
oops, I messed up "protectResponse" and "responseFlags" in such clients MUST always set this value to TRUE or omit the responseFlags item entirely, which requires the server to return a protected response. Following David's argument, even when not encoding the optionalresponseflags, protectResponse is then TRUE. Or, in this sentence, the first half talks about the value of an boolean,
and the second about how to encode something.
Russ At 12:05 PM 5/30/2006, Peter Sylvester wrote:I think I already did.Shouldn't the the 'or' be changed into 'i.e.' or he rest of the sentence removed.In fact, I suggested for all cases to avoid the potential misinterpretation, and my messagefrom months ago suggested textual changes. And in my previous: 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 notgood 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. Russ Housley wrote:I interpreted your previous not in a much different light. Can you suggest text that would resolve your concern?Russ At 10:51 AM 5/30/2006, Peter Sylvester wrote:Russ Housley wrote:Peter:I believe that this was discussed. I think we need to ship the document. Delay is causing problems.When, where, there was no response to my message? You hay have discussed something at the last IETF, but this is not in the minutes, and I never received an reply to my message.How can you claim that something has been discussed that I just mentioned fo the first time asa response to david? ===> 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 sentenceremoved.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 errorsin 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.--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.--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.
--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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature