<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 16 Feb, 2012, at 3:30 AM, Bodo Moeller wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Thu, Feb 16, 2012 at 12:05 PM, Werner Koch <span dir="ltr"><<a href="mailto:wk@gnupg.org">wk@gnupg.org</a>></span> wrote:<br><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

You are right that RFC4880 does not demand that the key expiration date<br>
is put into a hashed subpacket.  But not doing so would be stupid.<br></blockquote><div><br>I call it a "protocol failure", you call it "stupid", but Jon calls it a "feature" (<a href="http://article.gmane.org/gmane.ietf.openpgp/4557/">http://article.gmane.org/gmane.ietf.openpgp/4557/</a>).<br></div></div></blockquote></div><br><div>That's not what I said. Or perhaps not what I meant.</div><div><br></div><div>I think it is indeed a feature that the expiry is a part of the certification, not part an intrinsic property of the key material. That permits you to do very cool things like rolling certification lifetimes.</div><div><br></div><div>Putting that into an unhashed packet is stupid, as Werner said.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">    </span>Jon</div><div><br></div></body></html>