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.
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".
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.
Dave