Subject: RE: SCVP Draft 17: Summary of changes

From: "Seth Hitchings" <[email-masked]>
Date: Thu, 17 Feb 2005 14:28:29 -0500

Tim, 

I'd like to thank you and all of the other editors for pulling together
draft 17. I have no functional issues with this draft and would like to see
it achieve consensus. Our products will support draft 17 shortly.

If you do decide to put together another draft to address some of the
aesthetic issues, I'd like to see some of the tagging oddities (skipping
from 4 to 6, for example) addressed.

Thanks again,

Seth Hitchings
CoreStreet, Ltd.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tim Polk
Sent: Monday, February 14, 2005 5:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: SCVP Draft 17: Summary of changes

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: "David A. Cooper" <[email-masked]>
Date: Fri, 18 Feb 2005 10:11:03 -0500

>from 4 to 6, for example) addressed.
Several people have now commented stating that they believe it is 
important to modify the ASN.1 in SCVP so that explicit tags are 
sequential, etc.

So, Tim and I went through the document and made changes to the ASN.1 as 
follows:

(1) We renumbered explicit tags wherever there was a gap in the sequence 
in draft 17.
(2) We removed the explicit tagging where it was clear that the explicit 
tagging was not necessary.
(3) We defined DEFAULT values for several of the INTEGER and ENUMERATED 
values when defining a default value could be done without affecting the 
ASN.1 for any other fields.

I plan to submit draft 18 later today.  Below is a copy of all of the 
ASN.1 structures that have been changed since draft 17 (at least, I 
believe that this is all of them).

Dave

-----------------------------------------------------------------------------------

   CVRequest ::= SEQUENCE {
     cvRequestVersion           INTEGER DEFAULT 1,
     query                      Query,
     requestorRef           [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING
                                  OPTIONAL,
     requestNonce           [1] OCTET STRING OPTIONAL,
     requestorName          [2] GeneralName OPTIONAL,
     reqestExtensions       [3] Extensions OPTIONAL }

   ValidationPolicy ::= SEQUENCE {
     validationPolRef           ValidationPolRef,
     validationAlg          [0] ValidationAlg OPTIONAL,
     userPolicySet          [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                  IDENTIFIER OPTIONAL,
     inhibitPolicyMapping   [2] BOOLEAN OPTIONAL,
     requireExplicitPolicy  [3] BOOLEAN OPTIONAL,
     inhibitAnyPolicy       [4] BOOLEAN OPTIONAL,
     trustAnchors           [5] TrustAnchors OPTIONAL,
     keyUsages              [6] KeyUsages OPTIONAL,
     extendedKeyUsages      [7] SEQUENCE OF KeyPurposeId OPTIONAL }

   CVResponse ::= SEQUENCE {
     cvResponseVersion          INTEGER,
     policyID                   INTEGER,
     producedAt                 GeneralizedTime,
     responseStatus             ResponseStatus,
     respValidationPolicy   [0] RespValidationPolicy OPTIONAL,
     requestRef             [1] RequestReference OPTIONAL,
     requestorRef           [2] SEQUENCE SIZE (1..MAX) OF OCTET STRING
                                  OPTIONAL,
     requestorName          [3] GeneralNames OPTIONAL,
     replyObjects           [4] ReplyObjects OPTIONAL,
     respNonce              [5] OCTET STRING OPTIONAL,
     serverContextInfo      [6] OCTET STRING OPTIONAL,
     cvResponseExtensions   [7] Extensions OPTIONAL }

   ResponseStatus ::= SEQUENCE {
       statusCode               CVStatusCode DEFAULT okay,
       errorMessage             UTF8String OPTIONAL }

   CertReply ::= SEQUENCE {
     cert                       CertReference,
     replyStatus                ReplyStatus DEFAULT success,
     replyValTime               GeneralizedTime,
     replyChecks                ReplyChecks,
     replyWantBacks             ReplyWantBacks,
     validationErrors       [0] SEQUENCE SIZE (1..MAX) OF
                                  OBJECT IDENTIFIER OPTIONAL,
     nextUpdate             [1] GeneralizedTime OPTIONAL,
     certReplyExtensions    [2] Extensions OPTIONAL }

   ReplyCheck ::= SEQUENCE {
     check                      OBJECT IDENTIFIER,
     status                     INTEGER DEFAULT 0 }

   ValPolRequest ::= SEQUENCE {
     vpRequestVersion           INTEGER DEFAULT 1,
     requestNonce               OCTET STRING }

   ValPolResponse ::= SEQUENCE {
     vpResponseVersion                INTEGER,
     maxCVResponseVersion             INTEGER,
     maxVPResponseVersion             INTEGER,
     defaultPolicyID                  INTEGER,
     thisUpdate                       GeneralizedTime,
     nextUpdate                       GeneralizedTime OPTIONAL,
     validationPolices                SEQUENCE OF ValidationPolRef,
     validationAlgs                   SEQUENCE OF OBJECT IDENTIFIER,
     authPolicies                     SEQUENCE OF AuthPolicy,
     responseTypes                    ResponseTypes,
     defaultPolicyValues              RespValidationPolicy,
     revocationInfoTypes              RevocationInfoTypes,
     serverPublicKeys                 SEQUENCE OF KeyAgreePublicKey
                                        OPTIONAL,
     clockSkew                        INTEGER DEFAULT 10,
     requestNonce                     OCTET STRING OPTIONAL }

   AuthPolicy ::= CHOICE {
     authPolRefByOID       OBJECT IDENTIFIER,
     authPolRefByURI       IA5String }