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