RE: Again, confusing 8.1

Thank you Jose for your careful explanation.    

Ed wrote:
> 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.

Jose responded:
>>>
...
What is important is that the user be able to type the same passphrase
regardless of what device s/he is using. From some feedback I got (I've to
ask if I can forward it to the list), it seems that the best way is to
require that the pass-phrase be coded into UTF-8 before applying the MAC
algorithms. This provides for having the same result regardless of the
mechanism used to input the pass-phrase. 
<<<

My concern is regarding support for non-human-language pass phrases.  Yes,
if it is human language, there needs to be a way to canonicalize the various
textually equivalent, but binarily different, forms into one binary form.
Whether that canonicalization needs to be part of the core XKMS spec, or in
a profile, I'm not so sure (I lean toward a separate profile).  What is
important is that the XKMS spec 
a) NOT make it difficult for non-human-language pass phrases to be
implemented
b) read so that it is clear how one would use non-human-language pass
phrases

To address the above, I would rewrite paragraph [329] as follows (note: I've
NOT separated out the canonicalization of the human-readable symmetric key
into a separate profile):

>>>
[329a]The symmetric key data MAY be binary data (as from an authentication
device) or as a human-readable value (numeric, alphabetic, or both).  When
it is binary data, no transformation is needed; the data can be used
directly as input to the MAC function.

[329b]When the symmetric key data is human-readable, it may be issued to a
human user in the form of a text string which may in some circumstances be
read over a telephone line. It may be randomly generated and represent an
underlying numeric value, or may be a password or phrase. In either case, it
is often convenient to present the value to the human user as a string of
characters in a character set the particular user understands.  To limit the
possibility of human error in processing the symmetric key data, and to
provide a canonical binary representation, follow these REQUIRED steps.

1) Allow only characters conforming to the XML Schema NMTOKEN type
(http://w3.org/TR/xmlschema-2/#NMTOKEN).
2) Convert all upper case characters in the Latin-1 alphabet to lower case
(no other characters, including accented characters are converted).
3) Encode the string in UTF-8.
<<<

Comments?

Regards, 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: www-xkms-request@w3.org [mailto:www-xkms-request@w3.org] On Behalf Of
Jose Kahan
Sent: December 18, 2004 12:48 AM
To: Ed Simon
Cc: www-xkms@w3.org
Subject: Re: Again, confusing 8.1

Ed,

Mea-culpa!

On Fri, Dec 17, 2004 at 02:42:58PM -0500, Ed Simon wrote:
> 
> 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).

Oops! Sorry for my being ignorant about this! 

I had to do my homework again so to avoid saying confusing things.
The XKMS schema uses xs:base64Binary for some of its attributes and
elements, including <RevocationCodeIdentifier> and <RevocationCode> where
the base64bin coding of the result of the encoded pass-phrase goes when
registering a new key.

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

It's a bit more than that. For me part of the confusion is how 8.1 defintes
what is a Limited-Use Shared secret. Looking at the example for the
Registration of a Client-Generated Key pair in section 6.1.1, par[243],
Alice uses the pass-phrase (or shared string?) "Help I have revealed my key"
is used. This string is encoded twice with the HMAC-SHA1 one way function
(Appendix C.2.1) and the final result is BASE64bin  encoded (I guess this is
how one referers to it) and then included inside this element:

     <RevocationCodeIdentifier>
      5AEAai06hFJEkuqyDyqNh8k/u3M=
    </RevocationCodeIdentifier>

In 6.3.1 this key is revoked and Alice uses the same pass-phrase for
authentication purposes. But she only applies once the HMAC_SHA1 one way
function and then BASE64bin encodes the result:

   <RevocationCode>PHx8li2SUhrJv2e1DyeWbGbD6rs=</RevocationCode>

The server verifies the authentication by applying itself the second
HMAC-SHA1 on the furnished value and comparing the values, which must be the
same. In this case, the pass-phrase never circulated on the clear and the
server never knew what it was.  didn't saw it.

This is explained in section 7.1.2.

What is important is that the user be able to type the same passphrase
regardless of what device s/he is using. From some feedback I got (I've to
ask if I can forward it to the list), it seems that the best way is to
require that the pass-phrase be coded into UTF-8 before applying the MAC
algorithms. This provides for having the same result regardless of the
mechanism used to input the pass-phrase.

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

We're only coding binary results into BASE64bin AFAIK. 

Did the explanations that I write here above clarify a bit this?

-jose

Received on Monday, 20 December 2004 19:55:17 UTC