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
