Thanks again for your review, Tero. The resolutions discussed in this thread
have been applied to the -32 draft.
-- Mike
-----Original Message-----
From: Tero Kivinen [mailto:kivinen(_at_)iki(_dot_)fi]
Sent: Monday, September 22, 2014 6:42 AM
To: Mike Jones
Cc: iesg(_at_)ietf(_dot_)org; secdir(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org;
draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
jose(_at_)ietf(_dot_)org
Subject: RE: Secdir review of draft-ietf-jose-json-web-signature-31
Mike Jones writes:
Tero - for your point "2) Hash inside "alg" and inside the signature",
could you please write proposed security considerations text
addressing this issue? I'd think it should describe the need for
implementations to ensure that signature verification is done for the
exact algorithm specified in the "alg" header parameter, no matter
what algorithm information may (or may not) have been encoded into the
signature value in an algorithm-specific manner.
Something like this:
In case of algorithms where there is algorithm parameters specified
also inside the actual signature, the implementations MUST verify
that the parameters inside the signature and the parameters
specified by the "alg" Header Parameter match. This includes for
example the RSASSA-PKCS-v1_5 algorithms ("RS*") where the signature
contains the hash algorithm and most libraries actually use the hash
algorithm specified inside the signature when verifying the
signature. This test is required as the steps in the section 5.2
verify that algorithms specified by the "alg" Header Parameter are
acceptable, and if those algorithms could be different the attacker
could be able to claim to use strong hash algorithm while actually
using weak one inside the signature.
For your point "3) There is no explicit warning about the "alg"
"none"", I plan to add the additional step that you suggested.
In my text above I assumed you had already added step in section 5.2 to verify
that "alg" is acceptable.
For your point "4) Thumbprint formats" if you or someone else wants to
define an additional thumbprint format for use in IoT contexts (or any
other contexts), I encourage you to write an Internet Draft that does
so, registering the new header parameter defined in the JSON Web
Signature and Encryption Header Parameters registry.
That can of course be done, but I would have hoped the initial version of the
specification would also be usable in the IoT context, where the use of raw
public keys will most likely arise.
--
kivinen(_at_)iki(_dot_)fi