Re: Part 2 spec updated - need feedback

Hi Shivaram,

Thanks for your modifications. I am finally starting to understand these
tables! I just have a minor comment for the TLS bindings (Good work), but some
more for the payload security ones.

See my in-line comments. I hope this helps!

-jose

On Thu, Apr 07, 2005 at 06:52:33PM -0700, Shivaram Mysore wrote:
> 
> Shivaram: April 07th Draft
>    Issue 328-jk: Updated table para [71b]

I think that we're not really talking about MessageDigests, but
about Message Authentication Codes. A message digest can be duplicated
by anyone, but a MAC requires knowing something secret. If you agree
with this, the last paragraph on [32] also needs to be updated.

I would put a note before 71b saying "In the following table,
Request/Signature means that an XKMS Request element includes an
dsig:Signature element in enveloped mode. This signature is calculated
using a digital signature method. Request/MAC has a similar meaning,
except that the signature is computed using a Message Authentication
code.

I think that it would really be useful to have a description
of what is meaning of "payload" security in this context. For example,
is this payload the content of an XKMS request (or response) or is it 
the XKMS request/response itself when being vehiculed by another protocol, 
e.g., HTTP, or Soap? I think that it means "what mechanism is 
included in the payload so that it is protected regardless  of 
the transport mechanism" and so we are talking about what features
XKMS has that provide for payload security.

Let's suppose that "payload security" means what I supposed here above.

In [71b], instead of calling column two "Client Authentication Mode" I
would just clal it "Authentication Mode" and add "client" or "server" or
"mutual" or "none" in the cells below it. When using a MAC (see below),
you could use "shared secret" in the cell entry under this column.

It's not clear to me why Request/MessageDigest (which I proposed
to change to Request/MAC) is associated to Request/Response
Correspondence. It authenticates the entities that share the secret
used to compute the MAC and it authenticates the contents itself.
It would satisfy the client/response correspondance if the secret
was based in a nonce that changed after each transaction. I don't think
that part-1 defines this (at least I didn't find it).

For the correspondance, I would alternatively suggest "shared secret"
for the "Authentication Mode" and put RequestID together with Request/MAC
and Response MAC. The entry right below is ok.

Request/ResponseWith=Represent ouf... How about "two phase protocol"
instead and replacing XKMS element by XKMS feature in this table?

>>Proposing [72a] as a replacement for para [72] for better 
>> clarification of the text - need feedback

Last row mentions Request/MessageDigest, but MessageDigest is not defined
in the schema. What does the "/" mean here, where all the other elements
in this column use "." ? If you use my definition above Request/MAC, then
this makes sense. Otherwise, it's a typo.

-----------------------------------------

>    Proposing [75a] as a replacement for para [75] for better clarification of the text - need feedback


For Table [74a] Certificate baed authentication isn't an XKMS element,
is it?


> [1] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-DRAFT/PR-DRAFT-xkms-part-2.html