Subject: SCVP: Speak now or forever hold your peace...

From: [email-masked]
Date: Wed, 4 Aug 2004 20:06:11 -0400

Folks,

It is time to get serious and finish up SCVP.  In the slides presented at our 
meeting this morning, the SCVP editors requested a "Definitive and final list 
of all issues from workgroup".  I believe that is a reasonable request.  Let's 
do our best to get that list documented ASAP, so that -16 can be our *last*.

I am requesting that everyone in the WG make time to review SCVP and document 
any issues you find by Friday the 13th.  (I am not setting a deadline for 
terminating discussion - it may take a few days to reach consensus on the 
issue list.  I am just trying to surface all the issues ASAP.)  Once the issue 
list is stable, I am sure we can work out solutions.

Please post all technical comments to the list.  Editorial comments can be 
sent to Trevor directly.  Include SCVP in the subject line regardless! 

Thanks,

Tim Polk

---

From: Francis Dupont <[email-masked]>
Date: Thu, 05 Aug 2004 04:57:18 +0200

In your previous mail you wrote:

   It is time to get serious and finish up SCVP...

=> I had many comments about the previous draft but unfortunately some
are still valid. As an example of nits the application MIME types changed
but not everywhere so there are still both application/cv-request and
application/scvp-request in the document. I'll try to make all comments
before the dead-line and in the list (as previous comments sent in private
seemed to have been ignored).

Regards

[email-masked]

PS: I'd like to perform all the certificate validation needed by an IKE
server in a SCVP responder. I used a partial implementation of SCVP
in OpenSSL and for the IKE daemon racoon, both on FreeBSD and Linux.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 05 Aug 2004 17:36:19 +0200

Tim,

I am leaving for holidays tonight, so your message reached me just in time 
to tell you that I will have not have the time to send more comments before 
the deadline of Friday 13.

I may simply say that in general the answers from Trevor have not correctly 
answered to the nine concerns I raised on July 28.

The major concern remains to ability to refence only one OID for the 
validation policy and leave ALL the complexity of client-defined parameters 
for a validation policy or a validation algorithm (whatever name is being 
used) as an OPTIONAL feature that DOES not have to be supported by implementers.

I am also supportive of a much cleaner separation between CVP and DPD as 
advocated by Mike. Even if there are similarities, the two protocols are 
differents. Some restructuring of the document will be necessary so that 
this goal can be achieved.

The comments from Peter should not be forgotten.

As mentionned by Steve, the S from SCVP is still supposed to mean Simple.

Denis

---

From: [email-masked]
Date: Thu, 5 Aug 2004 13:02:18 -0400

Denis,

I certainly am counting your nine concerns and Peter's four comments as 
unresolved issues.  I understand that deadline will be hard for some people to 
meet, and am sorry that you are one of that group.  As you have commented 
extensively in the past, I am hopeful that 99% of your concerns have already 
been raised.

You may have noticed that I requested (begged?) that issues be raised by the 
deadline, but didn't absolutely forbid posting new issues after that date.  We 
are a security WG, and if security issues are identified on August 14 we will 
have to address them.  (However, late submissions may be ignored if they do 
not fall into that category.)

I hope everyone will treat this as a hard deadline, though.  Establishing a 
complete list is more than a courtesy to the editors of SCVP.  It is a 
necessary step towards completion and progression of SCVP.  The status of SCVP 
has become a major impediment to the development and deployment of products.  
This deadline is a necessary evil.

With respect to the two issues highlighted below:
(1) Your major concern (referencing a single OID in the request) is well 
understood, and has already prompted a lot of discussion.  I expect we can 
handle this one in your absence.  
(2) I believe we can clarify the DPD - DPV split quite easily.  Restructuring 
the document is not necessary, though, and would introduce unacceptable delays.

Have a nice vacation.

Tim

---

From: [email-masked]
Date: Thu, 5 Aug 2004 16:34:37 -0400

Francis,

I am sorry some previous comments appeared to be overlooked.  I appreciate 
your resubmitting those so we can build a complete issues list.

BTW, I certainly consider issues like MIME types to be important issues, 
rather than nits.  These issues could adversely affect interoperability, and 
should be noted on list.  Typos, etc. are things best sent straight to the 
editors, since they may become OBE based on other edits.

Thanks,

Tim

---

From: "Michael Myers" <[email-masked]>
Date: Fri, 6 Aug 2004 15:57:14 -0700

Tim,

Regarding SCVP closure, I still feel that the document should
normatively translate 3379's notions of DPD and DPV into SCVP ASN.1.
Doing so will reduce ambiguity down the road.  Think OCSP nonces.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of [email-masked]
Sent: Wednesday, August 04, 2004 5:06 PM
To: [email-masked]
Subject: SCVP: Speak now or forever hold your peace...

Folks,

It is time to get serious and finish up SCVP.  In the slides presented
at our
meeting this morning, the SCVP editors requested a "Definitive and final
list
of all issues from workgroup".  I believe that is a reasonable request.
Let's
do our best to get that list documented ASAP, so that -16 can be our
*last*.

I am requesting that everyone in the WG make time to review SCVP and
document
any issues you find by Friday the 13th.  (I am not setting a deadline
for
terminating discussion - it may take a few days to reach consensus on
the
issue list.  I am just trying to surface all the issues ASAP.)  Once the
issue
list is stable, I am sure we can work out solutions.

Please post all technical comments to the list.  Editorial comments can
be
sent to Trevor directly.  Include SCVP in the subject line regardless!

Thanks,

Tim Polk

---

From: "Faisal Maqsood" <[email-masked]>
Date: Tue, 10 Aug 2004 15:51:25 +0500

Hi,

Below are my points on SCVP-15:

- In following structure why 'requestRefHash' is not tagged?
- Should 'IsCA' not be 'isCA'?
- Should 'SignResponse' not be 'signResponse'?
- Should there not be commas in tags 13 and 14?
- If we know default values for 'requestRefHash' and tagged 0 to 5, why we
are not making these as optional? To make them optional will benifit for low
network traffic and if these optional value are not inserted in request
server will automatically use default values.

Query ::= SEQUENCE {
     queriedCerts             SEQUENCE SIZE (1..MAX) OF CertReference,
     checks                   CertChecks,
     wantBack                 WantBack,
     validationAlg            ValidationAlg,
     requestRefHash           BOOLEAN DEFAULT TRUE,
     fullPolResponse      [0] BOOLEAN DEFAULT FALSE,
     inhibitPolMap        [1] BOOLEAN DEFAULT FALSE,
     requireExplicitPol   [2] BOOLEAN DEFAULT FALSE,
     ignoreAnyPol         [3] BOOLEAN DEFAULT FALSE,
     IsCA                 [4] BOOLEAN DEFAULT FALSE,
     SignResponse         [5] BOOLEAN DEFAULT TRUE,
     serverContextInfo    [6] OCTET STRING OPTIONAL,
     validityTime         [7] GeneralizedTime OPTIONAL,
     trustAnchors         [8] TrustAnchors OPTIONAL,
     intermediateCerts    [9] CertBundle OPTIONAL,
     revInfos            [10] RevocationInfos OPTIONAL,
     keyUsage            [11] KeyUsage OPTIONAL,
     extendedKeyUsage    [12] ExtKeyUsageSyntax OPTIONAL,
     queryExtensions     [13] Extensions OPTIONAL
     producedAt          [14] GeneralizedTime OPTIONAL
     validationPolRef    [15] ValidationPolRef OPTIONAL}

- In following structure tags are not correct for 'attrCert' and 'acRef'?

    CertReference ::= CHOICE {
      pkc                   PKCReference,
      ac                    ACReference }

    PKCReference ::= CHOICE {
      cert              [1] Certificate,
      pkcRef            [2] ESSCertID }

    ACReference ::= CHOICE {
      attrCert          [1] AttributeCertificate,
      acRef             [2] ESSCertID }

- In above structure why tag start from 1 instead of 0 in 'cert'?

- In structure below why 'requestor' tag starts from 1 instead of 0?

    CVResponse ::= SEQUENCE {
      scvpVersion           INTEGER,
      policyID              INTEGER,
      producedAt            GeneralizedTime,
      responseStatus        ResponseStatus,
      requestRef            RequestReference,
      requestor         [1] OCTET STRING OPTIONAL,
      responder         [2] OCTET STRING OPTIONAL,
      replyObjects      [3] ReplyObjects OPTIONAL,
      requestNonce      [4] OCTET STRING OPTIONAL,
      serverContextInfo [5] OCTET STRING OPTIONAL,
      valPolResponse    [6] ValPolicy OPTIONAL,
      validationPolRef  [7] ValidationPolicyRef OPTIONAL
      respExtensions    [8] Extensions OPTIONAL }

- In following structure should 'requestHash' tag not be start from 0
instead 1?

    RequestReference ::= CHOICE {
      requestHash       [1] HashValue, -- hash of CVRequest
      fullRequest       [2] CVRequest }

- In following structure should 'nextUpdate' tag not be start from 0
instead 1?

    CertReply ::= SEQUENCE {
      cert                       CertReference,
      replyStatus                ReplyStatus,
      replyValTime               GeneralizedTime,
      replyChecks                ReplyChecks,
      replyWantBacks             ReplyWantBacks,
      valAlg                     ValidationAlg,
      nextUpdate             [1] GeneralizedTime OPTIONAL,
      certReplyExtensions    [2] Extensions OPTIONAL }

- In the following paragraph referenced section 3.2.7 should be 3.2.15 to
point CertBundle

  The octet string value for the certification path used to verify
  the certificate in the request, { id-swb 1 }, contains the
  CertBundle type.  The syntax and semantics of the CertBundle type
  are described in section 3.2.7.

Regards,
Faisal

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 05, 2004 05:06
Subject: SCVP: Speak now or forever hold your peace...

list
Let's
*last*.
document
issue

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 2004 11:51:53 +0200

I have many comments about the SCVP draft 15: in its current case
IMHO it should not be sent to the RFC editor. I've tried to classify
comments into major problems, ASN.1 problems and editorial problems.
Here are the major problems (other issues will be next messages):
 - IMHO we *really* need an explanation about the validation policy
   and algorithm terms. Currently this is spread between lines among
   the whole document.
 - there is no hint about how to return validation algorithm errors,
   two examples:
   * what happens when isCA is set in a query and the entity type of
     the certificate is not the right one? One can believe the status
     (want back 3) should be set to invalid but a more detailed report
     should be fine and this doesn't answer to the next point.
   * how to use the name validation algorithm errors? They are defined
     but there is no place to put them in response/reply.
 - the signature stuff is completely misleading. I believe there are two
   usage modes:
   * SCVP over HTTP/HTTPS where only raw requests/responses (i.e.,
     CVRequest/CVResponse/... in DER) are sent without any embedded
     signature or MAC.
   * SCVP over CMS where SignedData and AuthenticatedData can bind
     a signature or MAC to encapsulated requests/responses.
   All discussions about signature, for instance the signResponse stuff,
   are about the second mode only.
 - in the HTTP/HTTPS mode I can't see any benefit to validate more than
   one certificate per exchange. In order to keep SCVP simple we can add
   this as an implementation hint, can't we?
 - I'd like to use SCVP in order to handle certificate validation in
   IKE, including the new Hash and URL stuff of IKEv2. But this doesn't
   work with ESSCertID because it uses an optional IssuerSerial in place
   of the URL. I'd like to get an extended way to give a pointer to
   a certificate in addition to its SHA-1 hash.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 2004 12:16:14 +0200

Here are the ASN.1 bugs:
 - CertReference is an ambiguous CHOICE. In a previous version
   one tried to solve the ambiguity by changing the ACReference tags
   to 3 and 4 (I don't know if this is really allowed or recognized
   by compilers, of course it works but as I'd like to get the reference
   stuff a bit extended perhaps it is better to tag the CertReference itself).
 - responseStatus 50 is missing in 4.4
 - change the fullPolRequestUnsuported into fullPolResponseUnsuported in 4.4
   and 8
 - the cert field in CertReply is CertReference in 4.8 and ReplyCertificate
   in 8. I prefer the 8 (and previous draft) version because it is a
   simple way to enforce the return of the whole certificate. There are
   many ways to fix this:
   - just fix 8
   - same but add a want back to get the certificate itself (note that with
     IKE the certificate itself is useful only if the name validation
     algorithm doesn't work, and in the other case the public key is
     enough).
   - just fix 8 and adding in 4.8.1 that the whole certificate is mandatory
   - go back to previous draft, i.e., fix 4.8 and 4.8.1
   (note: I prefer the second solution (and get the validation algorithm
    error issue fixed!))
 - change the valAlg of CertReply (4.8 and 8) into validationAlg
 - fix the name of Pol{icies}Response in 5
 - add the i to validationPolices (to get validationPolicies) in 6 and
   add a subsection describing it between 6.5 and 6.6

Regards

---

From: "Faisal Maqsood" <[email-masked]>
Date: Wed, 11 Aug 2004 16:53:17 +0500

Hi,

Sorry for the long email but it is important.

Let's imagine of an SCVP client which puts three certificates in an SCVP
request message and in the reply it wants:
- only certification path(s) for the first certificate and
- only validated path for second certificate and
- only revocation status and OCSP/CRL used for third certificate.

I think to do this client has two options:

1. Client put all three certificates in Query of a single SCVP request
and for want backs client puts all his required OIDs.
2. Client generates three different SCVP requests with his requirement
as stated in above case.

If client uses method 1, it will make burden on SCVP Server (In this
case server has to collect all the information as stated by the want
backs OIDs for all the certificates)

If client uses method 2, it makes burden on Client (In this case the
client has to set different configs for each different request)

Note: This is just an example, there may be more complex use cases like
when involving ESSCertIDs, attribute certificates etc in the
combination.

Regarding this confusion/restriction in the protocol, I already sent an
email to the group list with subject "SCVP Structure Suggestions" but
may be subject was not good or what so ever, I did not get any response
of that email.

Now with this thread call, I again request to consider these cases
before new release.

>>>>> Relevant Suggestion Again >>>>>
In the CVRequest->Query one can specify Checks and WantBack.

I believe the Request ASNStructure should be similar to the strategy
used in the CVResponse->CertReply i.e CertChecks and WantBack should
also be present along with each certificate being validated in the
request message.

I would propose the following structure.

Query ::= SEQUENCE {
 QueriedCerts SEQUENCE SIZE (1..MAX) OF CertConfig,
 Checks     [0] CertChecks OPTIONAL,
 WantBack    [1] WantBack OPTIONAL,
 .....
    }

CertConfig::= SEQUENCE{
 Cert  CertReference,
 Checks      [0] CertChecks OPTIONAL,
 WantBack    [1] WantBack   OPTIONAL
}

Note: by placing CertChecks and WantBack according to above has
following benefits:

- User can define WantBack, CertChecks for each Certificate separately
providing greater flexibility. The CVResponse->CertReply ASN structure
already supports seperate WantBack, CertChecks for each Certificate.

-  WantBack, CertChecks inside CVRequest->Query ASN Structure should
remain to provide default settings but would be OPTIONAL. If in
CertConfig one does not provide WantBack and CertChecks then these
default values (CVRequest->Query->WantBack,
CVRequest->Query->CertChecks) MUST be present and used.

- Benefit of providing Checks and WantBack inside Query would be to
allow some or all of the Cert inside CertConfig to use default Checks +
WantBack settings thus reducing CVRequest size and thus reduces network
load.
<<<<<

Regards,
Faisal

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 05, 2004 05:06
Subject: SCVP: Speak now or forever hold your peace...

list
Let's
*last*.
document
issue

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 2004 13:48:54 +0200

Here are ASN.1 & co typos and suggestions: first letter of a field in
lower case, of a type in upper case, plural for [wW]antBack.
 - 3.2 title Query -> query
 - in 3.2: [wW]antBack -> [wW]antBacks, IsCA -> isCA,
   SignResponse -> signResponse
   missing "," after queryExtensions and producedAt (same in 8)
 - in 3.2.3, including the title, [wW]antBack -> [wW]antBacks
 - put 3.2.12 before 3.2.4 (to follow the field order)
 - in 3.2.12.2 KeyPurposedId -> keyPurposedId (in definition and text),
   ValidationNames -> validationNames
 - in 3.2.16 riType -> reType, riValue -> reValue
 - in 3.3 and 4.6 title Requestor -> requestor
 - in 4 id-ct-scvp-psResponse -> id-ct-scvp-certValResponse (twice)
 - in 4 and 8, missing "," after validationPolRef
 - in 4.5.2 text PSRequest -> CVRequest
 - in 4.8.5, including the title, [rR]eplyWantBack -> [rR]eplyWantBacks
   (note this is *not* a suggestion, cf 4.8 where are the plurals
    and there is a ReplyWantBack type too: caution!)
 - in 4.11 IsCA -> isCA
 - in 4.11 and 8 trustAnchors should be OPTIONAL (because in the second usage,
   PolResponse, there already is a trustAnchors field).
 - in 6 and in 6.2, including title, DefaultPolicyID -> defaultPolicyID
 - in 6.7 AuthPolRefBy{OID,URI} -> authPolRefBy{OID,URI}
 - in 8 (extra typos):
   * Query: valalidationAlg -> validationAlg
            keyusage -> keyUsage
 - in B application/scvp-{request,response} ->
        application/cv-{request,response}

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 2004 14:40:43 +0200

Here are editorial issues:

 - in 2 "request- response" -> "request-response"
  "validation request," -> "validation request."
 - in 3 SCVPRequest -> CVRequest (IMHO better than SCVP request)
   "request i.e." -> "request, i.e.,"
 - in 3.2 and in every places the fields are listed: update the
   list(s) in order to follow the current definition!
 - in 3.2.9 I am not sure that to use a BOOLEAN with a DEFAULT is
   a correct way to handle a field with 3 different possible values,
   i.e., can the DEFAULT override the "missing" value? BTW it works
   with OpenSSL but OpenSSL ASN.1 is not as standard as it should be.
 - in 3.2.9 the first sentence doesn't parse. IMHO there is an extra
   "certificate" word (last one).
 - in 3.2.10 I have two concerns:
   * the field should not be in query because it is about the response
     so the whole request. For instance what does happen formally when
     the field is set to different values in different queries of the
     same request.
   * not only DPD and DPV abbrevs must be expanded but I strongly suggest
     a reference to the RFC ([RQMTS])
 - in 3.3.12.1 "an valAlgId" -> "a valAlgId"
 - in 3.2.18 I suggest to contact the pki4ipsec WG where the EKU is
   an hot topic in order to know what id-kp to use (including none).
 - in 3.2.21 please specify what error to return (ReplyStatus 6?,
   in this case fix the error definition, i.e., add URI to OID).
 - in 3.6 and 4.13.2 I can't parse "PKIX-1.validation"
 - in 4 where is the certificate field in AuthenticatedData?
 - in 4.5 first paragraph: the hash doesn't cover encapsulated content
   and authenticated attributes, but only CVRequest. I suggest to remove
   the two statements refering to CMS.
 - in 4.8.4 we must explain the differences between Unknown and Unavailable
   or at least put the reference to the document where it is explained.
 - in 4.13 not ASCII betwen client and "s knowledge"
 - in 4.13 missing final "."
 - in 4.13.1 "a implementation" -> "an implementation"
 - in 5 and 6 please use either "Server" and "Validation" in titles.
 - in 6 polResponse -> PolResponse
 - in 6.8 "request i.e." -> "request, i.e.,",
   "requestors nonce" -> "requestor nonce" (or 's)
 - in 9 serverContextInformation -> serverContextInfo

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 2004 15:13:12 +0200

=> this is the first one so we don't need to tag it.

=> typos (I found then too).

   - If we know default values for 'requestRefHash' and tagged 0 to 5, why we
   are not making these as optional?

=> DEFAULT is similar to OPTIONAL, both are not always encoded according
to T-REC-X.680-200207 24.14 for instance.

   
   
       ACReference ::= CHOICE {
   
=> do you mean they should be 3 and 4?

=> we have the choice. We can begin by 123456 and put 999999 in the next.

   
   
=> same.

=> I missed this one.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 2004 15:36:57 +0200

=> this suggests to spread most of the Query fields to a per cert
structure... I agree, IMHO only requestRefHash and signResponse are
clearly per CVRequest.

=> IMHO multiple SCVP requests are better at one exception: when you'd
like to get the whole thing in one CMS message. In fact the real issue
is that ASN.1 has no reference, so can't handle easily sharing
(one can say this is another consequence of the incredible incompetence
of ASN.1 designers in computer science :-).

   Query ::= SEQUENCE {
   
   CertConfig::= SEQUENCE{
    Cert  CertReference,
   
=> you should get the .... to for CertConfig. I have a concern about
this: this gives two different ways to specify the parameters for
an unique cert.
   
IMHO the best option is just to accept one certificate per request.
It keeps SCVP so simple (:-)! Sharing of certificates (huge structures)
is already handled by references, we need only a way to share crls,
i.e., define our own RevocationInfo reference system?

Regards

---

From: "Faisal Maqsood" <[email-masked]>
Date: Wed, 11 Aug 2004 19:06:48 +0500

Well FD ,

please see comments below:

Regards,
Faisal

==============================

=> this is the first one so we don't need to tag it.
    [FM: what is logic that first one do not need to be tag?]

   - If we know default values for 'requestRefHash' and tagged 0 to 5, why
we
   are not making these as optional?

=> DEFAULT is similar to OPTIONAL, both are not always encoded according
to T-REC-X.680-200207 24.14 for instance.
    [FM: But DEFAULT is not same to OPTIONAL, so it will be better to
explicitly mention DEFAULT with OPTIONAL. Although tagged elements are by
default OPTIONAL]

       ACReference ::= CHOICE {

    [FM: Yes]

=> we have the choice. We can begin by 123456 and put 999999 in the next.
    [FM: Same goes for OPTIONAL? right, but it is better to follow some
standard way so that readers can feel comfortable that they have not skipped
or author has not skipped some thing]

=> same.

=> I missed this one.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 11 Aug 2004 16:16:43 +0200

- If we know default values for 'requestRefHash' and tagged 0 to 5, why
   we are not making these as optional?
   
   => DEFAULT is similar to OPTIONAL, both are not always encoded according
   to T-REC-X.680-200207 24.14 for instance.
       [FM: But DEFAULT is not same to OPTIONAL,

=> not but they are described together in X.680.

   so it will be better to explicitly mention DEFAULT with OPTIONAL.

=> I disagree and I don't understand, in the unlikely case it is legal (*),
what it means. (*) X.680 syntax excludes DEFAULT with OPTIONAL.

   Although tagged elements are by default OPTIONAL]

=> ??? I don't think the OPTIONAL keyword is optional!

   
=> this is really a matter of taste. IMHO the authors still stand well
between dictatorship and anarchy (:-).
   
Regards

---

From: Olivier Dubuisson <[email-masked]>
Date: Wed, 11 Aug 2004 16:54:14 +0200

>    to T-REC-X.680-200207 24.14 for instance.

24.14 deals with extension additions, but I think that your type has no 
extension marker.
The relevant subclauses are 24.10 and 24.11:
24.10	If OPTIONAL or DEFAULT are present, the corresponding value may be 
omitted from a value of the new type.
24.11	If DEFAULT occurs, the omission of a value for that type shall be 
exactly equivalent to the insertion of the value defined by "Value", 
which shall be a value notation for a value of the type defined by 
"Type" in the "NamedType" production sequence.

> => I disagree and I don't understand, in the unlikely case it is legal (*),

It is illegal to have both OPTIONAL and DEFAULT applied to the same 
component of a structured type.

> => ??? I don't think the OPTIONAL keyword is optional!

I didn't understand either what "tagged elements are by default 
OPTIONAL" means.
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/

---

From: "Faisal Maqsood" <[email-masked]>
Date: Wed, 11 Aug 2004 20:05:30 +0500

Well FD ,

Regards,
Faisal

----- Original Message -----
From: "Francis Dupont" <[email-masked]>
To: "Faisal Maqsood" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 11, 2004 18:36
Subject: Re: Speak now or forever hold your peace...

   Query ::= SEQUENCE {

   CertConfig::= SEQUENCE{
    Cert  CertReference,

[FM: No, By "....." I mean the remaining part of Query in draft 15 . Yes
this gives
two different ways, but let me explain how this helps:
    - Firstly for the case I mentioned above in my original email,
client
can use CertConfig optional elements i.e. checks & wantback to be
specified
for each certificate and not to use Query optional elements checks,
wantback.
    - Secondly for the case if client has multiple certificates and for
one
certificate he needs only certification path(s) while for all other
certificates client needs same other wantback, in this case client will
use
CertConfig optional elements checks, wantback only for first certificate
and
not for others but also client can use the Query optional elements
checks,
wantback to specify common wantback for other certificates (for which
client
has not used CertConfig optional elements).
By this way client has choice to control network trafic too.]

Regards

---

From: "Faisal Maqsood" <[email-masked]>
Date: Tue, 24 Aug 2004 16:37:52 +0500

Hi All,

I have two more things to concern for SCVP draft 15 as below:

1- According to SCVP draft 15, 'RequestReference' is not OPTIONAL in scvp
response structure.As by default 'requestRefHash' is TRUE in Query, if
server fails to calculate hash for any reason how can the server sends
'Internal Error' response back to client without 'RequestReference' when it
is set as mandatory ? Should 'RequestReference' not be OPTIONAL?

2- Section 6.2 describes PolicyID which seems to belong only to default
validation policy. If so, it should be an optional element in scvp response
because if client uses validation policy other than default, there is no
need to insert PolicyID in scvp response.

Regards,
Faisal

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 05, 2004 05:06
Subject: SCVP: Speak now or forever hold your peace...

list
Let's
*last*.
document
issue