W3C home > Mailing lists > Public > www-xkms-ws@w3.org > November 2001

Re: XKMS requirements - initial draft

From: Stephen Farrell <stephen.farrell@baltimore.ie>
Date: Tue, 13 Nov 2001 15:04:23 +0000
Message-ID: <3BF13677.4E2E524C@baltimore.ie>
To: www-xkms-ws@w3c.org
CC: hirsch@zolera.com, mike.just@entrust.com

Mike, Frederick,

Once again, I think you guys did a great job getting this together
so quickly. I've gone through the document and have the following
general comments:

1. I think a "security model" should be specifically described. Basically,
   xkms clients can "trust" xkms responders in various ways (e.g. a client 
   should regard a server that it just uses for locates differently from
   one it uses for validates). We should call out the various possibilities
   and map those to ways to protect xkms transactions (e.g. running over
   TLS, signing xkms messages etc.). Personally, I don't believe that it
   should be required that all xkms messages are, e.g. signed, but that's
   something to discuss.

2. (Following on from the above.) I'd like to see some dicsussion as to 
   whether *all* of the functionality included in XTAML is really out of 
   scope, as is indicated in section 5. I imagine a case can be made that 
   we need to provide at least a basic security model when xkms messages 
   are signed, without reference to another specification like XTAML.

3. Symmetric key management is mentioned at the start, but isn't really
   discussed later on. I'd suggest punting on this, perhaps by indicating
   an intention rather than specifying requirements. (Not too different 
   from what's there now.) However, is this ok for the XML encryption folks 
   or is there an expectation that xkms will be usable for symmetric key 
   management (e.g. equivalent to kerberos)?
   
4. Terminology. We could probably use a terminology section - terms like
   "trust service", "client", "assertion" are used in various places and
   probably should be defined (so long as we don't spend too long doing 
   that:-).
   
5. Relationship to SOAP/XML protocol security. My belief is that xkms 
   will be easier to finish, implement and more efficient if we define,
   in the xkms specification(s), how xkms transactions are secured, rather 
   than assume that generic XML protocol security mechanisms are used 
   to secure xkms. If we have concensus on this then I think we should
   call this out specifically, so that the other folks don't get the 
   wrong impression.

And here are a few more-specific nits that occured to me while reading
the document:

1. Section 2.1, "Universality & Usability", items 4 & 5 say that we must
   specify how to use xml encryption and signature on xkms messages, (I
   agree we must do that), but should the requirements document not rather
   state that the specification(s) must specify how to secure xkms 
   transactions. For example, use of TLS (IMHO) shouldn't be ignored.
   
2. Same list, item 7: Does this mean that xkms specificaiton(s) must include
   a "privacy considerations" section? There's a mention of p3p later on, but
   I didn't follow what was intended.
   
3. Same list, items 6 & 11: are these calling for the specification(s) to 
   include a state machine for clients? Might be a good idea (probably 
   always is for protocol specifications) - is there any existing w3c 
   stuff to copy?
   
4. Section 2.3 (and elsewhere) should probably refer to "specification(s)" to
   make clear that we're not talking about a single (eventual) 
   recommendation.

5. Section 2.4: Should this require that specification(s) must define the 
   "profile" of the messages that (in particular) client must support?
   
6. Section 2.5, item 11: The XTAML link in the references is wrong, though
   the text is correct.
   
7. Section 3.1, item 3: possibly belongs more in section 3.2?

8. Same list, item 4: is this more design than requirements language?

9. Same list, item 5: I'd say that the requirement is more to support 
   asynchronous registration - the current text suggests a way to do that.

10. Section 3.2, item 5: this is a security consdiration and probably belongs
   in that section.
   
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 Tuesday, 13 November 2001 10:04:23 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 13:51:41 EDT