RE: requirements comments.

Stephen

Thank you for the helpful comments that make a lot of sense.

A couple of responses:

1. Regarding the terminology for Key Name
- s/not required and not required/not required/ though I do like the
  emphasis:-)

This is trying to say two things: a) that the KeyName is not required, and
b) if it is used, it is not required that it be treated as a unique
identifier.

2. Section 2.1: Universality and Usability

- 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

Maybe we should get rid of this item, ("Privacy considerations should be
addressed"), since it is repeated in the next section titled Security
Model - 2.2.10 which mentions using P3P. Regardless, I agree.

==> maybe we should change the name from Security Model to Security
Considerations

3. I'd argue that we refer to SOAP rather than XMLP, for clarity, although
we can note the correspondence in the introduction. Has the SAML discussion
reached a verdict on SOAP versions?

4.(2.2.7) I agree removing the XTAML reference, simply saying
"The specification should support different means of establishing a trust
relationship with the trust service and should not be limited to client
caching of a trusted certificate or trusted key.

5.(2.2.8) Agree that we should not specify the need to specify unknown
optional mechanisms.

6 (2.2.11) - 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?
yes

7 Unfortunately the term key recovery sometimes has the governmental
implication, which we did not intend to imply.
"Key backup and retrieval" is probably a better phrase?

8 Regarding one or more key descriptions (sub-elements of KeyInfo), need to
figure out how to say it clearly.
- item 8: is "key attributes" right here? (possible confusion with XML
  attributes?), maybe "...types of <ds:KeyInfo>"

9 2.2.9 - 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/
Right.

10 (3.3.1) I believe the requirements should not preclude storing a private
key at the server and retrieving it. Perhaps we do not need to state
requirement 3.1.1 - I need to think about it.

11.(3.1.5) "More generally, the specification should allow asynchronous
transport of both registration and service responses, but not require this
of Trust servers. "
This is saying not only can registration be asyncrononous but also locates
and validates. I agree this is incorrect - I believe we agreed it should
only be applicable to registration, as in the wording you suggest.

12 (3.2.7) "Provide means to match requests and responses with server for
transaction histories. "
It should be possible to look at responses and demonstrate to a third party
that the correspond to the requests. I think we decided to include a hash of
each request in each response in discussions, but this is not captured in
this document. Should it be? (also useful for security concerns)

13. (3.3.3) Should key bindings have issuers associated with them? Is there
an argument against MUST?

14. (3.3.4) regarding KeyInfo X.509 support - the idea was to define minimum
X.509 interoperability support when X.509 is supported, but not require all
implementations to support X.509. I guess this needs discussion.

15. (3.4.2) Namespace aware means that we can do versioning using
namespaces, and allow extensions from different namespaces. (Technically it
also refers to xml parsers, but we can assume they are namespace aware at
this point)

Thanks

< Frederick

---
Frederick Hirsch
Zolera Systems, http://www.zolera.com/
Information Integrity, XML Security


> -----Original Message-----
> From: www-xkms-request@w3.org [mailto:www-xkms-request@w3.org]On Behalf
> Of Stephen Farrell
> Sent: Wednesday, January 16, 2002 11:28 AM
> To: www-xkms@w3.org
> Subject: 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

Received on Wednesday, 16 January 2002 14:33:37 UTC