Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31

Tero Kivinen <> Tue, 16 September 2014 09:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 073D01A01C3; Tue, 16 Sep 2014 02:27:34 -0700 (PDT)
X-Quarantine-ID: <FSsC78MlvnQQ>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "References"
X-Spam-Flag: NO
X-Spam-Score: -2.773
X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_NEUTRAL=0.779] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FSsC78MlvnQQ; Tue, 16 Sep 2014 02:27:31 -0700 (PDT)
Received: from ( [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 690B51A00C9; Tue, 16 Sep 2014 02:27:30 -0700 (PDT)
Received: from (localhost []) by (8.14.8/8.14.8) with ESMTP id s8G9RSbx024999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Sep 2014 12:27:28 +0300 (EEST)
Received: (from kivinen@localhost) by (8.14.8/8.14.8/Submit) id s8G9RQDL015192; Tue, 16 Sep 2014 12:27:26 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 16 Sep 2014 12:27:26 +0300
From: Tero Kivinen <>
To: Mike Jones <>
References: <>, <>
In-Reply-To: <>
References: <> <>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 27 min
X-Total-Time: 35 min
X-Mailman-Approved-At: Tue, 16 Sep 2014 08:40:49 -0700
Subject: Re: [jose] Secdir review of draft-ietf-jose-json-web-signature-31
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Sep 2014 09:27:34 -0000

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.


>> 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 -
> #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.