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

From: [email-masked]
Date: Wed, 24 May 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Server-based Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-23.txt
	Pages		: 84
	Date		: 2006-3-3
	
SCVP allows a client to delegate certificate path construction and
   certificate path validation to a server.  The path construction or
   validation (e.g. making sure that none of the certificates in the
   path are revoked) is performed according to a validation policy,
   which contains one or more trust anchors.  It allows simplification
   of client implementations and use of a set of predefined validation
   policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-23.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-scvp-23.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-23.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 24 May 2006 17:48:21 -0400

All,

It is actually draft 24 of SCVP that was just posted.  The PKIX WG Web 
page is pointing to draft 23, but draft 24 has been posted to 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-24.txt.

I have also posted a diff file highlighting the changes between drafts 
23 and 24: 
http://csrc.nist.gov/pki/documents/PKIX/wdiff_draft-ietf-pkix-scvp-23_to_24.html.

Draft 24 contains no significant changes from draft 23.  We changed the 
title to "Server-based Certificate Validation Protocol (SCVP)" from 
"Standard Certificate Validation Protocol (SCVP)" since we were informed 
that use of the word "Standard" could cause problems and also made a few 
changes to correct some ID-nits and fixed a typographical error.  No 
other changes were made to the document.

Dave

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 25 May 2006 14:07:35 +0200

It seems that you have not addressed at all the inconsistencies
mentioned in:

      http://www.imc.org/ietf-pkix/mail-archive/msg03248.html

David A. Cooper wrote:
> Draft 24 contains no significant changes from draft 23.  We changed 
> the title to "Server-based Certificate Validation Protocol (SCVP)" 
> from "Standard Certificate Validation Protocol (SCVP)" since we were 
> informed that use of the word "Standard" could cause problems and also 
> made a few changes to correct some ID-nits and fixed a typographical 
> error.  No other changes were made to the document.
>
> 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.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 25 May 2006 16:02:15 -0400

>      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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 May 2006 15:51:32 -0700

At 4:02 PM -0400 5/25/06, David A. Cooper wrote:
>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.

<process-alert>
BLARG! That is a significant technical change! That is *not* what 
AUTH48 is for.
</process-alert>

Please consider issuing a new draft with that change. That's what the 
I-D process is for.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 28 May 2006 14:50:45 +0200

David A. Cooper wrote:
> "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?

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

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2006 10:14:51 -0400

Peter:

I believe that this was discussed.  I think we need to ship the 
document.  Delay is causing problems.

Russ

At 08:50 AM 5/28/2006, Peter Sylvester wrote:

>>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 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
>using the verb 'set' concerning of the value of an item and how it is encoded.
>
>
>>
>>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
>
>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
>it doesn't want cached responses, it is not clear whether a conforming server
>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.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 May 2006 16:51:35 +0200

> 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 as
a response to david?

===>

Anyway:

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 May 2006 18:05:30 +0200

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 message
from months ago suggested textual changes.

And in my previous:

Point 1 in paragraph 4

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2006 11:45:16 -0400

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2006 13:06:05 -0400

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?

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 30 May 2006 21:05:07 +0200

> 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

Following David's argument, even when not encoding the optional
responseflags,     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.

>>>> sentence

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 May 2006 16:51:44 -0400

Peter:

I can see making this point in the text to add clarity, but the need 
for anything else is just not coming through.

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 May 2006 14:10:38 +0200

I am fine with this clarification.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite'; 
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch.