I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
Summary: This document has issues.
This document is part of the jose-json document set, and describres
the JSON Web Signatures.
The security considerations section includes text which says:
The entire list of security considerations is beyond the scope of
this document, but some significant considerations are listed here.
but also lists quite a lot of security considerations. I think the
security considerations covering this document should be in scope with
the document. Of course there are generic security considerations
which might be outside the scope of this document, but I do not think
we need to explictly mention those.
I have following issues about the draft:
1) "alg" and Protected Header
2) Hash inside "alg" and inside the signature
3) There is no explict warning about the "alg" "none".
4) Thumbprint formats
There is also following nit:
5) Terminology ordering.
----------------------------------------------------------------------
1) "alg" and Protected Header
Question: Shouldn't the "alg" header parameter be protected by the
signature, i.e. wouldn't it make sense to say MUST be in the
"Protected Header"?
If it is part of the "Unprotected Header" and is not protected by the
signature, that would allow all kind of attacks, i.e. changing the
"alg" to be "none" or changing the hash algorithm of the signature.
If it should be part of the "Protected Header" then that would mean
that "Proteced Header" cannot be empty, as "alg" is mandatory header
parameter, and MUST be present.
There are several cases where the text indicates that "Protected
Header" could be empty, which would mean that "alg" could be part of
the "Unprotected Header". (Section 5.1, 4. bullet; section 7.2,
"protected" element and other places in same section). In all examples
the "alg" is always in the "Proteced Header".
I think the draft needs text saying something about the situation
where "alg" is not in "Protected Header" in the security sections
section. I.e. either say, that it has been analyzed that there is no
problem even when the "alg" is not protected, and reference to such
analysis, or otherwise add text/warning that it MUST/SHOULD be in the
"Protected Header". I do not know enough about the proposed signature
algorithms to know which one is true, especially as there might be new
algorithms in the future.
--
2) Hash inside "alg" and inside the signature
Also in some cases the signature itself has the hash function stored
internally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid
inside the signature, so what should the implementation do if the
"alg" parameter outside the signature does not match the oid inside
the signature? I.e the signature using "alg" of "RS256", but inside
the signature the oid is using the "SHA1". Most crypto libraries will
just take the oid from the signature, and use that to verify the
message. Adding some description what to do in such situation would be
needed.
--
3) There is no explict warning about the "alg" "none".
In the section 5.2 it says that "at least one signature ... MUST
successfully validate", but that does not limit alg "none" out from
it. I.e. if the application policy is to "one signature needs to
validate", and it gets JWS that has "none" as one of the algorithms,
then it will accept it.
I think there should be warning here or in the security considerations
section about the "none" algorithm, especially as the algorithm itself
is defined in the different draft (perhaps just reference to the
section 8.5 of the [JWA] draft).
--
4) Thumbprint formats
Section 4.1.7 and 4.1.8 defines a x5t and x5t#S256 thumbprints, but
those are over the whole certificate.
With the thumbprints, it has been noted lately, that quite often it is
more useful to use the hash of the SubjectPublicKeyInfo object of the
X.509 certificate, than the full X.509 certificate. This method has
been used in the raw public key methods (draft-ietf-tls-oob-pubkey,
draft-kivinen-ipsecme-oob-pubkey), and also in the DANE (it has two
options one for the full certificate and another for the
SubjectPublicKeyInfo object of the certificate).
Using hash of the SubjectPublicKeyInfo object allows changing the
certificate without invalidiating the certificates, i.e. when changing
CAs, or switching from SHA1 to SHA2 in certificates, or just renewing
the certificate. It also allows using raw public keys which do not
have defined X.509 certificate format, but which can be converted to
the SubjectPublicKeyInfo object when calculating the thumbprints. This
is very important in the Internet of Things type of things, which
might not be using the full X.509 certificates.
--
5) Terminology ordering.
Terminology is not in any order. It would be useful to have it either
in logical order (i.e. define terms before they are used), or in
alphabetical order.
Now for example the "JWS Protected Header" is used before it is
defined in the "JWS Signature", and "Header Paramater" is between "JWS
Signature" and "JWS Protected Header", also "JWS Signature" uses both
"JWS Payload" and "JWS Protected Header", and one of those is defined
before and one after the "JWS Signature".
--
kivinen(_at_)iki(_dot_)fi