SCVP 16 comments

["Wen-Cheng Wang" <wcwang@xxxxxxxxxx>]

Here are my comments on SCVP ID 16.

1. Page 11:

The responseRefHash, responseValidationPolByRef, and
signResponse items are now grouped into the the
responseFlags item. 

Therefore, the sentence:

" A query 
  MUST contain a sequence of one or more queriedCerts items as well 
  as one checks, one wantBack and one validationPolicy item; and a 
  query MAY also contain responseRefHash, responseValidationPolByRef, 
  signResponse, serverContextInfo, validationTime, intermediateCerts, 
  revInfos, producedAt, and queryExtensions items."

should be changed to:

" A query 
  MUST contain a sequence of one or more queriedCerts items as well 
  as one checks, one wantBack and one validationPolicy item; and a 
  query MAY also contain responseFlags, serverContextInfo,
  validationTime, intermediateCerts, revInfos, producedAt, and
  queryExtensions items."

2. Page 12:

For the same reason, the sentence:

" The requestRefHash, responseValidationPolByRef 
  and signResponse items allow the client to request optional 
  features for the response."

should be changed to:

" The responseFlags item allows the client to request optional 
  features for the response."

3. Page 13:

When a client want to build/validate/do revocation check on the
certification path for the AC issuer, it is not clear that whether
the reference to the AC itself or the AC issuer's PKC need to be
send to the server?

Also, there are no OIDs defined for

  - Build a certification path to a trust anchor;
  - Build a certification path to a trust anchor for the AC 
    issuer

And I think the following statement is not correct.

  "Also, building a validated certification path does 
   not imply revocation status checks."

If the server does not perform revocation status checks,
how does it know the certification path is valid or not?

4. Page 17:
The following paragraph should not appear in section 3.1.4.1:

" SCVP servers SHOULD support serverContextInfo.  SCVP clients MAY 
  support serverContextInfo"

5. Page 18:

The following paragraph should be moved to section 3.1.4.1:

" Neither the clients nor server MUST dereference the URI during SCVP 
  request processing.  The URI is simply used as a reference for the 
  validation policy.  Clients and server MAY dereference the URI as 
  part of configuration."

6. Page 19, 20, 21, 22:
OID names are not consistent. The following substutions are
recommended:

id-bvae-notYetValid -> id-bvae-not-yet-valid

id-bvae-wrong-Anchor -> id-bvae-wrong-anchor

id-bvae-invalid-Key-Usage -> id-bvae-invalid-key-usage

id-bvae-invalid-Purpose -> id-bvae-invalid-purpose

id-bvae-invalid-Policy -> id-bvae-invalid-cert-policy

id-bvae-invalid-Name -> id-bvae-invalid-name

id-bvae-invalid-Entity -> id-bvae-invalid-entity

id-bvae-invalid-Depth -> id-bvae-invalid-path-length

id-bvae-invalidPurpose -> id-bvae-invalid-purpose

id-bvae-invalidCertPolicy -> id-bvae-invalid-cert-policy

id-bvae-invalidName -> id-bvae-invalid-name

id-bvae-invalidEntity -> id-bvae-invalid-entity

id-bvae-invalidPathDepth -> id-bvae-invalid-path-length

id-nvae-unknown-pupose -> id-nvae-unknown-purpose

id-nvae-nameMismatch -> id-nvae-name-mismatch

id-nvae-noCertName -> id-nvae-no-name

id-nvae-unknownPupose -> id-nvae-unknown-purpose

id-nvae-badName -> id-nvae-bad-name

id-nvae-badNameType -> id-nvae-bad-name-type

id-nvae-mixedNames -> id-nvae-mixed-names

7. Page 22:

The following paragraph should not appear in section 3.1.5.2.4:

" The userPolicySet item specifies a list of policy identifiers that 
  the SCVP server MUST use when forming and validating a certificate 
  If certPolicies is not specified, then any-policy MUST be used."

8. Page 64:

In the last paragraph of page 64:

"serverContextInformation" should be "serverContextInfo".


Wen-Cheng Wang