Subject: I-D ACTION:draft-ietf-pkix-scvp-23.txt

From: Peter Sylvester <[email-masked]>
Date: Mon, 06 Mar 2006 17:31:29 +0100

Here some issues with the latest draft.

- Caused to the recent changes to use DER encoding there
   there are several leftovers and inconsistencies in the wording
   concerning setting default values or omitting them.

- When an element is both present in a request and in a response,
   there are at least two paragraphs, but the description are
   not homogeneous, e.g. in order to see what can be set in a response
   one has to read the paragraph of the request.

Details:

paragraph 3.2.5.3

protectResponse cannot be set to TRUE in the encoding.

... "such clients MUST NOT set this value to FALSE"

paragraph 3.2.5.4

cachedResponse cannot be TRUE, it can only be absent. But the
wording here is not totally false because there is no phrase "or omitted".
nevertheless, inverting "is set to TRUE" to "is not set to FALSE"
avoids the misinterpretation.

3.2.6:

Why SHOULD servers support serverContextInfo? In case where
there is never any alternate response, this is never needed.

3.3:

The fist sentence of the last item is superfluous. it is obvious from
the syntax. Furthermore, the last sentence is somewhat in conflict
with 7, where servers SHOULD use a DNS name to ensure uniqueness.
In fact, the last two sentences are superfluous also because the first
item says: The value and use of requestorRef is defined in section 7.

new text proposal: "The requesterRef is used to detect looping in the
context of server relaying. The value and use of the item is discussed
in paragraph 7." followed by the second part concerning conformity.

Unless we decide not to return the value,  the part "may be omit from
cached responses" should say. "May omit in a responses that is to be
cached."

Also cf next.

paragraph 3.4:

The first text block handles requestNonce a bit better than 3.3 handles
requesterRef.

But it handles also parts of the server which IMO should be done in 4.10
(or the other way around). 4.10 could be the server returns a value
according to 3.4

What is the purpose of setting a Nonce and not setting cachedresponse to
FALSE?
in this case a MIM can just return a cached response. Why does a cached
response MUST NOT have a respNonce? It measn that, by setting a nonce,
a client actually instructs the server not to use the response later
in a cache. Is this intended?

paragraph 3.5:

Here we have a clear an simple text describing what the client does and
4.8 specifies what the server does (cf 3.4 vs 4.10)

paragraph 3.6:

- Last line on page 35 contains 'requesterName' instead of 'responderName'

- point 2: The protectResponse set to TRUE cannot occur since the
   request is encoded in DER.

- There is no relation between multiple keys and multiple certificates.
   Since the server includes an ESScertid, text should be adjusted.

paragraph 3.7

This copy of the PKIX-1 document useless.
All what should be said is that
"An SCVP server MUST reject an unrecognized critical
  extension and MUST treat recognized ones."

3.7.1 is simply a repetition of the definition.
3.7.2 is the standard behaviour.
3.7.3. is also just the standard description

to compare: nowhere you describe A GeneralName

Paragraph 3.8

protectResponse cannot be set to TRUE in the encoding.

The text: "if included, the signatureAlg item ..." should be
replaced by: The signatureAlg MUST/SHOULD specify one of
the algorithms supported by the server. A client MAY use
a policy response from the server in order to determine
a valid value."

Paragraph 3.9

cf. above 3.8

paragraph 3.10

This is inconsistent with the 3379. 3379 does not allow a server
not to copy the field.

c.f. also the discussion of 3.3 vs 4.7 and 3.4 vs 4.10 in relation with 4.13

paragraph 4:

point 1: SHOULD NOT be protected is wrong IMO.  They can have
a signature, in particular when the result needs to be validated later.
              MAY be unprotected depending on the policy.
There seems to be confusion between unprotected/protected
DPD and DPV. (I guess Denis had said this long time ago).

paragraph 4.7:

    It is good that almost all treatment of this field is now handled by
    paragraph 7. But the text looks inconsistent with paragraph 7 and 3.3
    where the value does not identify the original requester but the set of
    relays,

    As I have already mentioned several time, to me the term
    "only local significance" looks very misleading. In fact, it
    has no local significance at all, the only signficance is a
    global one to be used in loop detection. A DNS name is
    not 'only local significance' either.

   Since the value is only used for loop control, what is the
   purpose of returning it.

   I suggest the field be removed from the response, and
   4.7 deleted, or, if someone inists that it is returned, all
   qualifying text about local significance moved either to
   3.3 or 7.

   7 does not say that one returns the augmented list. So you just
   get what you have sent, and that's something you already know.

Paragraph 4.8

what means 'a server SHOULD support this item?' since support
can be not to create it?

The last text block should say: The specification does not indicate
how a client reacts on the presence of the value (identical or
different from the one in the request.

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