Subject: SCVP chapter 3.3

From: Peter Sylvester <[email-masked]>
Date: Wed, 01 Mar 2006 15:26:37 +0100

I think that the text in 3.3 is not good and there is double text with 
section 7/

The first line "... contains a SEQUENCE of names ..." is not unfortunate
The definition says GeneralNames, so this is already asn.1 SEQUENCE. I 
think what is
meant is ".. contains a list of names ..." and "Although encoded as a 
SEQUENCE,
no order is implied." should be added.

The remaining of the first paragraph should not be there, it is already 
in section 7
concerning relaying. Talking about resources etc is really unrelated to the
description of that item.

The first sentence of the last paragraph is superfluous since this is 
just the syntax.

In section 7 change "sequence of names" to "list of names"

And: "the server-generated request MUST contain a requestorRef item 
consisting
if the names in the provided requestorRef and an identifier of the SCVP 
server."

We know alrteady that it is a GeneralName, and the order has no importance.

What is the value of returning a requestoRef, in particular because a 
server can
omit it, and even if not, the value is the same as provioded by the 
client, UNLESS
there is some missing text that indicates that the requestorRef is 
filled from the
response of a relay and not from the request, which means that it gets 
populated?

Section 7 says: 'This section does not impose requirement on servers 
that don't relay".
Doe it mean that a non relaying server MAY totally ignore the field and NOT
copy it into the CVResponse?

---

From: Tim Polk <[email-masked]>
Date: Wed, 01 Mar 2006 13:05:01 -0500

Peter,

IMHO, the most straightforward implementation of requestorRef would be 
achieved if the server maintained ordering and simply appended their name 
to the current value.  There is currently one sentence in Section 7 that 
implies this technique.

However, there is no security rationale for requiring ordering in the 
requestorRef list of names.  All that is required is that previous values 
be included in subsequent requests.

Since this is not a security requirement, and there is no reason to limit 
developers, I will make the appropriate changes to sections 3.3 and 7 to 
indicate the requestorRef is not ordered.  (I will post the text later 
today...)

SCVP servers that don't implement relay MUST satisfy the requirements in 
sections 3.3 and 4.7.   That is, they MUST copy the value into the 
requestorRef field in the response.  Such servers need not satisfy any 
additional requirements from Section 7.  That is, such servers need not 
review the names in requestorRef for their own name, since loopback is not 
an issue.

Thanks,

Tim Polk

At 03:26 PM 3/1/2006 +0100, you wrote:
>The remaining of the first paragraph should not be there, it is already in 
>section 7
>The first sentence of the last paragraph is superfluous since this is just 
>the syntax.
>
>And: "the server-generated request MUST contain a requestorRef item consisting
>there is some missing text that indicates that the requestorRef is filled 
>from the
>Section 7 says: 'This section does not impose requirement on servers that 
>don't relay".

---

From: Tim Polk <[email-masked]>
Date: Wed, 01 Mar 2006 17:38:03 -0500

Peter,

Here are my proposed edits.  Hopefully, these edits make it clear that 
there is no ordering requirement and remove the redundant text from section 
3.3.

Replace Section 3.3, paragraph 1 with the following text:

"The optional requestorRef item contains a list of names identifying SCVP 
servers, and it is intended for use in environments where SCVP relay is 
employed.  Although requestorRef is encoded as a SEQUENCE,  no order is 
implied.  The requestorRef item is used to detect looping in some 
configurations.  The value and use of requestorRef is defined in section 7."

In section 7, paragraph 3 second sentence:

Change
"If the request to be relayed already contains a requestorRef item, then 
the server-generated request MUST contain a requestorRef item constructed 
from this value followed by a GeneralName that contains an identifier of 
the SCVP server."

to
"If the request to be relayed already contains a requestorRef item, then 
the server-generated request MUST contain a requestorRef item constructed 
from this value and an additional GeneralName that contains an identifier 
of the SCVP server.

Section 7, Paragraph 5 Sentence 1:
Change:
"When an SVCP server receives a request that contains a requestorRef item, 
the server MUST check the sequence of names in the requestorRef item for 
its own identifier."
to
"When an SVCP server receives a request that contains a requestorRef item, 
the server MUST check the list of names in the requestorRef item for its 
own identifier."

I think that covers this one.

Thanks,

Tim Polk

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 03 Mar 2006 14:56:39 +0100

Tim,

inline.

> achieved if the server maintained ordering and simply appended their 
> name to the current value.  There is currently one sentence in Section 
> 7 that implies this technique.
or prepended.
> requestorRef list of names.  All that is required is that previous 
> values be included in subsequent requests.
Indeed.
>
> Since this is not a security requirement, and there is no reason to 
> limit developers, I will make the appropriate changes to sections 3.3 
> and 7 to indicate the requestorRef is not ordered.  (I will post the 
> text later today...)

You haven't responding to my somewhat unclear remark that
I think there there is
- duplicate text in section 3.3. with relaying.
- useless text since already implied y the syntax (last paragraph).

>
> SCVP servers that don't implement relay MUST satisfy the requirements 
> in sections 3.3 and 4.7.   That is, they MUST copy the value into the 
> additional requirements from Section 7.  That is, such servers need 
> not review the names in requestorRef for their own name, since 
> loopback is not an issue.
reading your response it seems that the main purpose of requesterRef
is for loop control  in relaying.  Why is it necessary to copy the
input value to the out, or better, depending on whether the response
is a chached one, the value is copied?

What is the corresponding requirement in 3379 or what is the purpose
of that feature.

>> I think that the text in 3.3 is not good and there is double text 
>> with section 7/
>>
>> The definition says GeneralNames, so this is already asn.1 SEQUENCE. 
>> I think what is
>> The remaining of the first paragraph should not be there, it is 
>> already in section 7
>> if the names in the provided requestorRef and an identifier of the 
>> SCVP server."
>>
>> response of a relay and not from the request, which means that it 
>> gets populated?
>>

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