Subject: FW: SCVP 16 comments

From: "Trevor Freeman" <[email-masked]>
Date: Tue, 8 Feb 2005 11:41:54 -0800

* -----Original Message-----
* From: Trevor Freeman
* Sent: Tuesday, February 08, 2005 11:36 AM
* To: 'Wen-Cheng Wang'
* Subject: RE: SCVP 16 comments
* 
* 
* Hi Wen-Cheng,
* Thanks for these comments. SCVP 17 should be shortly posted
* See below for answers
* Trevor
* * -----Original Message-----
* * From: Wen-Cheng Wang [mailto:[email-masked]]
* * Sent: Thursday, December 23, 2004 7:40 PM
* * To: Trevor Freeman
* * Subject: Fw: SCVP 16 comments
* *
* * Trevor,
* *
* * I would like to remind you that you have not yet responded
* * to my comments on SCVP ID 16.
* *
* * Wen-Cheng Wang
* *
* * ----- Original Message -----
* * From: "Wen-Cheng Wang" <[email-masked]>
* * To: <[email-masked]>
* * Sent: Thursday, December 16, 2004 1:13 AM
* * Subject: SCVP 16 comments
* *
* *
* * >
* * > 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."
* [TF] Fixed
* * >
* * > 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."
* [TF] Fixed
* * >
* * > 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
* [TF] the following OID are already defined
* id-stc-build-pkc-path: Build a certification path to a trust anchor;
* id-stc-build-status-checked-aa-path: Build a validated certification
path
* to a trust anchor for the AC issuer and perform
* * >
* * > 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"
* [TF] Fixed
* * >
* * > 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."
* [TF] Fixed
* * >
* * > 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
* [TF] Fixed
* * >
* * > 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."
* [TF] Fixed
* * >
* * > 8. Page 64:
* * >
* * > In the last paragraph of page 64:
* * >
* * > "serverContextInformation" should be "serverContextInfo".
* [TF] Fixed
* * >
* * >
* * > Wen-Cheng Wang
* * >