RE: Again, confusing 8.1

Jose wrote: "From what I understand, the pass-phrase is never sent on the
clear. We're only sending the base-64 of a MAC computation.  So that should
be valid XML." 

No, a base64 string is NOT valid XML.  That's why having the statement in
section 8.1 that "All shared string values are encoded as XML" is confusing.
base64 is not XML, it is base64 (eg.
http://w3.org/TR/xmlschema-2/#base64Binary).

It seems to me, based on my inadequate knowledge as someone not
participating in the technical interop, that specifying the means of
converting a human language pass phrase into base64 may be extraneous to the
XKMS spec.  (If the experience of actual implementors disagrees, let me
know.)  For me, the XKMS spec just has to say that the shared secret data,
wherever it came from, must be base64-encoded when appearing in an XKMS
message.  Then it does not matter if the pass phrase was human language
text, a (tiny) image bitmap, or whatever.

If we do need to specify rules of pre-base64-encoded human language pass
phrase, then we should certainly NOT mandate that it must be valid XML (eg.
with start and end tags) unless someone has a good reason for doing so.

Ed
========================================
Ed Simon
(613) 726-9645
edsimon@xmlsec.com 
Interested in XML, Web Services, or Security?  Visit "www.xmlsec.com".
Now available!  "Web Services Security" published by Osborne (ISBN#
0072224711)


-----Original Message-----
From: Jose Kahan [mailto:jose.kahan@w3.org] 
Sent: December 17, 2004 2:06 PM
To: Ed Simon
Cc: 'Stephen Farrell'; www-xkms@w3.org
Subject: Re: Again, confusing 8.1

Ed, Stephen,

See my previous message.

On Fri, Dec 17, 2004 at 11:39:10AM -0500, Ed Simon wrote:

> It seems to me that requiring an XML processor (right?) is going to be 
> particularly performance-consuming.  Plus one has to deal with exactly 
> what "All shared string values are encoded as XML" means.  To me, it 
> means that the pass phrase MUST be valid XML (eg.
>
> "<Pass_Phrase xmlns="http://example.com/secrets">my
> <Adjective>little</Adjective>
> <![CDATA[&lt;]]>secret<![CDATA[&gt;]]>!</Pass_Phrase>"

>From what I understand, the pass-phrase is never sent on the clear. We're
only sending the base-64 of a MAC computation.
So that should be valid XML.

However, one interesting point from Ed:
> 
> ) or else it is NOT a valid pass phrase, AND, therefore, pass phrase 
> tools must be full-fledged XML parsers capable of dealing with 
> potential attacks like entity expansion.  There is also a 
> contradiction that if one requires conversion to lower-case, one 
> invalidates XML such as that in my example because XML names are 
> case-sensitive.  It seems to me the constraints are contradictory.
> 
> I think what was originally intended was something like "encode as 
> UTF-8"; I expect requiring this would NOT break the interop cases done 
> thus far because I would guess no one is trying to use pass phrases 
> that are, in themselves, valid XML.

This makes me think that a user could go to any computer or device and be
able to regenerate the MAC in the same way... as if we need to canonicalize
the pass-phrase so that it's always possible to regenerate the same MAC as
needed.

For example, we could say:

Canonicalize the pass-phrase as follows:

- convert the pass phrase to UTF-8
- convert any remaining XML entity into UTF-8 characters

And then:

- apply the MAC algorithm

-jose

Received on Friday, 17 December 2004 19:42:33 UTC