On Sunday 24 January 2016 02:04:28 Dave Garrett wrote: > On Saturday, January 23, 2016 07:47:11 pm Michael StJohns wrote: > > 1) A receiver of an deterministic ECDSA signature verifies it > > EXACTLY > > like they would a non-deterministic signature. > > 2) A receiver of an ECDSA signature cannot determine whether or not > > the signer did a deterministic signature. > > 3) A TLS implementation has no way (absent repeating signatures over > > identical data) of telling whether or not a given signature using > > the > > client or server private key is deterministic. > > > > All that suggests that this is a completely unenforceable > > requirement > > with respect to TLS. > > We can have unverifiable & unenforceable MUSTs. A SHOULD might be more > appropriate, however, if we want to acknowledge this limitation to > some degree.
a MUST is only necessary if you are not sure or simply know that your RNG is broken, if you're doing a HSM implementation you know that your RNG is good so you can just use it and while we can have unverifiable MUSTs, it just looks silly if you do, especially if the other way of doing things is just as interoperable, and just as secure (if implemented properly) as the mandated one... SHOULD with explanation why it's there is definitely better approach -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
