<div dir="ltr">Unfortunately, the errata process takes time. i.e., in our process, we need 45 days review period after the WG consensus and one week voting period, so we are talking like the minimum of two months. <div><br>
<div>In the mean time, we need a minimum impact interim "work around" to recommend. </div><div><br></div><div>Nat <div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-26 5:24 GMT-08:00 Manger, James <span dir="ltr"><<a href="mailto:James.H.Manger@team.telstra.com" target="_blank">James.H.Manger@team.telstra.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why are we discussing ad hoc crypto restrictions on n & e, instead of simply fixing an obviously flawed method of fingerprinting a key?<br>

<br>
--<br>
James Manger<br>
<div class=""><br>
----- Reply message -----<br>
From: "Nat Sakimura" <<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>><br>
Date: Wed, Feb 26, 2014 7:11 pm<br>
Subject: [security] OIC self-issued mode is insecure<br>
</div><div class="">To: "Manger, James" <<a href="mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.com</a>><br>
Cc: "Mike Jones" <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>>, "<a href="mailto:openid-security@lists.openid.net">openid-security@lists.openid.net</a>" <<a href="mailto:openid-security@lists.openid.net">openid-security@lists.openid.net</a>><br>

<br>
Hi James,<br>
<br>
Thanks for pointing it out.<br>
<br>
</div>2014-02-25 16:48 GMT-08:00 Manger, James <<a href="mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.com</a><mailto:<a href="mailto:James.H.Manger@team.telstra.com">James.H.Manger@team.telstra.com</a>>>:<br>

<div class="HOEnZb"><div class="h5">> Having implementations verify that RSA key lengths are powers of two<br>
> seems like it could be one mitigation.<br>
<br>
I don’t think so. There are 1536-bit keys (just as historically there were 768-bit keys). I’m sure some will pick 3072-bit keys.<br>
Also, many supposedly 2048-bit keys are actually 2047-bit keys (still a product of two 1024-bit primes). Reject those and you will break things.<br>
<br>
<br>
ANSI X9.31 requires the key length to be the multiple of 256 bit, does it not?<br>
In which case, is not 2047-bit keys rejected?<br>
<br>
Also, I was wondering if requiring exponent to be selected from small set of candidates or even just requiring one would help.<br>
<br>
i.e., either e={3, 5, 17, 257, 65537} or e=65537.<br>
<br>
Some specs requires e>=65537 so just requiring e=65537 is not unreasonable, I think. Also, there is a study [1]  that over 95% of the e value used is 65537. Adding the fact that Windows' CAPI only accepts 65537 as e in key generation makes me think that most if not all libraries will accept 65537 as an input value for signature verification that in this particular case of self-issued provider, it would not hart to mandate that e be 65537. Do not you think it would help in the case of RSA?<br>

<br>
[1] <a href="https://eprint.iacr.org/2012/064.pdf" target="_blank">https://eprint.iacr.org/2012/064.pdf</a><br>
--<br>
Nat Sakimura (=nat)<br>
Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>

</div></div></div>