<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">
Le 15/09/2014 13:16, Håvard Molland a écrit :<br>
</div>
<blockquote cite="mid:5416CA8B.70403@opera.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 15. sep. 2014 11:15, Erwann Abalea
wrote:<br>
</div>
<blockquote cite="mid:5416AE20.4070105@opentrust.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">It would be hard to discuss about
SM2/SM3 at CABForum level when there's so few analysis and
publications of these algorithms.<br>
<br>
SM2 seems to be a set of asymetric cryptographic primitives
working on ECC, providing signature, key exchange, and
encipherment functions; respectively similar to ECDSA, ECDH,
and maybe ECIES?. There's also a new 256bits prime curve.<br>
SM3 is a hash function, MD design, similar to SHA256 with a
few modifications.<br>
<br>
What could be discussed at CABF level:<br>
- adoption of the new curve, can it be used with ECDSA to
sign certificates/CRLs/OCSP? (then we should also talk about
Brainpool family, ANSSI FRP256v1, Curve25519, and others)<br>
- adoption of SM3 in signatures, with ECDSA? That's a more
difficult question, we don't already agree on what to do with
SHA1, there's little to no analysis of SM3. The team behind
SM3 include some people involved in the end of MD4/MD5/RIPEMD
in 2004/2005, I guess they know what they're doing, but the
algo still needs to be challenged. If we talk about SM3, we
might as well talk about GOST R34.11-94, GOST R34.11-2012, and
maybe a lot of others...<br>
- adoption of SM2 in signature mode (SM2 part 2)? On which
curve, with which hash algorithm? An even more difficult
question; there's more info about EC-Schnorr or EdDSA than
there's about SM2. Again, other algorithms such as GOST
R34.10-2001 or GOST R34.10-2012 might as well be discussed,
and maybe ECKCDSA (Korean) or ECGDSA (German)<br>
</div>
</blockquote>
<br>
Any new algorithm should offer improvements on the existing
algorithms, such as improved security, new security features or
speed. I'm not sure we should add new algorithms simply for the
sake of being alternatives.<br>
</blockquote>
<br>
I agree, that's what SHOULD drive the inclusion of algorithms or
parameters. Based on that, the CABF SHOULD NOT discuss about
approval of these new things (not yet).<br>
<br>
Others MAY think differently, such as Russia, where GOST-approved
algorithms are mandatory. And we DO see GOST-approved hash
algorithms used in OCSP requests (to produce the issuerNameHash and
issuerKeyHash). Now.<br>
<br>
What if China mandates the use of their own algorithms?<br>
<br>
<pre class="moz-signature" cols="72">--
Erwann ABALEA
</pre>
<br>
</body>
</html>