RE: XKMS requirements - initial draft

Hi Stephen,

Thanks for your comments.  Replies below...

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Tuesday, November 13, 2001 10:04 AM
> To: www-xkms-ws@w3c.org
> Cc: hirsch@zolera.com; mike.just@entrust.com
> Subject: Re: XKMS requirements - initial draft
> 
> 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.
> 

The "security model" discussion seems like a good idea. This should be
sufficiently covered in the specification as well.  I agree with your last
statement and (as you indicate later) believe the spec should be giving some
more guidance as to how messages can be protected (both for reasons of
ensuring secure implementation, and for interoperability).

> 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.
> 

We were only considering the Trust Axiom Declaration and Delegation parts.
The other parts are there as support for these axioms I believe. I'll have
to read again to understand if there's much overlap with what we would want
XKMS to do.

> 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:-).
>    

Sounds good. This should probably be included in the specification as well
(not everyone will read the requirements doc).

> 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.
> 

As I mention above, I agree that this is important, both for supporting
interoperability and for ensuring secure implementation. The requirement
here might be stated as a requirement to profile different options for
securing XML key management messages.

> 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.
>   

This is similar to your point (5) above, and similarly, I agree.
 
> 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.
> 

We took this from the Workshop meeting minutes. I don't recall the intent
being very clear, hence neither is our interpretation. A "privcy
considerations" section is one solution and may be all that is necessary.
We'll try to make this clearer in the text. If anyone has any other
suggestions regarding privacy requirements, send them to the list.
   
> 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?
>    

I raised item 11 on the list already, but got no response :-(. My particular
example was that including "Multiple" with a <Respond> as part of an X-KRSS
request didn't seem to make sense, yet the current spec didn't give guidance
as to which responses were allowed for each request, and behaviour in case
others were used. There is certainly a more general issue here as well. As
another example, I don't think that it's entirely clear from the current
spec whether <Validate> includes <Locate> (e.g. can I submit a <Validate>
request and only supply <KeyName>?).

Regarding item 6 (correspondence of request and response), the client either
needs to maintain state and/or the specification needs to give more
guidance. For example suppose a user has an encryption certificate and they
use a <Validate> operation to validate this certificate. If the client has
no ASN.1 capabilities, then they cannot ensure that the response they
receive matches their request (unless guidance is given to request
<X509Cert> as part of <Respond>). Similarly, if I were to include <KeyName>
and <KeyValue> as part of <Validate>, but not within <Respond>, then I am
not able to ensure that the successful response I receive actually matches
my request. (Note that a transaction Id does not solve this problem.)

> 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.
> 

Sounds fine.

> 5. Section 2.4: Should this require that specification(s) 
> must define the "profile" of the messages that (in particular) 
> client must support?
>    

I'm not sure what you mean by this comment.

> 6. Section 2.5, item 11: The XTAML link in the references is 
> wrong, though the text is correct.
>    

Oops. Not sure how that happened. We'll fix it.

> 7. Section 3.1, item 3: possibly belongs more in section 3.2?
> 

Sounds right. It's not really talking about "trust" after all. 

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

I guess the second sentence is more like a design statement. It might be
fine to remove and keep the first sentence.
 
> 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.
>

X-Bulk does, but not X-KRSS (or other operations that receive a "Pending"
response), or were you suggesting that the X-Bulk message could be used in
all situations. (It seems pretty specific to bulk registration though.) I
had made this point on the list, with no responses :-(. This is similar to
issues raised with CMP regarding a Pending response.
 
> 10. Section 3.2, item 5: this is a security consdiration and 
> probably belongs in that section.
>    

Sounds ok. 

Thanks again for the comments.
Mike