W3C home > Mailing lists > Public > www-xkms@w3.org > September 2002

Requirements Validation

From: Frederick Hirsch <hirsch@fjhirsch.com>
Date: Wed, 25 Sep 2002 21:28:21 -0400
Message-ID: <3D9262B5.4020201@fjhirsch.com>
To: www-xkms@w3.org, hirsch@fjhirsch.com

This message is intended to address action item #17 from F2F3 (to 
validate the draft against the requirements) at this stage in the process.


17 Clarification/
[ Sept 2002 F2F] [Part I - 2002/08/01] [Part II - 2002/08/01]
The specification should be validated against the requirements [XKMS 
Requirements]. Ensure that this validation is performed prior to moving 
through Working Group Last Call. [ Sept 2002 F2F].

The correct version of the requirements to work against is the May 23, 
2002 draft 1.38 at http://www.w3.org/2001/XKMS/Drafts/xkms-req.html 
which is different that the version linked against in the issues list. 
These comments refer to that version of the requirements.

Requirements against applications or clients cannot be addressed by the 
specification, rather requirements against the specification. Reviewing 
the requirements against the editors spec, I have the following list of 
needed changes and/or questions:

2.1.3 The requirement to justify optional features isn't met explicitly
"Use of optional features is discouraged. Use of unbounded XML element 
schema definitions and optional elements SHOULD be justified in the 

2.1.4 - A SOAP binding is required, including a statement that document 
encoding is used. (TBD in Part 2 now)

2.1.5 Wording is needed to clarify that XKMS is transport protocol 
agnostic - in [32].

2.1.12 should this requirement for the definition of pkcs#10 and #7 
support be removed given issue item #57 resolution - "remove pkcs#10 

2.1.3 Without a definition of "minimal overhead" this requirement cannot 
be tested. Do we agree that the specification meets this "guideline"?

2.2.3 TLS profile is required  (TBS in part 2). Need to specify 
acceptable cipher suites.

2.2.6 Replay protection is described in general [274], specifically for 
a nonce [41].  Should the specification give guidance for the other 
techniques, such as whether Id is intended to serve as a serial #,  and 
regarding use of origination time? Probably not necessary.

2.2.8 Does the specification need a discussion of establishing a trust 
relationship with the server to meet this requirement? I think so.

2.2.11 Need to state in security section of part 1 that server privacy 
policies may be addressed by server P3P support.

2.2.12 Part 1 security section should mention plain-text and data length 
vulnerabilities and how they might be addressed (or is this more 
appropriate in a payload confidentiality discussion in part 2?)

2.4.5 Bulk registration is being moved into the main specification - 
issues list #22.

2.4.6 Specification of how to request updated  status of a multi-key 
registration should be addressed in the bulk specification when added 
(issues item #22)

2.4.10 Specification needs to define how a client can determine the 
validation context, such as the certificate policy in use. I believe 
this is bound to the chosen URI for the service - is this clear in the 
specification? Suggest adding a sentence to [100] stating that the 
policy is associated with the service URI used by the client.

2.4.16 The specification MUST define which requests are idempotent (can 
repeat without ill effect) and which are not. Does the spec make this 
clear (registration is not, revocation and reissue is not, location and 
validation are, etc?)

2.5.4  X509Chain is required to be defined in the specification. The 
specification defines it as 1 or more ds:X509Data elements. Should it 
define the order (from root down or is this unnecessary?) Is a schema 
definition necessary?
Is OCSP well enough defined (appears so)

2.5.5 Use of exclusive canonicalization is not specified. Should it be, 
or is this an application requirement when needed (presume the latter).

Other major issues such as use of schema and extensible 
requests/responses namespace versioning , clarity of error responses 
are met.

I also noticed a potential typo:

Should "PassPhraseAuthentication" in the text in [214] be 
"NotBoundAuthentication" to match the schema?

< Frederick

Frederick Hirsch
Received on Wednesday, 25 September 2002 21:27:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:39 UTC