Murray S. Kucherawy wrote:
Here's what I remember from the original discussion of h= and k= in
the key record.
First, part of the idea was to have them both there, to make things
parallel: "This key is used for this crypto suite."
[...]
I'm neutral on either keeping or removing this one. It seems to me an RSA
key is invalid input to any other crypto mechanism, so those functions will
do the validation implicitly.
While that is probably true, I'd note that the rsa p= value is
a fairly simple construct (ASN.1 sequence of two integers) and
other algorithms have similar structures (e.g. Dss public key
in RFC 3279 is one integer and DSS-parms is an ASN.1 sequence
of three integers) so I guess I'd be a little concerned that
someone might define another key type (e.g. some ECC variant)
that was also two integers, or that someone's decoding code
might be suspect (e.g. accepting a DSS public key as an
RSA modulus and defaulting the exponent to 65537 or
something).
The putative attack would be to sign with foo-sha256 where
foo is some algorithm that a verifier supports and such
that the foo key encoding could accept an rsa p= value as
input and such that that combination allows the attacker
to forge signatures.
That's fairly theoretical, but there'd be a bit
of work to go check that there is in fact no realistic
situation where such confusion could arise. So on the
whole, for me, keeping the k= just makes it easier
to get things right now and in future.
S. (As participant, of course)
Since "h=" doesn't have the same benefit, I'd rather keep it.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html