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

RE: Comments on requirements draft

From: Frederick Hirsch <hirsch@zolera.com>
Date: Wed, 14 Nov 2001 15:42:35 -0500
To: "Blair Dillaway" <blaird@microsoft.com>, <www-xkms-ws@w3c.org>
Message-ID: <HNEILHLKDJAILJJBNELPEEIECHAA.hirsch@zolera.com>
Blair

Thanks for the helpful comments and suggested wordings. All your comments
make sense and I also agree with Sebastien's comments.

One general difficulty is to figure out which requirements to make explicit
which are implicit in the existing XKMS note, so if we are missing any more,
please let us know.

thanks

< Frederick

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


> -----Original Message-----
> From: www-xkms-ws-request@w3.org [mailto:www-xkms-ws-request@w3.org]On
> Behalf Of Blair Dillaway
> Sent: Wednesday, November 14, 2001 1:30 PM
> To: www-xkms-ws@w3c.org
> Subject: Comments on requirements draft
>
>
> I finally got around to reviewing the requirements draft.  My thanks to
> Frederick and Mike for their efforts.  Looks pretty good but I have a
> few issues/questions.  I'll try not to repeat editorial issues already
> posted
>
> 2.1.3 - This should be changed to indicate we'll provide a binding to
> SOAP 1.1 and will migrate to XML Protocol once defined.  This is
> consistent with language latter on in the spec.
>
> 2.1 - I'd like to add another item to this list stating the design will
> be transport protocol agnostic.
>
> 2.2.4 - Add a statement that we should describe how to roam key
> information as well as recover it.
>
> 2.4.1.1 - can we change first sentence to read "The specification must
> define a request for retrieving a public key, given a <ds:KeyInfo>
> element containing one or more key attributes."
>
> 2.5 - add a statement to the effect we are not defining generic
> mechanisms for securing SOAP/XML-Protocol consistent with our telecon
> discussion and Stephen's earlier comments.
>
> 3.2.1 - reword to make SOAP/XML-P relationship clear.  Something like -
> "Define payload and header XML formats, providing SOAP 1.1 bindings (or
> XML Protocol if specified  in time).  SOAP need not be the only binding
> defined, but it is required."
>
> 3.2.6.a.4 - Is the statement about "response values" is specifically
> targeted at the 'respond' parameter used to communicate which KeyInfo
> child elements should be returned?  If so, perhaps more explicit wording
> should be added.  If not, I don't know what this refers to.
>
> 3.3.4 I agree with Sebastien's comments in regards to X509Cert and
> X509Chain being required.  These should be recommended or optional.
> XKMS services should not be required to implement X509 support.
>
> 3.4.a.4 Why is "Exclusive Canonicalization" a parsing requirement?  It's
> a serialization technique, not what we generally mean by XML parsing.
> Also, the use is rather vague - "assertions".  Shouldn't we say
> something along the lines of we require its use when applying XML
> Signatures to insure robustness given the possibility of intermediate
> processors altering the SOAP envelope context.
>
> 3.4.b.1 - Can't we say something like "The specification should be
> compatible with use of authentication mechanisms carried in a
> SOAP/XML-Protocol message and/or the transport protocol".  XKMS doesn't
> actually define an authentication mechanism beyond the key POP.
>
> Also, a couple of things already in XKMS 1.1 should be added to 3.4.b
> 	- The specification should allow use of user-generated pass
> phrases as a means of proving ownership of a key(s) previously
> registered.
> 	- The specification should provide a means of employing a
> secret, arranged out-of-band, between the  registration service and
> end-user as a means of authorization a registration action.
>
> Blair
Received on Wednesday, 14 November 2001 15:42:19 EST

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