Conformance Keyword Audit

http://www.w3.org/2001/XKMS/Drafts/XKMS/xkms-issues-list#issue-18
>[Part I - 2002/08/01] [Part II - 2002/08/01] 
>The specification should have a sanity check performed against 
>the MAY/SHOULD/MUST requirements.

This email satisfies my action item for a conformance keyword audit of Part 
I. (I plan to wait till the next rev of version 2). The attached version of 
the specification contains the RFC2119 keywords highlighted. If 
capitalized, then it's a primary color; if lower case then of lesser 
saturation. The following colors and designations are used:

red - must/required
blue - should/recommended
green - may/optional

I then reviewed this marked up version with an eye towards ensuring that all 
CAP terms are approriate to defining a (sometimes testable) conformance 
profile for some agent. It appears we are specifying requirements over the 
following agents: client, KISS service, and KRSS service. (I don't see 
specific conformance requirements broken out for locate versus validate but 
maybe I missed it.)

There's a bunch of testable features for these agents, that we should make 
sure that are two interoperable implementations of:

ALL Actors:
- MUST(?) SOAP binding
- (?) SOAP Encoding?
- various security profiles (in Part II)
- 2.3.8.1 Result Codes: Are there any mandatory or optional behaviours 
associated with these codes?
- ValidityInterval and Status: I presume these are MUST for everyone to 
support, we will want good test cases for these to ensure the semantics are 
clear/shared.
- Client and Service authentication.

Service Features (query and registration):
- MUST: synchronous processing
- MAY: asynchronous processing
- SHOULD: opaque data.
- MAY: is it safe to say everything in the table of [51] is a MAY?}
(Registration only)
- MAY: Reissue and Revocation features.

Client Features
- XKMS Client MUST: synchronous processing
- XKMS Client MAY: asynchronous processing


[22] X-KISS allows a client to delegate part or all of the tasks required to 
process XML Signature <ds:KeyInfo> elements to a Trust service. 

BTW: It's probably best to replace instances of "XML Signature" with the 
actual bibliographic token?


[32] XKMS protocol messages share a common format that is carried in the 
body of a SOAP message. Implementations MAY support other encapsulation 
formats at their option.

SOAP supports multiple serialization/encodings, do we have a MUST associated 
with one of them? Is this part of this spec, or the binding? 
  http://www.w3.org/TR/SOAP/#_Toc478383512


[64] The following ResultMajor codes are defined:

The "must" in the table should probably be MUST.


[67] In the XML Signature Specification, a signer may optionally include 
information about his public signing key ("<ds:KeyInfo>") within the 
signature block. 

Redundant?


[91] For example a Locate Service MAY act as an aggregator of public key 
related information obtained from a variety of sources without performing 
any checks to determine whether specific information is current or 
establishing any formal trust policy. Such a service would correspond to 
the role of a directory in a traditional PKI. A Validate service MAY 
provide a service that validates key information presented to it but does 
not provide aggregation services.

I think I would lowercase these MAYs.


[202] X-KRSS specifies a mechanism for authenticating requests that is 
independent of any authentication mechanism provided by the message 
security binding. By its nature the X-KRSS protocol must support requests 
from parties who have yet to register their credentials or who have 
impaired credentials which are to be revoked.

I think this "must" should be MUST.


[275] The precise mechanism by which replay attacks are prevented is left to 
the implementation. For example generic mechanism built into the object 
exchange protocol if specified MAY be used.

Is a set of OPTIONAL algorithms for this specified?


[277] Freshness tokens MAY be encoded as XML Signature Properties.

More explaination of a "freshness" token would probably be useful.


[280] Depending on the implementation and application a key recovery 
operation MAY involve an unacceptable loss of confidence in the security of 
a private key component. This may lead to the possibility of repudiation of 
a signed document or of accountability in the case of an encrypted 
document.

The first may should be lower case.

-- 
*Note: I will be traveling and attending meetings Oct 2/3 in California; and 
Oct 5-15 in Australia. I will not be very responsive during this period; I 
will fully respond to any email as soon as possible after my return.

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/