Mike Jones writes:
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.
Several reviewers have objected to this sentence. Its removal is
planned.
Good.
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.
I think there's some confusion here, since the JWS spec does not use
any OIDs or ASN.1 for signatures. Rather, the cryptographic
operations to be performed are fully specified by the "alg" value
and the signatures are represented as base64url encoded octet
sequences representing the signature values produced by the
signature algorithms.
But JWS uses RSASSA-PKCS1-V1_5, which DOES have ASN.1 inside. I.e. if
you look at the RFC3447 section 8.2 (referenced from the
draft-ietf-jose-json-web-algorithms-31) you will see that when you
generate signature, you first to EMSA-PKCS1-V1_5-ENCODE operation
(section 9.2 of RFC3447) to the message. This will take the hash of
the message, then create the DigestInfo ASN.1 object, which includes
the oid of hash algoritm used in previous step and the actual output
of the hash, and finally you encode the EM by padding that DigestInfo
with suitable padding. After that you do the RSA operation.
When verifying the signature, you do RSA operation, verify the padding
and extract the hash oid and hash value out from the ASN.1 and then
generate EM' by doing EMSA-PKCS1-V1_5-ENCODE operation to the original
message using hash algorithm specified by the oid extracted by
previous operation.
In most cases the libraries will always do that automatically, and
there is no way to specify that you want to use some other algorith,
than what is stored in the ASN.1, as if you use any other algorithm
that was exactly same than what was stored in the ASN.1 inside the RSA
signature the verification will fail.
In your case there is now two algorithms, the outer "alg" algorithm
and the one inside the signature itself. So even if the outer "alg"
says "RS256", the hash used in the signature might be MD5, and most
crypto libraries will simply verify the signature fine, and this can
cause security problems.
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).
This warning is present in the spec where the algorithm is defined
specifically -
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31
#section-8.5. (Note that the working group decided to define
algorithms in a separate spec than the ones in which they are used.)
Also note that it is up to applications which algorithms are
acceptable in a given context - not just "none" but also other
algorithms that might be deprecated or inappropriate for some other
reason. Unless the signature algorithm used is acceptable to the
application, it should not accept the JWT.
The current draft does not have any steps for such policy checks. So
it would be good to add new step in section 5.2 which says that verify
that the algorithms used in the signature are allowed by the policy in
the current context. Also noting that "none" is not really usable
signature algoritm ever...
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.
This thumbprint definition matches existing practice in commonly
used software packages. For instance, both openssl and Windows use
certificate thumbprints of this kind.
Yes, I am not saying we should remove them.
That being said, there's nothing preventing another specification
from defining a different thumbprint calculation over the SPKI
information and a header parameter used to represent it. The header
parameters are extensible via a registry.
Yes, but as I think those formats using SPKI are much more usable,
especially in the internet of things contextes, it might be good idea
to define them now, not year later. On the other hand if these formats
are not meant to be used in the Internet of Things contextes, then
never mind...
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".
The terms are listed in top-down order, with related terms grouped
together. Thus "JSON Web Signature" is first, the members that make
up a JWS object are listed together in the order that they appear in
a JWS, etc. That being said, I'll plan to review the orderings and
make sure that they consistently follow those ordering rules.
Ok, thanks.
--
kivinen(_at_)iki(_dot_)fi