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

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 10 Aug 2004 08:38:48 -0700

Hi Faisal,
Thanks for this.
Trevor

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Faisal Maqsood
* Sent: Tuesday, August 10, 2004 3:51 AM
* To: [email-masked]; [email-masked]
* Subject: Re: Speak now or forever hold your peace...
* 
* 
* Hi,
* 
* Below are my points on SCVP-15:
* 
* - In following structure why 'requestRefHash' is not tagged?[TF]
Fixed
* - Should 'IsCA' not be 'isCA'?[TF] already fixed
* - Should 'SignResponse' not be 'signResponse'?[TF]  already fixed
* - Should there not be commas in tags 13 and 14?[TF]  already fixed
* - 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.[TF]  fixed
* 
* 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'?[TF]  fixed
* 
*     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?[TF]  fixed
* 
*     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?[TF]  fixed
* 
*     RequestReference ::= CHOICE {
*       requestHash       [1] HashValue, -- hash of CVRequest
*       fullRequest       [2] CVRequest }
* 
* - In following structure should 'nextUpdate' tag not be start from 0
* instead 1?[TF]  fixed
* 
*     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[TF]  fixed
* 
*   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...
* 
* 
* >
* >
* >
* > 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: "Trevor Freeman" <[email-masked]>
Date: Wed, 11 Aug 2004 09:06:23 -0700

Hi Faisal,
Since requestRefHash has a default value, it can be omitted from the
encoding and therefore does not result in bits on the wire.

Trevor

* -----Original Message-----
* From: Faisal Maqsood [mailto:[email-masked]]
* Sent: Wednesday, August 11, 2004 3:06 AM
* To: Trevor Freeman; [email-masked]; [email-masked]
* Subject: Re: Speak now or forever hold your peace...
* 
* Hi Trevor,
* 
* Thanks for the reply. In your sentence what is meant by encoded ? I
think
* If
* you make this element optional then this will reduce the size of SCVP
* Request.
* 
* Regards,
* Faisal
* 
* ----- Original Message -----
* From: "Trevor Freeman" <[email-masked]>
* To: "Trevor Freeman" <[email-masked]>; "Faisal
Maqsood"
* <[email-masked]>; <[email-masked]>; <[email-masked]>
* Sent: Tuesday, August 10, 2004 21:49
* Subject: RE: Speak now or forever hold your peace...
* 
* 
* > Sorry, one correction to this. requestRefHash is already defaulted
so is
* > not encoded i.e. there are no bits on the wire to save so it can say
as
* > it is.
* >
* > Trevor
* >
* > * -----Original Message-----
* > * From: [email-masked]
* > [mailto:[email-masked]]
* > * On Behalf Of Trevor Freeman
* > * Sent: Tuesday, August 10, 2004 8:39 AM
* > * To: Faisal Maqsood; [email-masked]; [email-masked]
* > * Subject: RE: Speak now or forever hold your peace...
* > *
* > *
* > *
* > * Hi Faisal,
* > * Thanks for this.
* > * Trevor
* > *
* > * * -----Original Message-----
* > * * From: [email-masked]
* > * [mailto:[email-masked]]
* > * * On Behalf Of Faisal Maqsood
* > * * Sent: Tuesday, August 10, 2004 3:51 AM
* > * * To: [email-masked]; [email-masked]
* > * * Subject: Re: Speak now or forever hold your peace...
* > * *
* > * *
* > * * Hi,
* > * *
* > * * Below are my points on SCVP-15:
* > * *
* > * * - In following structure why 'requestRefHash' is not tagged?[TF]
* > * Fixed
* > * * - Should 'IsCA' not be 'isCA'?[TF] already fixed
* > * * - Should 'SignResponse' not be 'signResponse'?[TF]  already
fixed
* > * * - Should there not be commas in tags 13 and 14?[TF]  already
fixed
* > * * - 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.[TF]  fixed
* > * *
* > * * 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'?[TF]  fixed
* > * *
* > * *     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?[TF]  fixed
* > * *
* > * *     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?[TF]  fixed
* > * *
* > * *     RequestReference ::= CHOICE {
* > * *       requestHash       [1] HashValue, -- hash of CVRequest
* > * *       fullRequest       [2] CVRequest }
* > * *
* > * * - In following structure should 'nextUpdate' tag not be start
from 0
* > * * instead 1?[TF]  fixed
* > * *
* > * *     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[TF]  fixed
* > * *
* > * *   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...
* > * *
* > * *
* > * * >
* > * * >
* > * * >
* > * * > 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: Thu, 12 Aug 2004 13:45:48 +0500

Hi FD,

please see comments below:

Regards,
Faisal

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

In your previous mail you wrote:

   => you should get the .... to for CertConfig. I have a concern about
                              too
   this: this gives two different ways to specify the parameters for
   an unique cert.

   [FM: No, By "....." I mean the remaining part of Query in draft 15 .

=> I mean the same thing(s).

   Yes this gives two different ways, but let me explain how this helps:

=> I understand your idea but with per cert checks/wantbacks why not
per cert isCA flag, etc.
[FM:
As I have already written that my puposed structure will come out
with new things. But as in current SCVP structure there are elements
provided only to facilitate the client to make single request/response in a
single file so that client can make his archives in a better way according
to their needs i.e. Refering to 3.2.5. To consider such elements the
purposed structure can benefit
the clients and it also saves time of client to make different requests and
also communication time will be reduced.
In addition you may see similar problem with TrustAnchors if client puts
three certificates in QueriedCerts and four certificates in TrustAnchors...
will it not make burden on server in DPD? Ofcourse it will.
You may imagine the real time requests/responses of more number of
QueriedCerts and TrustAnchors, so I am not happy with the existing structure
but it is all upto ASN.1 designers to consider such more serious things
present in existing structure.]

   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?

=> I put this again because it is a good summary of my opinion.

Regards

[email-masked]

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 13 Aug 2004 10:46:57 +0200 (MEST)

Good news. 
I stand corrected.
Thanks for the information. 
Peter

> -----
> There are **MANY** ASN.1 specs that have tags in excess of 30.
> I know of no commercial-grade ASN.1 toolkit, nor any of the
> popular free ones, that suffers from such a deficiency.
> 
> In the early 1990's the implementor's organization in Europe, the U.S.A
> (NIST Stable Implementation Guideline) and Asia agreed that ASN.1 specs
> should not use tag numbers greater than 16383, and implicitly, that tools
> should support tags of at least that size.  To the best of my knowledge
> all commercial-grade and popular free ASN.1 toolkits support tags this
> large.
> -----
> 
> Olivier
>

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 13 Aug 2004 14:21:18 +0200 (MEST)

3.3 Requestor 
   
  The requestor item MUST be an octet string.  

What is the reason for this statement. It is defined as an ASN1
octet string. So there is no other choice.

                                              No provisions are made 
  to ensure uniqueness of the requestor octet string; however, all of 
  the octets MUST have values other than zero.

This is inconsistent of what is specified in relaying
where zeros are allowed. 

7 SCVP Server Relay 

... 
 
  When an SVCP server receives a request that contains a requestor 
  item, the server MUST check for its own identifier.  The identifier 
  could be located at the beginning of the octet string followed by a 
  zero octet, or it could be located between two zero octets.

With thgis logic a server cannot detect immediately a loop to itself
of a request relayed to it by another server.

I strongly suggest again to replace this handling by using a sequence
of octet strings at least for the second request instaed of this
null logic.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 13 Aug 2004 14:11:56 +0200 (MEST)

Paragraph 3.2.17 does not seem clear enough to me. It
does not indicate how the server performs the matching
between the provided keyusage bit string and the
bitstring in the candidate certificate. 

It should be clarified whetyher this is a conparison
for identity or whether it is tested that all 1 bits
in the client provided string are also 1 in the
cert. 

Isn't there a ',' missing behind 'Therefore'.

in a context of a digital signature, the nonrepudiation
bit alone can be used as far as I remember. 

How can one ask for either keyEncipherment or keyAgreement
in the case of a serverAuth or an email cert.

---

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 17 Aug 2004 16:31:19 -0700

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Peter Sylvester
* Sent: Friday, August 13, 2004 5:12 AM
* To: [email-masked]
* Subject: Re: Speak now or forever hold your peace...
* 
* 
* 
* Paragraph 3.2.17 does not seem clear enough to me. It
* does not indicate how the server performs the matching
* between the provided keyusage bit string and the
* bitstring in the candidate certificate.
* 
* It should be clarified whetyher this is a conparison
* for identity or whether it is tested that all 1 bits
* in the client provided string are also 1 in the
* cert.[TF]  Already Fixed
* 
* Isn't there a ',' missing behind 'Therefore'.[TF]  fixed
* 
* in a context of a digital signature, the nonrepudiation
* bit alone can be used as far as I remember.[TF]  Fixed
* 
* 
* How can one ask for either keyEncipherment or keyAgreement
* in the case of a serverAuth or an email cert.[TF]  fixed

---

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 24 Aug 2004 09:19:57 -0700

* -----Original Message-----
* From: [email-masked]
[mailto:[email-masked]]
* On Behalf Of Faisal Maqsood
* Sent: Tuesday, August 24, 2004 4:38 AM
* To: [email-masked]; [email-masked]
* Subject: Re: Speak now or forever hold your peace...
* 
* 
* 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?
[TF] this is already fixed in 16
* 
* 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.
[TF] If the client uses a validation policy other that default which
does not define every parameter, and the client also omits the missing
values in the request, the default values are used for whatever is
missing therefore the policy ID potentially applies to any 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...
* 
* 
* >
* >
* >
* > 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
* >