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.
For your point "3) There is no explicit warning about the "alg" "none"", I plan
to add the additional step that you suggested.
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.
Thanks,
-- Mike
-----Original Message-----
From: Tero Kivinen [mailto:kivinen(_at_)iki(_dot_)fi]
Sent: Tuesday, September 16, 2014 2:27 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:
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