<div dir="ltr"><div><div>I would suggest *not* to use the (single or double) hash of the key itself as the key-id. <br></div>One simple (and reasonably secure) way of computing key-id is as HMAC(key,string)<br>where "string" is drawn from a set of non-secret session values, e.g., timestamp, seq#, <br>endpoint names/addresses, etc.<br><br></div>Cheers,<br>Gene<br><br><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 3:12 AM,  <span dir="ltr"><<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">One could always just double hash the key to get the keyid for hmac.<div><br></div><div>Personally, I would think that in general hmac keys need to be agreed on by a key exchange protocol so they are rotated periodically.  However that agreement protocol identifies keys could also be used as the keyid, such as a small integer.</div><div><br></div><div>Marc</div><div><br></div></div></blockquote></div></div></div></div>