requirements comments.

Since I was asking for folks to send their comments on the 
requirements draft by today, I felt I should send mine:-)

If you can, please try to send yours today or tomorrow so
that we can see what to have on the agenda for next week's
conference call and have a chance to discuss things on the
list prior to the call,

Regards,
Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

XKMS requirements

General

- Suggest changing to MUST/SHOULD/MAY ala rfc 2119, i.e. capitalize
  all normative must/should/may and leave non-normative ones lower
  case
- Should there be a mention of being consistent/compatible with SAML?
- Key recovery: I think we're only in the business of defining how 
  a user can recover her own key and don't (say) have to define how
  two administrators can recover my key for law enforcement purposes.
  Am I right here? (Comments below assume that I am, strangely enough:-)
- There should be an explicit requirement or goal stated that the data 
  formats etc. that the trust service uses internally must not "leak"
  over the xkms protocol, at least if you're not using some private
  extension.
- Should we require that the specification define how to use a 4-cornered
  approach at this stage (could be in a separate document, like xbulk).
  I argue that we should (I think).
  
Specific

Abstract: "external requirements" sounds wrong, suggest deleting the phrase

Status: "http://www.w3.org/TR/" as the source of drafts. This (and other
xkms drafts) aren't there. I'm checking if this is the right URL, but I
guess the WG overview page is the alternative.

Introduction: Still not quite clear that we're not doing symmetric key
management. Suggest changing opening to "XML-based public key management 
should be designed...", also "...to support the public key management
requirements of..."

Terminology: Should this be section "1.1" or just part of "1" or "2" (I 
at least don't know how to fix the numbering, but I guess it should be 
done.)

Asynchronous exchange: 
- s/require a/requires a/
- Nice to add an example, say "...is incomplete, e.g. when processing a 
  registration requires time consuming checks,..."
- "response status of "Pending"" should be an example in case there's
  some other way to do it
- Should we define asynchronous exchange so that in addition to indicating
  a pending status, the response should/must include an indicator as to
  how the complete response can be received (e.g. a check-back URL)?

Deferred authentication:
- Maybe this would be better termed "Deferred request authentication" since
  e.g. one of the CMP PoP schemes gives out an encrypted certificate so that 
  only the holder of the right private key can send a confirm message. That
  CMP example could also be a type of deferred authentication, but is 
  different from what's meant here.
  
Key Validation:
- Maybe a mine-field, in which case ignore this, but would suggest that the
  1st sentence be replaced with "A service that verifies the binding of
  information to a public key, and also determines the current status
  of that binding, if appropriate/possible for the information in question."
  
KeyBinding:
- Change to "Key Binding" (two words) here since we're not in schema-land
  yet
- s/additional elements/additional information/ since there might (in
  principle at least) be XML attributes in there too
  
KeyName:
- s/KeyName/Key Name/
- s/not required and not required/not required/ though I do like the 
  emphasis:-)

Pass Phrase:
- Should the term used really be "Pass Phrase Key"?
- s/may be provided/may be used/

Proof of Possession:
- Capatalize "possession" 
- s/POP/PoP/ is more usual
- s/ownership/possession/

Section 2.1: Universality and Usability

- item 4: There was an issue with which SOAP version to use on the SAML list
  today, we should check that out and hopefully come to the same conclusion
- item 7: Suggest adding "prefereably through the use of an external 
  specification" to give the hint that we don't want to spend out lives
  considering privacy
- item 9: s/for a each/for each/
- item 12: Is defined a bit strong here? Maybe "allowed" or say that the
  capability must be demonstrated - don't want to have to include every
  legacy format that someone finds, which could be argued from the current
  wording

Section 2.2: Security model:

- There's a bit of repetition in this section, needs some editorial work.

- item 0: First sentence should have a number, right? Suggest changing 
  this to:" The specificaiton must specify how to secure messages for
  confidentiality, data integrity and data origin authentication, though
  use of these mechanisms must not be mandatory at the message level, e.g.
  confidentiality and origin authentication may be provided via a secure
  transport mechanism like TLS."
- item 1: s/trust responder/trust service/ since the latter is the defined
  term; need to define "payload security"; s/SSL/TLS/ 
- item 2: not sure what's meant, but I would understand s/taken/used/ 
- item 3: refers both to SOAP and XMLP - should use one; maybe it should
  be s/body content/body/; also s/used/usable/
- item 5: delete "interoperable" since TLS already is, right:-) Also suggest
  adding "e.g. by only requiring a subset of the mandatory ciphersuites be
  supported" to explain why a profile of TLS is useful
- item 7: since I (at least) don't know how XTAML might be used, suggest 
  deleting that (no harm since there's already the certificate example which
  makes the point)
- item 8: s/using either/using for example/ and some wording glitches need
  fixing (e.g. s/in security section/in a security considerations section/);
  I'd rather we deleted the last sentence since I don't like "optional" 
  things and I'd always like to (at least try) have replay protection.
- item 9: s/an XML key management standard/the specification/
- item 11: I don't understand this one but I think you mean "trust services
  must make their public keying information (i.e. public keys to be used to 
  authenticate the trust service), publically available in at least the
  <ds:KeyValue> format, since that it the minimal [XMLDSIG] key 
  representation" or words to that effect?
- item 12: s/must always/must/

Section 2.3: protocol design

- item 2: the defined term is "key binding" so s/public key assertion/key
  binding/
- item 3: s/the update to/update/
- item 4: need to make it clear that we're only thinking about a user 
  recovering their own key and not, e.g., two administrators recovering
  my key for law enforcement purposes, so suggest adding "...so that a user
  may recover their own key. Note: the specification shall not define
  how e.g. administrators can recover the keys of users which is out of
  scope of the current work."
- items 5,6,7: Suggest adding to each: "...but must not make this mandatory
  to support for "typical" clients" since we do want to separate out the more 
  complex (e.g. bulk) cases
- item 8: is "key attributes" right here? (possible confusion with XML
  attributes?), maybe "...types of <ds:KeyInfo>"
- item 9: make it clear that this only refers to the protocol, since we're
  not defining what happens inside a responder in this case, right? maybe
  s/how to/define protocol that allows/
- item 10: should "4-corner" be a defined term? I think so, but don't have
  text right now.

Section 2.4: Out of scope

- items 4&15: if the general comment about 4-corners is adopted then these
  might need modification, I've no text at the moment
- item 13: well, I'd like it to be possible to use xkms (esp locate) 
  anonymously - shouldn't we allow that? OTOH, I wouldn't like to spend
  too much time on it either, so how about adding at the end "...are not
  a primary focus of the work, though may be supported"

Section 3 overall:

- Maybe make it clear that you're expected to be familiar with the
  XKMS W3C Note before reading this part?

Section 3.1: Trust server

- item 1: seems to conflict with item 2.4.14, where we rule out roaming
  for now, suggest deleting this one 'till we add back roaming
- item 3: suggest s/selection of services/selection of differently 
  configured trust services/
- item 5: "both registration and services responses" - should that be
  "both registration requests and responses"? If not, I don't understand

Section 3.2: Payload and protocol definition

- item 7: I don't understand this one.
- item 8: "number of responses" seems wrong, maybe "number of key bindings
  in a response" is what's really meant?
- item 12: s/assertions/key bindings/

Section 3.3: Objects

- item 3: is it may or must? I'd go for must. (and s/assertion/key binding/)
- item 4: the X.509 part seems to be defining some sort of conformance 
  classes - is this right or should we either make X.509 a must or a may? Also,
  I don't understand the last sentence, but think it should probably be a 
  separate item?
  
Section 3.4: Processing

- item 2: what does "namespace aware" really mean? I've no idea at any rate;-)
- item 5: s/define an authentication mechanism/define any new authentication
  mechanism/
- item 7: just trails off...I guess it should end with "...key binding."
- item 8: s/arranged/agreed/ would be more common usage

Section 4: Co-ordination

- Doesn't co-ordination have a hyphen?
- Rephrase 1st sentence. Maybe "The specification should aim to be consistent
  with the following external specifications/groups:..."