Subject: SCVP Draft 17: Summary of changes

From: Tim Polk <[email-masked]>
Date: Mon, 14 Feb 2005 17:59:09 -0500

Folks,

A new version of SCVP-17 was posted this afternoon.  IMHO, this version 
fully satisfies RFC 3379, and is responsive to the comments submitted on 
the WG mailing list.  Ever the optimist, I believe this draft is a strong 
candidate for WG consensus.

Please spend some time reviewing the new draft so we can gauge consensus 
and either tweak the document before the ID submission deadline (next 
Monday!) or forward it to the ADs.

In the interest of an efficient review, here is a summary of the changes:

(1) All of the comments submitted to the list before Christmas were 
reviewed.  Comments where Trevor had worked out a resolution on the list 
are included here and many (but not all) of the remaining comments were 
addressed.
(2) Inconsistencies between the text and any ASN.1 structures have been 
resolved.
(3) Draft 16 used the term "signed" to refer to messages protected by 
either a digital signature or a (H)MAC.  Draft 17 refers to these messages 
as "protected" and reserves the word "signed" for messages protected by a 
digital signature.
(4) The Diffie-Hellman based authentication method was changed from MUST to 
SHOULD implement.
(5) The text for validation policies, validation algoriothms and name 
validation algorithms has all been revised for clarity.
(6) A field has been added to the validation policy response message so 
that servers can indicate the type(s) of status information the server is 
capable of using, as required in RFC 3379.
(7) Validation policies are now required to include default values for all 
parameters.  Draft -16 permitted servers to create policies where clients 
were forced to supply values for some parameters.
(8) A requestor name field was added to the cv request message, so that 
clients can include an asserted identity, as required in RFC 3379.  Servers 
may still return an authenticated identity for the client if available.
(9) The key usage and extended key usage specifications have been enhanced 
to permit a client to state "no requirements".
(10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure 
from the scvp request message to indicate its policy (in the scvp response 
and policy response messages).
(11) The validation error OIDs associated with the basic validation 
algorithm and name validation algorithm have been scrubbed.
(12) The keyPurposeID in the name validation algorithm was renamed 
nameCompAlgId.  While some of the OIDs specified in this document 
correspond to extended key usages, that is not a requirement of the 
specification.  The important point was that the OID identified the 
algorithm used to compare names in the end certificate.
(13) The isCA option to support partial path validation was removed from 
the validation policy.  To use this feature securely, extensive additions 
to the protocol were required to return a set of interim state variables 
from an incomplete run of RFC 3280 Section 6.1 path validation.  The 
complexity was considered an impediment to completion of the document and 
was not a requirement in RFC 3379.  (This feature may be specified in a 
separate document in the future, using the SCVP extensions mechanism.)
(14) Clients signal whether a cached response is acceptable using the 
responseFlags rather than a wantback as in draft -16.
(15) When providing a list of certificates in the replyWantbacks in an scvp 
response message, servers are now required to order the certificates 
beginning with the end certificate.  (This is a requirement stated in RFC 
3379.)
(16) When performing Diffie-Hellman where the client has an ephemeral key 
and the server has a static key, the ephemeral key is conveyed in the 
authenticated data wrapper rather than the cv request.  The draft does not 
allow ephemeral - ephemeral but does support pre-shared keys.
(17) A new failure code was added to reply status to handle the case where 
all checks were performed successfully, however one or more of the 
wantBacks could not be satisfied.
(18) The replychecks for status checking were extended to cover the case 
where the server cannot locate a source of status information.  (This 
differentiates the failure from one where a source is known but network or 
other errors prevented getting the information.)

Of the comments which were not incorporated into the document:

(A) The editors disagreed with the comment that path validation algorithms 
other than that in RFC 3280 should be supported.  This is a PKIX WG 
specification, and there is no requirement in RFC 3379 to support non-PKIX 
path validation.  Consequently, this change was not made.
(B) The descriptions of validation algorithm and validation policy more 
clearly delineate the differences, but I am unsure if all of that class of 
comments are satisfied.
(C) Changes to ASN.1 syntax for elegance alone were not implemented; beauty 
is in the eye of the beholder and that debate would never end.  ASN.1 
changes were only made to enforce restrictions specified in the text or for 
consistency with the text (e.g., add a missing item described elsewhere.)

Thanks,

Tim Polk

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 15 Feb 2005 13:33:38 +0100

Tim (or to the ever optimist)

> the WG mailing list.  

My comments 46 to 68 have never been responded on the list.

I replied to the disposition of comments for 1-45 stating that several 
comments were not correctly understood and resolved to my satisfaction, but 
I got no answer.

Under these conditions, I am rather pessimistic, since I have not yet seen 
the draft.

Denis

> Ever the optimist, I believe this draft is a 
> strong candidate for WG consensus.
> 
> either a digital signature or a (H)MAC.  Draft 17 refers to these 
> messages as "protected" and reserves the word "signed" for messages 
> protected by a digital signature.
> (4) The Diffie-Hellman based authentication method was changed from MUST 
> to SHOULD implement.
> that servers can indicate the type(s) of status information the server 
> is capable of using, as required in RFC 3379.
> (7) Validation policies are now required to include default values for 
> all parameters.  Draft -16 permitted servers to create policies where 
> clients were forced to supply values for some parameters.
> clients can include an asserted identity, as required in RFC 3379.  
> Servers may still return an authenticated identity for the client if 
> available.
> (9) The key usage and extended key usage specifications have been 
> enhanced to permit a client to state "no requirements".
> from the scvp request message to indicate its policy (in the scvp 
> response and policy response messages).
> the validation policy.  To use this feature securely, extensive 
> additions to the protocol were required to return a set of interim state 
> variables from an incomplete run of RFC 3280 Section 6.1 path 
> validation.  The complexity was considered an impediment to completion 
> of the document and was not a requirement in RFC 3379.  (This feature 
> may be specified in a separate document in the future, using the SCVP 
> extensions mechanism.)
> (15) When providing a list of certificates in the replyWantbacks in an 
> scvp response message, servers are now required to order the 
> certificates beginning with the end certificate.  (This is a requirement 
> stated in RFC 3379.)
> (16) When performing Diffie-Hellman where the client has an ephemeral 
> key and the server has a static key, the ephemeral key is conveyed in 
> the authenticated data wrapper rather than the cv request.  The draft 
> does not allow ephemeral - ephemeral but does support pre-shared keys.
> (17) A new failure code was added to reply status to handle the case 
> where all checks were performed successfully, however one or more of the 
> differentiates the failure from one where a source is known but network 
> or other errors prevented getting the information.)
> 
> (A) The editors disagreed with the comment that path validation 
> algorithms other than that in RFC 3280 should be supported.  This is a 
> PKIX WG specification, and there is no requirement in RFC 3379 to 
> support non-PKIX path validation.  Consequently, this change was not made.
> clearly delineate the differences, but I am unsure if all of that class 
> of comments are satisfied.
> (C) Changes to ASN.1 syntax for elegance alone were not implemented; 
> beauty is in the eye of the beholder and that debate would never end.  
> ASN.1 changes were only made to enforce restrictions specified in the 
> text or for consistency with the text (e.g., add a missing item 
> described elsewhere.)
> 
> Thanks,
> 
> Tim Polk
> 
>

---

From: Tim Polk <[email-masked]>
Date: Tue, 15 Feb 2005 09:48:43 -0500

Denis,

The editors have been working feverishly to meet the deadlines.  In some 
cases, the disposition of comments are currently chicken scratch on 
paper.  They will be submitted to the list as soon as we can document things.

However, you should understand that some comments may not be resolved to 
your satisfaction.  We are looking for *rough consensus* here.  That means 
the WG as a group needs to be satisfied on each issue, but some individuals 
will inevitably be unhappy with the resolution of some particular 
issues.  That is just life.

IMHO, issues related to consistency with RFC 3379 are show stoppers - SCVP 
must be responsive to our requirements document!  Issuers related to 
elegance and personal preference are not show stoppers, and should not be 
allowed to prevent this document from moving forward.

Anyway, we will get the disposition of your comments (and others) 
documented and onto the list today or tomorrow.  I'm looking forward to 
your comments on our disposition of your comments.

Thanks,

Tim

At 01:33 PM 2/15/2005 +0100, Denis Pinkas wrote:
>comments were not correctly understood and resolved to my satisfaction, 
>but I got no answer.
>
>>Ever the optimist, I believe this draft is a strong candidate for WG 
>>consensus.
>>scvp response message, servers are now required to order the certificates 
>>authenticated data wrapper rather than the cv request.  The draft does 
>>not allow ephemeral - ephemeral but does support pre-shared keys.
>>PKIX WG specification, and there is no requirement in RFC 3379 to support 
>>non-PKIX path validation.  Consequently, this change was not made.
>>text or for consistency with the text (e.g., add a missing item described 
>>elsewhere.)
>>Thanks,
>>Tim Polk
>
>
>

---

From: Tim Polk <[email-masked]>
Date: Tue, 15 Feb 2005 10:18:27 -0500

Denis,

I just realized the significance of your comment "since I have not yet seen 
the draft."  The ID announcement does not seem to have been posted, but the 
new draft is available right now from the PKIX WG charter page.

The URL for draft 17 is 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-17.txt

If I had recognized this situation, I would have included the URL in my 
message with the summary of changes yesterday.

Thanks,

Tim

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 15 Feb 2005 10:09:57 -0700

Tim,

I have read through your summary and the -17 draft and have no issues.
Many thanks to you, Trevor and others for staying on task.

Mike