Re: "Last call" on draft-altman-tls-channel-bindings-05.txt

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
> For completeness, I would add:
> 
>    This algorithm agility resolution mechanism assumes that there is a
>    mapping from every Public-key signature algorithm to one hash
>    function algorithm.  This is the case for all practically used public
>    key signature algorithms today, but if future public-key signature
>    algorithms would employ multiple hash functions (or none at all) this
>    specification needs to be updated to resolve which hash function
>    should be used.

This brings up a question: what to do in the case of randomized digital
signatures?  In the case of NIST-SP-800-106 there's still a hash
function, so that's OK.  But one can imagine a digital signature
algorithm where a MAC and random key are used instead of a hash.

Traditionally a digital signature

	S'(Kp, M) = S(Kp, H(M))

while in NIST-SP-800-106

	S'(Kp, M) = {rv = rng(rv_len),
		     S(Kp, H(rv ||
			     (pad(M, rv_len) XOR xor_pad_gen(rv) ||
			     rv_length_indicator(rv_len))))
		    }

One could imagine this, however:

	S'(Kp, M) = {mk = rng(),
		     S(Kp, MAC(k, M))}

in which case there'd be no hash function.  Of course, we could define a
pseudo-hash function in that case: H(x) = MAC(mk, x), where mk is the mk
that would appear in the signature.

But I don't want to guess at what might happen in the future
of digital signatures.  Instead I'd rather either say either
that tls-server-end-point CB is undefined if the cert's
signature alg does not use a signature, or pick a hash
function (e.g., SHA-512) to use in such cases.

Comments?

Nico
--