RE: XKMS requirements - initial draft

Stephen

Thank you for going through the document in detail and providing specific
comments.

I agree with creating a separate security model section. We can include the
XML signature and encryption requirements, as well as issues of establishing
trust or using SSL/TLS for session security in this section. I believe XML
digital signature and XML encryption allow signing and encryption to be part
of the responses (e.g. a signed assertion) which is somewhat different from
protocol transport integrity offered by SSL/TLS. I expect we will want both
for different purposes. I agree this needs clarification.

The reason for mentioning symmetric keys was that KeyInfo can be used to
refer to a symmetric key for XML encryption and an application might not
want or be able to make a distinction. It may just want the KeyInfo to be
processed. It is a bit of a reach, but making the XKMS scope for purely
public key may constrain XKMS unnecessarily.

I think privacy is an important concern to people - it could be its own
section or part of a general security section (more likely).  Initially the
ability to request and obtain a privacy statement from the trust server
(hence the p3p) is probably good enough to address privacy issues, at least
that is what I heard at the face to face.

The detailed capability of requesting a privacy policy could also be put in
the general category of Trust Server "Introspection", or the ability to
query the server about its own capabilities (e.g. which tiers of service are
supported, what is the privacy policy, what are the security policies, how
to get support etc)

The point on matching requests and responses is to allow definitive matching
of requests and responses to enable clear evidence trails (as well as to
avoid confusion in asynchronous communications)

I'm not sure we should say much about the requirements on a client - other
than they should not require standard PKI processing capabilities. I think
the focus should be on the wire protocol and on server functionality.

Thanks for the detailed nits which should make it into the next edit pass.

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


> -----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.
>
> 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 14:18:39 UTC